Matt, Indeed - we can carve out any scope we want out of the wider scope of the whole problem space. My concern was that the argument for choosing the particular scope of RTP transport seemed based on some misunderstanding. It would be perfectly valid to work solely on RTP transport if it was to make sure it doesn't starve out elastic traffic. This was the proposal from people like Colin Perkins, which was a sensible attempt to focus down the work (setting aside whether there is a feasible solution). Bob At 21:59 07/07/2012, Matt Mathis wrote:
I would like to point out that nobody has actually disagreed: If "fixing the network" means something like "deploy QoS" then yes it is absolutely out of scope. However "diagnosing (the lack of) QoS" is absolutely in scope. It should have the indirect effect of causing the former, irregardless of scope or who owns the problem.
Note that the Internet will almost certainly be better served by QoS metrics that are built into all applications and determined by their needs, rather than the intent of the QoS implementers.
And (I hope) we all agree that rtcweb can not directly fix network problems, no matter how well it performs.
Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay
On Sat, Jul 7, 2012 at 11:13 AM, Jim Gettys <<mailto:jg@freedesktop.org>jg@freedesktop.org> wrote: On 07/07/2012 01:35 PM, Bob Briscoe wrote:
Michael, Bill,
The proposed logic for focusing on the R-T transport is that network fixes will only be deployed piecemeal, so some parts of the Internet won't have the new functions in them, therefore any fix has to be done in the e2e transport. This sounds logical if you don't think too hard about it, but...
1/ If the chosen problem to address is that TCP flow(s) are running up to the tail of a slow buffer and causing delays and losses that make simultaneous r-t delivery quality poor, then no amount of improvement to RTP alone will fix this. The impairment would be caused by the TCP traffic even if the RTP flow(s) weren't there, so adding an RTP flow cannot /reduce/ impairments caused by other transports (unless it includes a magic anti-delay-sucking nano-worm).
Bob is exactly correct: no programming around bufferbloat will work for real time, no protocols magic will work that I can see.
Ledbat only works because you are trying to do the opposite: keep it from interfering with TCP. And even there, Ledbat stops working once AQM (e.g. CoDel) keeps the delays low. The inverse just won't work.
And even a single TCP connection will do you in today.
For instance, if we added delay sensing to the R-T transport, it will sense delay, back-off and TCP will just continue, while the RTP starves itself (cf Vegas).
If TCP-induced impairment is indeed the chosen problem, then limiting the scope to R-T transport only will therefore achieve precisely nothing.
2/ If the chosen problem is to prevent an R-T transport doing harm to other elastic (TCP) traffic (or other R-T traffic for that matter), then focusing on RTP makes perfect sense.
3/ If problem #1 (preventing TCP harming RT) is in scope, then network changes are the *only* way to solve this aspect. They won't solve it anywhere but where they are deployed, but this is better than solution #1 (focus on R-T transport alone), which solves it precisely nowhere.
I think we must presume the network gets fixed. Broadband (and WiFi) are both broken well beyond real time standards required for good audio to be reliable.
The biggest parts of the bufferbloat problem (at least that we know today; we may be looking for keys under the lamppost) are the two common bottlenecks at the edge of the network. In your house, those are your broadband connection, and your WiFi hop (both sides of the WiFi hop; your operating system needs to be fixed too). Cellular wireless is somewhat similar, but also somewhat different.
I think the right strategy for rtcweb are two fold: a) making sure that everything works well for real time when the network has been fixed. cf. <http://gettys.wordpress.com/2012/06/26/the-internet-is-screwed-up-and-how-to-fix-it/>http://gettys.wordpress.com/2012/06/26/the-internet-is-screwed-up-and-how-to-fix-it/ b) detecting the problem, so that people know to go get it fixed, and which hops are broken. Preferably by pointing the finger to the offending component, so that it gets fixed, whether your operating system, your home router, your broadband cpe, your broadband head end.
So Bob is exactly correct on this; you can't engineer real time traffic around bufferbloat in today's broken internet by protocol magic. You can, however fix the broken components (and in your home, with care, do pretty well even today if you are clever). cf. <http://gettys.wordpress.com/2010/12/13/mitigations-and-solutions-of-bufferbloat-in-home-routers-and-operating-systems/>http://gettys.wordpress.com/2010/12/13/mitigations-and-solutions-of-bufferbloat-in-home-routers-and-operating-systems/ And you can come help fix the problem for real, in home routers, and elsewhere in the network. - Jim
Bob
At 16:03 07/07/2012, Michael Welzl wrote:
I agree.
It seems clear to me that the ability to work everywhere is the top goal of rtcweb; interactions with the network have to be considered, of course (any congestion control algorithm will have to consider queue behavior).
More below, in line:
On Jul 6, 2012, at 6:20 PM, Bill Ver Steeg (versteb) wrote:
I agree that this is not the right forum for discussing middlebox buffer management algorithms. I would add that even if the network elements do creep into scope, the host-based congestion control algorithms still have to work with the existing systems found in the wild. In other words, we could suggest that the middleboxes implement [insert your favorite AQM algorithm here]and [insert your pick of ECN, PCN, or maybe even Conex, etc] but the hosts still need to deal with [tail drop, RED, WRED, etc].
Stated another way, the algorithm is going to get a variety of congestion signals. When running on networks with primitive buffer management algorithms, one of those signals is going to be delay. On more modern systems, we can hope that the middleboxes' buffer management algorithms do not introduce persistent delay.
So, the RMCAT work will have to consider delay, packet loss and explicit packet markings. In a perfect world, the network will never give us persistent delay - but the world is rarely perfect.
Bill VerSteeg
-----Original Message----- From:
<mailto:rtp-congestion-bounces@alvestrand.no>rtp-congestion-bounces@alvestrand.no
[mailto:rtp-congestion-bounces@alvestrand.no ] On Behalf Of John Leslie Sent: Friday, July 06, 2012 11:38 AM To: Bob Briscoe Cc: <mailto:rtp-congestion@alvestrand.no>rtp-congestion@alvestrand.no; Michael Welzl Subject: Re: [R-C] BoF approved
Bob Briscoe <<mailto:bob.briscoe@bt.com>bob.briscoe@bt.com> wrote:
At 11:41 06/07/2012, Michael Welzl wrote:
On 6/26/12 4:05 PM, Wesley Eddy wrote: > The RMCAT BoF was approved to meet at IETF 84 in Vancouver.
From <http://trac.tools.ietf.org/bof/trac/>http://trac.tools.ietf.org/bof/trac/ : ] ] Transport ] ] RTP Media Congestion Avoidance Techniques (RMCAT) ] ] Description: WG-forming BoF on RTP congestion control ] Responsible AD: Wesley Eddy ] BoF Chairs: Michael Welzl and Colin Perkins ] Number of people expected to attend: 100 ] Length of session: 2 hours ] Conflicts to avoid: RTCWEB, AVTCORE, MMUSIC, ICCRG, CODEC, TSVWG, TCPM, ] CONEX, PCN, MPTCP, IPPM, CORE ] Webex: not sure ] Meetecho: not sure ] Mailing list: <mailto:rtp-congestion@alvestrand.no>rtp-congestion@alvestrand.no ] I-Ds:
] http://datatracker.ietf.org/doc/draft-jesup-rtp-congestion-reqs/ ] Draft charter: ]
] Status: APPROVED
> When it was discussed by the IESG and IAB, one topic that really > needs to be clarified by/within the group is the scope of the > mechanisms being developed. For instance, it needs to be more > clear what stack the group wants to be chartered to operate on. > Whether the group would be doing a mechanism that works for RTP > itself, or a new SCTP mechanism will need to be very clear.
I would like to get a grip on exactly *what* really *is* decided regarding the way the stack looks. Which protocol over which protocol(s) for which type of data. ...
Michael,
Recall at the Paris ICCRG I asked the wider question of whether changes to the network are in scope.
Personally, for the sake of keeping focus, I would say it's out of scope.
This is Transport area, with Wes the expected Responsible AD.
That means Network-Layer isn't expected to be in-scope for the WG.
I would hope, however, that discussion of potential Network-Layer work which would be helpful would be in-scope for the BoF.
I know those proposing this believe the scope is v definitely e2e protocols only (at least, if not specified down to a specific e2e protocol), but the scope determines very greatly how much of the problem we're going to solve:
* If RTP-only, we don't solve TCP harming RTP, only the other way round (which is fine if that's the scope we want)
I don't understand that.
* If SCTP-only, I'm not sure what we solve?
I get the impression that SCTP-only is not an option.
* If we allow network to be in scope, we might be able to address bufferbloat-style issues, or perhaps good policer designs to protect apps from each other.
Good policer designs that work well with rtcweb would be cool to have, but why can't that be done e.g. in ICCRG?
I expect to do a rant at the Workshop on Congestion Control for Interactive Real-Time Communication July 28th, to the effect that this can't be solved at the Transport Layer only.
It looks as if enough of us will be there to discuss Bob's question.
I agree, but I think we should try to get consensus on some key issues earlier than that.
My personal opinion is that this w-g should be trying to solve the problem. And the problem has three halves: * RTP harming elastic * elastic harming RTP * network arbitrating between the two
Clearly the first needs to be in-scope for the WG.
IMHO the other two halves need to be discussed at the BoF.
If I understood it correctly, Matt Mathis argued that neither the first nor the second should be in scope. I'd like to hear some more views on that.
Having read RFC5434, I think a general goal, and the role of Colin and me, is to try to maximize consensus and minimize the amount of discussion-at-the-BOF beforehand. So naturally I disagree, for now, that these things need to be discussed there. Let's try to agree on as much as possible before it.
Cheers, Michael
________________________________________________________________ Bob Briscoe, BT Innovate & Design _______________________________________________ Rtp-congestion mailing list <mailto:Rtp-congestion@alvestrand.no>Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list <mailto:Rtp-congestion@alvestrand.no>Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
________________________________________________________________ Bob Briscoe, BT Innovate & Design
Hi, Personally I think that the best we can do end-to-end, and a good possible scope, is: - avoid that RTP starves out elastic traffic as per Colin's proposal - *additionally* make sure that our transport keeps queues low in the absence of TCP traffic, or does not contribute more than necessary to queue growth - *additionally* avoid being starved by TCP traffic Combining all of these things should be possible. Yes, if there is a competing TCP, it will still push up the queues, but I think it should be outside the scope of this group to solve that. All with chair hat off, just bringing in my personal thoughts. Cheers, Michael On Jul 8, 2012, at 4:56 PM, Bob Briscoe wrote:
Matt,
Indeed - we can carve out any scope we want out of the wider scope of the whole problem space. My concern was that the argument for choosing the particular scope of RTP transport seemed based on some misunderstanding.
It would be perfectly valid to work solely on RTP transport if it was to make sure it doesn't starve out elastic traffic. This was the proposal from people like Colin Perkins, which was a sensible attempt to focus down the work (setting aside whether there is a feasible solution).
Bob
At 21:59 07/07/2012, Matt Mathis wrote:
I would like to point out that nobody has actually disagreed: If "fixing the network" means something like "deploy QoS" then yes it is absolutely out of scope. However "diagnosing (the lack of) QoS" is absolutely in scope. It should have the indirect effect of causing the former, irregardless of scope or who owns the problem.
Note that the Internet will almost certainly be better served by QoS metrics that are built into all applications and determined by their needs, rather than the intent of the QoS implementers.
And (I hope) we all agree that rtcweb can not directly fix network problems, no matter how well it performs.
Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay
On Sat, Jul 7, 2012 at 11:13 AM, Jim Gettys <jg@freedesktop.org> wrote: On 07/07/2012 01:35 PM, Bob Briscoe wrote:
Michael, Bill,
The proposed logic for focusing on the R-T transport is that network fixes will only be deployed piecemeal, so some parts of the Internet won't have the new functions in them, therefore any fix has to be done in the e2e transport. This sounds logical if you don't think too hard about it, but...
1/ If the chosen problem to address is that TCP flow(s) are running up to the tail of a slow buffer and causing delays and losses that make simultaneous r-t delivery quality poor, then no amount of improvement to RTP alone will fix this. The impairment would be caused by the TCP traffic even if the RTP flow(s) weren't there, so adding an RTP flow cannot /reduce/ impairments caused by other transports (unless it includes a magic anti-delay-sucking nano-worm).
Bob is exactly correct: no programming around bufferbloat will work for real time, no protocols magic will work that I can see.
Ledbat only works because you are trying to do the opposite: keep it from interfering with TCP. And even there, Ledbat stops working once AQM (e.g. CoDel) keeps the delays low. The inverse just won't work.
c.f. http://gettys.wordpress.com/2012/05/14/the-next-nightmare-is-coming/
And even a single TCP connection will do you in today.
For instance, if we added delay sensing to the R-T transport, it
will
sense delay, back-off and TCP will just continue, while the RTP starves itself (cf Vegas).
If TCP-induced impairment is indeed the chosen problem, then limiting the scope to R-T transport only will therefore achieve precisely nothing.
2/ If the chosen problem is to prevent an R-T transport doing harm to other elastic (TCP) traffic (or other R-T traffic for that matter), then focusing on RTP makes perfect sense.
3/ If problem #1 (preventing TCP harming RT) is in scope, then network changes are the *only* way to solve this aspect. They won't solve it anywhere but where they are deployed, but this is better than solution #1 (focus on R-T transport alone), which solves it precisely nowhere.
I think we must presume the network gets fixed. Broadband (and WiFi) are both broken well beyond real time standards required for good audio to be reliable.
The biggest parts of the bufferbloat problem (at least that we know today; we may be looking for keys under the lamppost) are the two common bottlenecks at the edge of the network. In your house, those are your broadband connection, and your WiFi hop (both sides of the WiFi hop; your operating system needs to be fixed too). Cellular wireless is somewhat similar, but also somewhat different.
I think the right strategy for rtcweb are two fold: a) making sure that everything works well for real time when the network has been fixed. cf. http://gettys.wordpress.com/2012/06/26/the-internet-is-screwed-up-and-how-to... b) detecting the problem, so that people know to go get it fixed, and which hops are broken. Preferably by pointing the finger to the offending component, so that it gets fixed, whether your operating system, your home router, your broadband cpe, your broadband head end.
So Bob is exactly correct on this; you can't engineer real time traffic around bufferbloat in today's broken internet by protocol magic. You can, however fix the broken components (and in your home, with care, do pretty well even today if you are clever). cf. http://gettys.wordpress.com/2010/12/13/mitigations-and-solutions-of-bufferbl... And you can come help fix the problem for real, in home routers, and elsewhere in the network. - Jim
Bob
At 16:03 07/07/2012, Michael Welzl wrote:
I agree.
It seems clear to me that the ability to work everywhere is the
top
goal of rtcweb; interactions with the network have to be considered, of course (any congestion control algorithm will have to consider queue behavior).
More below, in line:
On Jul 6, 2012, at 6:20 PM, Bill Ver Steeg (versteb) wrote:
I agree that this is not the right forum for discussing middlebox buffer management algorithms. I would add that even if the network elements do creep into scope, the host-based congestion control algorithms still have to work with the existing systems found in the wild. In other words, we could suggest that the middleboxes implement [insert your favorite AQM algorithm here]and [insert your pick of ECN, PCN, or maybe even Conex, etc] but the hosts still need to deal with [tail drop, RED, WRED, etc].
Stated another way, the algorithm is going to get a variety of congestion signals. When running on networks with primitive buffer management algorithms, one of those signals is going to be delay. On more modern systems, we can hope that the middleboxes' buffer management algorithms do not introduce persistent delay.
So, the RMCAT work will have to consider delay, packet loss and explicit packet markings. In a perfect world, the network will never give us persistent delay - but the world is rarely perfect.
Bill VerSteeg
-----Original Message----- From: rtp-congestion-bounces@alvestrand.no [ mailto:rtp-congestion-bounces@alvestrand.no ] On Behalf Of John Leslie Sent: Friday, July 06, 2012 11:38 AM To: Bob Briscoe Cc: rtp-congestion@alvestrand.no; Michael Welzl Subject: Re: [R-C] BoF approved
Bob Briscoe <bob.briscoe@bt.com> wrote:
At 11:41 06/07/2012, Michael Welzl wrote: > On 6/26/12 4:05 PM, Wesley Eddy wrote: >> The RMCAT BoF was approved to meet at IETF 84 in Vancouver.
From http://trac.tools.ietf.org/bof/trac/ : ] ] Transport ] ] RTP Media Congestion Avoidance Techniques (RMCAT) ] ] Description: WG-forming BoF on RTP congestion control ] Responsible AD: Wesley Eddy ] BoF Chairs: Michael Welzl and Colin Perkins ] Number of people expected to attend: 100 ] Length of session: 2 hours ] Conflicts to avoid: RTCWEB, AVTCORE, MMUSIC, ICCRG, CODEC, TSVWG, TCPM, ] CONEX, PCN, MPTCP, IPPM, CORE ] Webex: not sure ] Meetecho: not sure ] Mailing list: rtp-congestion@alvestrand.no ] I-Ds: http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-congestion/ ] http://datatracker.ietf.org/doc/draft-jesup-rtp-congestion-reqs/ ] Draft charter: ] http://www.alvestrand.no/pipermail/rtp-congestion/2012-May/000381.html ] Status: APPROVED
>> When it was discussed by the IESG and IAB, one topic that really >> needs to be clarified by/within the group is the scope of the >> mechanisms being developed. For instance, it needs to be more >> clear what stack the group wants to be chartered to operate on. >> Whether the group would be doing a mechanism that works for RTP >> itself, or a new SCTP mechanism will need to be very clear. > > I would like to get a grip on exactly *what* really *is* decided > regarding the way the stack looks. Which protocol over which > protocol(s) for which type of data. > ...
Michael,
Recall at the Paris ICCRG I asked the wider question of whether changes to the network are in scope.
Personally, for the sake of keeping focus, I would say it's out of scope.
This is Transport area, with Wes the expected Responsible AD.
That means Network-Layer isn't expected to be in-scope for the WG.
I would hope, however, that discussion of potential Network- Layer work which would be helpful would be in-scope for the BoF.
I know those proposing this believe the scope is v definitely e2e protocols only (at least, if not specified down to a specific e2e protocol), but the scope determines very greatly how much of the problem we're going to solve:
* If RTP-only, we don't solve TCP harming RTP, only the other way round (which is fine if that's the scope we want)
I don't understand that.
* If SCTP-only, I'm not sure what we solve?
I get the impression that SCTP-only is not an option.
* If we allow network to be in scope, we might be able to address bufferbloat-style issues, or perhaps good policer designs to protect apps from each other.
Good policer designs that work well with rtcweb would be cool to have, but why can't that be done e.g. in ICCRG?
I expect to do a rant at the Workshop on Congestion Control for Interactive Real-Time Communication July 28th, to the effect that this can't be solved at the Transport Layer only.
It looks as if enough of us will be there to discuss Bob's question.
I agree, but I think we should try to get consensus on some key issues earlier than that.
My personal opinion is that this w-g should be trying to solve
the
problem. And the problem has three halves: * RTP harming elastic * elastic harming RTP * network arbitrating between the two
Clearly the first needs to be in-scope for the WG.
IMHO the other two halves need to be discussed at the BoF.
If I understood it correctly, Matt Mathis argued that neither the first nor the second should be in scope. I'd like to hear some more views on that.
Having read RFC5434, I think a general goal, and the role of Colin and me, is to try to maximize consensus and minimize the amount of discussion-at-the-BOF beforehand. So naturally I disagree, for now, that these things need to be discussed there. Let's try to agree on as much as possible before it.
Cheers, Michael
________________________________________________________________ Bob Briscoe, BT Innovate & Design _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
Bob Briscoe, BT Innovate & Design
Michael, That's a good scope to work on. To be clear, when we say we agree with "Colin's proposal" we're saying we agree with the problem statement part, not necessarily buying in to Colin's particular solution. Bob At 12:17 12/07/2012, Michael Welzl wrote:
Hi,
Personally I think that the best we can do end-to-end, and a good possible scope, is: - avoid that RTP starves out elastic traffic as per Colin's proposal - *additionally* make sure that our transport keeps queues low in the absence of TCP traffic, or does not contribute more than necessary to queue growth - *additionally* avoid being starved by TCP traffic
Combining all of these things should be possible. Yes, if there is a competing TCP, it will still push up the queues, but I think it should be outside the scope of this group to solve that.
All with chair hat off, just bringing in my personal thoughts.
Cheers, Michael
On Jul 8, 2012, at 4:56 PM, Bob Briscoe wrote:
Matt,
Indeed - we can carve out any scope we want out of the wider scope of the whole problem space. My concern was that the argument for choosing the particular scope of RTP transport seemed based on some misunderstanding.
It would be perfectly valid to work solely on RTP transport if it was to make sure it doesn't starve out elastic traffic. This was the proposal from people like Colin Perkins, which was a sensible attempt to focus down the work (setting aside whether there is a feasible solution).
Bob
At 21:59 07/07/2012, Matt Mathis wrote:
I would like to point out that nobody has actually disagreed: If "fixing the network" means something like "deploy QoS" then yes it is absolutely out of scope. However "diagnosing (the lack of) QoS" is absolutely in scope. It should have the indirect effect of causing the former, irregardless of scope or who owns the problem.
Note that the Internet will almost certainly be better served by QoS metrics that are built into all applications and determined by their needs, rather than the intent of the QoS implementers.
And (I hope) we all agree that rtcweb can not directly fix network problems, no matter how well it performs.
Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay
On Sat, Jul 7, 2012 at 11:13 AM, Jim Gettys <jg@freedesktop.org> wrote: On 07/07/2012 01:35 PM, Bob Briscoe wrote:
Michael, Bill,
The proposed logic for focusing on the R-T transport is that network fixes will only be deployed piecemeal, so some parts of the Internet won't have the new functions in them, therefore any fix has to be done in the e2e transport. This sounds logical if you don't think too hard about it, but...
1/ If the chosen problem to address is that TCP flow(s) are running up to the tail of a slow buffer and causing delays and losses that make simultaneous r-t delivery quality poor, then no amount of improvement to RTP alone will fix this. The impairment would be caused by the TCP traffic even if the RTP flow(s) weren't there, so adding an RTP flow cannot /reduce/ impairments caused by other transports (unless it includes a magic anti-delay-sucking nano-worm).
Bob is exactly correct: no programming around bufferbloat will work for real time, no protocols magic will work that I can see.
Ledbat only works because you are trying to do the opposite: keep it from interfering with TCP. And even there, Ledbat stops working once AQM (e.g. CoDel) keeps the delays low. The inverse just won't work.
c.f. http://gettys.wordpress.com/2012/05/14/the-next-nightmare-is-coming/
And even a single TCP connection will do you in today.
For instance, if we added delay sensing to the R-T transport, it
will
sense delay, back-off and TCP will just continue, while the RTP starves itself (cf Vegas).
If TCP-induced impairment is indeed the chosen problem, then limiting the scope to R-T transport only will therefore achieve precisely nothing.
2/ If the chosen problem is to prevent an R-T transport doing harm to other elastic (TCP) traffic (or other R-T traffic for that matter), then focusing on RTP makes perfect sense.
3/ If problem #1 (preventing TCP harming RT) is in scope, then network changes are the *only* way to solve this aspect. They won't solve it anywhere but where they are deployed, but this is better than solution #1 (focus on R-T transport alone), which solves it precisely nowhere.
I think we must presume the network gets fixed. Broadband (and WiFi) are both broken well beyond real time standards required for good audio to be reliable.
The biggest parts of the bufferbloat problem (at least that we know today; we may be looking for keys under the lamppost) are the two common bottlenecks at the edge of the network. In your house, those are your broadband connection, and your WiFi hop (both sides of the WiFi hop; your operating system needs to be fixed too). Cellular wireless is somewhat similar, but also somewhat different.
I think the right strategy for rtcweb are two fold: a) making sure that everything works well for real time when the network has been fixed. cf. http://gettys.wordpress.com/2012/06/26/the-internet-is-screwed-up-and-how-to... b) detecting the problem, so that people know to go get it fixed, and which hops are broken. Preferably by pointing the finger to the offending component, so that it gets fixed, whether your operating system, your home router, your broadband cpe, your broadband head end.
So Bob is exactly correct on this; you can't engineer real time traffic around bufferbloat in today's broken internet by protocol magic. You can, however fix the broken components (and in your home, with care, do pretty well even today if you are clever). cf. http://gettys.wordpress.com/2010/12/13/mitigations-and-solutions-of-bufferbl... And you can come help fix the problem for real, in home routers, and elsewhere in the network. - Jim
Bob
At 16:03 07/07/2012, Michael Welzl wrote:
I agree.
It seems clear to me that the ability to work everywhere is the
top
goal of rtcweb; interactions with the network have to be considered, of course (any congestion control algorithm will have to consider queue behavior).
More below, in line:
On Jul 6, 2012, at 6:20 PM, Bill Ver Steeg (versteb) wrote:
I agree that this is not the right forum for discussing middlebox buffer management algorithms. I would add that even if the network elements do creep into scope, the host-based congestion control algorithms still have to work with the existing systems found in the wild. In other words, we could suggest that the middleboxes implement [insert your favorite AQM algorithm here]and [insert your pick of ECN, PCN, or maybe even Conex, etc] but the hosts still need to deal with [tail drop, RED, WRED, etc].
Stated another way, the algorithm is going to get a variety of congestion signals. When running on networks with primitive buffer management algorithms, one of those signals is going to be delay. On more modern systems, we can hope that the middleboxes' buffer management algorithms do not introduce persistent delay.
So, the RMCAT work will have to consider delay, packet loss and explicit packet markings. In a perfect world, the network will never give us persistent delay - but the world is rarely perfect.
Bill VerSteeg
-----Original Message----- From: rtp-congestion-bounces@alvestrand.no [ mailto:rtp-congestion-bounces@alvestrand.no ] On Behalf Of John Leslie Sent: Friday, July 06, 2012 11:38 AM To: Bob Briscoe Cc: rtp-congestion@alvestrand.no; Michael Welzl Subject: Re: [R-C] BoF approved
Bob Briscoe <bob.briscoe@bt.com> wrote: > At 11:41 06/07/2012, Michael Welzl wrote: >> On 6/26/12 4:05 PM, Wesley Eddy wrote: >>> The RMCAT BoF was approved to meet at IETF 84 in Vancouver.
From http://trac.tools.ietf.org/bof/trac/ : ] ] Transport ] ] RTP Media Congestion Avoidance Techniques (RMCAT) ] ] Description: WG-forming BoF on RTP congestion control ] Responsible AD: Wesley Eddy ] BoF Chairs: Michael Welzl and Colin Perkins ] Number of people expected to attend: 100 ] Length of session: 2 hours ] Conflicts to avoid: RTCWEB, AVTCORE, MMUSIC, ICCRG, CODEC, TSVWG, TCPM, ] CONEX, PCN, MPTCP, IPPM, CORE ] Webex: not sure ] Meetecho: not sure ] Mailing list: rtp-congestion@alvestrand.no ] I-Ds: http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-congestion/ ] http://datatracker.ietf.org/doc/draft-jesup-rtp-congestion-reqs/ ] Draft charter: ] http://www.alvestrand.no/pipermail/rtp-congestion/2012-May/000381.html ] Status: APPROVED
>>> When it was discussed by the IESG and IAB, one topic that really >>> needs to be clarified by/within the group is the scope of the >>> mechanisms being developed. For instance, it needs to be more >>> clear what stack the group wants to be chartered to operate on. >>> Whether the group would be doing a mechanism that works for RTP >>> itself, or a new SCTP mechanism will need to be very clear. >> >> I would like to get a grip on exactly *what* really *is* decided >> regarding the way the stack looks. Which protocol over which >> protocol(s) for which type of data. >> ... > > Michael, > > Recall at the Paris ICCRG I asked the wider question of whether > changes to the network are in scope.
Personally, for the sake of keeping focus, I would say it's out of scope.
This is Transport area, with Wes the expected Responsible AD.
That means Network-Layer isn't expected to be in-scope for the WG.
I would hope, however, that discussion of potential Network- Layer work which would be helpful would be in-scope for the BoF.
> I know those proposing this believe the scope is v definitely e2e > protocols only (at least, if not specified down to a specific e2e > protocol), but the scope determines very greatly how much of the > problem we're going to solve: > > * If RTP-only, we don't solve TCP harming RTP, only the other way > round (which is fine if that's the scope we want)
I don't understand that.
> * If SCTP-only, I'm not sure what we solve?
I get the impression that SCTP-only is not an option.
> * If we allow network to be in scope, we might be able to address > bufferbloat-style issues, or perhaps good policer designs to protect > apps from each other.
Good policer designs that work well with rtcweb would be cool to have, but why can't that be done e.g. in ICCRG?
I expect to do a rant at the Workshop on Congestion Control for Interactive Real-Time Communication July 28th, to the effect that this can't be solved at the Transport Layer only.
It looks as if enough of us will be there to discuss Bob's question.
I agree, but I think we should try to get consensus on some key issues earlier than that.
> My personal opinion is that this w-g should be trying to solve
the
> problem. And the problem has three halves: > * RTP harming elastic > * elastic harming RTP > * network arbitrating between the two
Clearly the first needs to be in-scope for the WG.
IMHO the other two halves need to be discussed at the BoF.
If I understood it correctly, Matt Mathis argued that neither the first nor the second should be in scope. I'd like to hear some more views on that.
Having read RFC5434, I think a general goal, and the role of Colin and me, is to try to maximize consensus and minimize the amount of discussion-at-the-BOF beforehand. So naturally I disagree, for now, that these things need to be discussed there. Let's try to agree on as much as possible before it.
Cheers, Michael
________________________________________________________________ Bob Briscoe, BT Innovate & Design _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
Bob Briscoe, BT Innovate & Design
________________________________________________________________ Bob Briscoe, BT Innovate & Design
We do not really capture the problem space by talking about "competing with TCP". Some TCPs reduce load when encountering additional delay, many do not. Perhaps we should think about "competing with cross traffic that builds middlebox buffers" and "competing with cross traffic that does not build middlebox buffers". This is particularly true when talking about systems that have a tail-drop middlebox directly upstream of the bottleneck link. Systems with more modern buffer management algorithms are less problematic. The queues will be pushed up by a variety of traffic. The middleboxes will handle this in a variety of ways. Changing the response of the middleboxes is out of scope for this group, IMHO. Responding to the delay/drop/marking of packets is in scope. Generally speaking, transports that recognize delay and back off a bit will not build persistent queues - even with primitive middlebox buffer management algorithms. We can't specify what the competing flows do, but we can specify what the RMCAT flows do. When a delay-sensitive flow competes with other delay sensitive flows, it is pretty easy to visualize a solution set. However, when a delay-sensitive flow competes with a non-delay-sensitive flow, it is not easy to come up with a solution. I have seen proposals (in the TCP space) that try to play fairly for a while, then fall back to a non-delay-sensitive behavior when they sense that other flows are not sensing delay. In game theory, the "prisoner's dilemma" comes to mind. bvs -----Original Message----- From: rtp-congestion-bounces@alvestrand.no [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of Michael Welzl Sent: Thursday, July 12, 2012 7:18 AM To: Bob Briscoe Cc: rtp-congestion@alvestrand.no; John Leslie; Matt Mathis; Bill Ver Steeg (versteb); Jim Gettys Subject: Re: [R-C] BoF approved Hi, Personally I think that the best we can do end-to-end, and a good possible scope, is: - avoid that RTP starves out elastic traffic as per Colin's proposal - *additionally* make sure that our transport keeps queues low in the absence of TCP traffic, or does not contribute more than necessary to queue growth - *additionally* avoid being starved by TCP traffic Combining all of these things should be possible. Yes, if there is a competing TCP, it will still push up the queues, but I think it should be outside the scope of this group to solve that. All with chair hat off, just bringing in my personal thoughts. Cheers, Michael On Jul 8, 2012, at 4:56 PM, Bob Briscoe wrote:
Matt,
Indeed - we can carve out any scope we want out of the wider scope of the whole problem space. My concern was that the argument for choosing the particular scope of RTP transport seemed based on some misunderstanding.
It would be perfectly valid to work solely on RTP transport if it was to make sure it doesn't starve out elastic traffic. This was the proposal from people like Colin Perkins, which was a sensible attempt to focus down the work (setting aside whether there is a feasible solution).
Bob
At 21:59 07/07/2012, Matt Mathis wrote:
I would like to point out that nobody has actually disagreed: If "fixing the network" means something like "deploy QoS" then yes it is absolutely out of scope. However "diagnosing (the lack of) QoS" is absolutely in scope. It should have the indirect effect of causing the former, irregardless of scope or who owns the problem.
Note that the Internet will almost certainly be better served by QoS metrics that are built into all applications and determined by their needs, rather than the intent of the QoS implementers.
And (I hope) we all agree that rtcweb can not directly fix network problems, no matter how well it performs.
Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay
On Sat, Jul 7, 2012 at 11:13 AM, Jim Gettys <jg@freedesktop.org> wrote: On 07/07/2012 01:35 PM, Bob Briscoe wrote:
Michael, Bill,
The proposed logic for focusing on the R-T transport is that network fixes will only be deployed piecemeal, so some parts of the Internet won't have the new functions in them, therefore any fix has to be done in the e2e transport. This sounds logical if you don't think too hard about it, but...
1/ If the chosen problem to address is that TCP flow(s) are running up to the tail of a slow buffer and causing delays and losses that make simultaneous r-t delivery quality poor, then no amount of improvement to RTP alone will fix this. The impairment would be caused by the TCP traffic even if the RTP flow(s) weren't there, so adding an RTP flow cannot /reduce/ impairments caused by other transports (unless it includes a magic anti-delay-sucking nano-worm).
Bob is exactly correct: no programming around bufferbloat will work for real time, no protocols magic will work that I can see.
Ledbat only works because you are trying to do the opposite: keep it from interfering with TCP. And even there, Ledbat stops working once AQM (e.g. CoDel) keeps the delays low. The inverse just won't work.
c.f. http://gettys.wordpress.com/2012/05/14/the-next-nightmare-is-coming/
And even a single TCP connection will do you in today.
For instance, if we added delay sensing to the R-T transport, it
will
sense delay, back-off and TCP will just continue, while the RTP starves itself (cf Vegas).
If TCP-induced impairment is indeed the chosen problem, then limiting the scope to R-T transport only will therefore achieve precisely nothing.
2/ If the chosen problem is to prevent an R-T transport doing harm to other elastic (TCP) traffic (or other R-T traffic for that matter), then focusing on RTP makes perfect sense.
3/ If problem #1 (preventing TCP harming RT) is in scope, then network changes are the *only* way to solve this aspect. They won't solve it anywhere but where they are deployed, but this is better than solution #1 (focus on R-T transport alone), which solves it precisely nowhere.
I think we must presume the network gets fixed. Broadband (and WiFi) are both broken well beyond real time standards required for good audio to be reliable.
The biggest parts of the bufferbloat problem (at least that we know today; we may be looking for keys under the lamppost) are the two common bottlenecks at the edge of the network. In your house, those are your broadband connection, and your WiFi hop (both sides of the WiFi hop; your operating system needs to be fixed too). Cellular wireless is somewhat similar, but also somewhat different.
I think the right strategy for rtcweb are two fold: a) making sure that everything works well for real time when the network has been fixed. cf. http://gettys.wordpress.com/2012/06/26/the-internet-is-screwed-up-and-how-to... b) detecting the problem, so that people know to go get it fixed, and which hops are broken. Preferably by pointing the finger to the offending component, so that it gets fixed, whether your operating system, your home router, your broadband cpe, your broadband head end.
So Bob is exactly correct on this; you can't engineer real time traffic around bufferbloat in today's broken internet by protocol magic. You can, however fix the broken components (and in your home, with care, do pretty well even today if you are clever). cf. http://gettys.wordpress.com/2010/12/13/mitigations-and-solutions-of-bufferbl... And you can come help fix the problem for real, in home routers, and elsewhere in the network. - Jim
Bob
At 16:03 07/07/2012, Michael Welzl wrote:
I agree.
It seems clear to me that the ability to work everywhere is the
top
goal of rtcweb; interactions with the network have to be considered, of course (any congestion control algorithm will have to consider queue behavior).
More below, in line:
On Jul 6, 2012, at 6:20 PM, Bill Ver Steeg (versteb) wrote:
I agree that this is not the right forum for discussing middlebox buffer management algorithms. I would add that even if the network elements do creep into scope, the host-based congestion control algorithms still have to work with the existing systems found in the wild. In other words, we could suggest that the middleboxes implement [insert your favorite AQM algorithm here]and [insert your pick of ECN, PCN, or maybe even Conex, etc] but the hosts still need to deal with [tail drop, RED, WRED, etc].
Stated another way, the algorithm is going to get a variety of congestion signals. When running on networks with primitive buffer management algorithms, one of those signals is going to be delay. On more modern systems, we can hope that the middleboxes' buffer management algorithms do not introduce persistent delay.
So, the RMCAT work will have to consider delay, packet loss and explicit packet markings. In a perfect world, the network will never give us persistent delay - but the world is rarely perfect.
Bill VerSteeg
-----Original Message----- From: rtp-congestion-bounces@alvestrand.no [ mailto:rtp-congestion-bounces@alvestrand.no ] On Behalf Of John Leslie Sent: Friday, July 06, 2012 11:38 AM To: Bob Briscoe Cc: rtp-congestion@alvestrand.no; Michael Welzl Subject: Re: [R-C] BoF approved
Bob Briscoe <bob.briscoe@bt.com> wrote:
At 11:41 06/07/2012, Michael Welzl wrote: > On 6/26/12 4:05 PM, Wesley Eddy wrote: >> The RMCAT BoF was approved to meet at IETF 84 in Vancouver.
From http://trac.tools.ietf.org/bof/trac/ : ] ] Transport ] ] RTP Media Congestion Avoidance Techniques (RMCAT) ] ] Description: WG-forming BoF on RTP congestion control ] Responsible AD: Wesley Eddy ] BoF Chairs: Michael Welzl and Colin Perkins ] Number of people expected to attend: 100 ] Length of session: 2 hours ] Conflicts to avoid: RTCWEB, AVTCORE, MMUSIC, ICCRG, CODEC, TSVWG, TCPM, ] CONEX, PCN, MPTCP, IPPM, CORE ] Webex: not sure ] Meetecho: not sure ] Mailing list: rtp-congestion@alvestrand.no ] I-Ds: http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-congestion/ ] http://datatracker.ietf.org/doc/draft-jesup-rtp-congestion-reqs/ ] Draft charter: ] http://www.alvestrand.no/pipermail/rtp-congestion/2012-May/000381.html ] Status: APPROVED
>> When it was discussed by the IESG and IAB, one topic that really >> needs to be clarified by/within the group is the scope of the >> mechanisms being developed. For instance, it needs to be more >> clear what stack the group wants to be chartered to operate on. >> Whether the group would be doing a mechanism that works for RTP >> itself, or a new SCTP mechanism will need to be very clear. > > I would like to get a grip on exactly *what* really *is* decided > regarding the way the stack looks. Which protocol over which > protocol(s) for which type of data. > ...
Michael,
Recall at the Paris ICCRG I asked the wider question of whether changes to the network are in scope.
Personally, for the sake of keeping focus, I would say it's out of scope.
This is Transport area, with Wes the expected Responsible AD.
That means Network-Layer isn't expected to be in-scope for the WG.
I would hope, however, that discussion of potential Network- Layer work which would be helpful would be in-scope for the BoF.
I know those proposing this believe the scope is v definitely e2e protocols only (at least, if not specified down to a specific e2e protocol), but the scope determines very greatly how much of the problem we're going to solve:
* If RTP-only, we don't solve TCP harming RTP, only the other way round (which is fine if that's the scope we want)
I don't understand that.
* If SCTP-only, I'm not sure what we solve?
I get the impression that SCTP-only is not an option.
* If we allow network to be in scope, we might be able to address bufferbloat-style issues, or perhaps good policer designs to protect apps from each other.
Good policer designs that work well with rtcweb would be cool to have, but why can't that be done e.g. in ICCRG?
I expect to do a rant at the Workshop on Congestion Control for Interactive Real-Time Communication July 28th, to the effect that this can't be solved at the Transport Layer only.
It looks as if enough of us will be there to discuss Bob's question.
I agree, but I think we should try to get consensus on some key issues earlier than that.
My personal opinion is that this w-g should be trying to solve
the
problem. And the problem has three halves: * RTP harming elastic * elastic harming RTP * network arbitrating between the two
Clearly the first needs to be in-scope for the WG.
IMHO the other two halves need to be discussed at the BoF.
If I understood it correctly, Matt Mathis argued that neither the first nor the second should be in scope. I'd like to hear some more views on that.
Having read RFC5434, I think a general goal, and the role of Colin and me, is to try to maximize consensus and minimize the amount of discussion-at-the-BOF beforehand. So naturally I disagree, for now, that these things need to be discussed there. Let's try to agree on as much as possible before it.
Cheers, Michael
________________________________________________________________ Bob Briscoe, BT Innovate & Design _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
Bob Briscoe, BT Innovate & Design
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
participants (3)
-
Bill Ver Steeg (versteb) -
Bob Briscoe -
Michael Welzl