Michael, Recall at the Paris ICCRG I asked the wider question of whether changes to the network are in scope. 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) * If SCTP-only, I'm not sure what we solve? * 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. 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 betw the two Bob At 11:41 06/07/2012, Michael Welzl wrote:

Hi all,

On 6/26/12 4:05 PM, Wesley Eddy wrote:

...

The RMCAT BoF was approved to meet at IETF 84 in Vancouver.

BoF chairs will be announced soon.

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.

Any information would be appreciated - ideally with references: "... because this is in draft XY" / "... because 5 companies already implement it this way, and it's going to be in draft Z" / "...because this is what everyone in rtcweb agrees on"

- something of that sort, please. Just to get an idea of where we now stand, and what consensus we can build upon.

Cheers, Michael

_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion

________________________________________________________________ Bob Briscoe, BT Innovate & Design

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.

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) * If SCTP-only, I'm not sure what we solve? * 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.

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.

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. ;^) -- John Leslie <john@jlc.net> _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion

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). 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. 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

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

Matt Mathis <mattmathis@google.com> 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.

"Deploy QoS" covers an awful lot of ground... I claim that deploying QoS can't fix the problem unless - the application knows how to invoke an appropriate QoS, and - there is at least one appropriate QoS deployed where it's needed. QoS has tended to "guarantee" a byte-rate, meaning that you get that rate or you get nothing. This is not quite the appropriate QoS. QoS also has difficulty working between providers. Only the intersection of QoS offerings of the different providers can be guaranteed. This isn't real close to the appropriate QoS: we kind-of-need something that can function -- however minimally -- at whatever airport a participant may be waiting at. So, IMHO, "deploy QoS" as a mantra isn't a near-term solution. (What near-term may mean is left to an exercise to the student!)

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.

I agree -- but how do we get there?

And (I hope) we all agree that rtcweb can not directly fix network problems, no matter how well it performs.

RTP-congestion work is NOT limited to RTCWEB. Please recall our BoF is called "RTP Media Congestion Avoidance Techniques". -- John Leslie <john@jlc.net>

On 7/8/2012 11:13 PM, Mo Zanaty (mzanaty) wrote:

John Leslie <john@jlc.net> wrote:

...

RTP-congestion work is NOT limited to RTCWEB. Please recall our BoF is called "RTP Media Congestion Avoidance Techniques".

Trying to avoid specifics to talk to the general issues:

Is there consensus on this first critical point?

1. Some folks are using RTP and RTCWEB interchangeably.

They shouldn't. We need solutions for both, but as a (largely) green-field rtcweb may be able to implement things sooner (or with more ubiquity) than general RTP applications.

2. Some folks are assuming the work is limited to new protocols only (like maybe RTCWEB and CLUE), as evidenced by proposals to consider SCTP.

I would not assume that, but it may be easier to deploy in those environments per above, or they may add constraints that help solutions for those areas.

3. Some folks are assuming all RTP applications are in scope. 4. Some folks are assuming interoperability with existing RTP applications are also in scope.

yes - but gaining benefits for existing apps without any change by them is unlikely except via network changes. With changes, existing apps may be able to more fully take part.

I disagree with 1+2. Does anyone disagree with 3+4?

-- Randell Jesup randell-ietf@jesup.org

On 2012-07-09 05:13, Mo Zanaty (mzanaty) wrote:

John Leslie <john@jlc.net> wrote:

...

RTP-congestion work is NOT limited to RTCWEB. Please recall our BoF is called "RTP Media Congestion Avoidance Techniques".

Is there consensus on this first critical point?

1. Some folks are using RTP and RTCWEB interchangeably. disagree. They should not really. 2. Some folks are assuming the work is limited to new protocols only (like maybe RTCWEB and CLUE), as evidenced by proposals to consider SCTP. Of course,this work includes RTCWEB and CLUE but not limited to those. 3. Some folks are assuming all RTP applications are in scope. Not all RTP applications are included. I think the updated WG charter (https://sites.google.com/a/alvestrand.com/rtp-congestion/bof-planning-page/w...) clearly excludes some. 4. Some folks are assuming interoperability with existing RTP applications are also in scope. It cannot be expected that any new Congestion Corntrol (CC) feedback from an application implementing an upcoming RTP congestion control WG specs can be understood by existing RTP application. It also cannot be expected that non-standard CC feedback from existing RTP applications are understood by upcoming WG specs compliant applications. The only thing that can be expected is that the upcoming WG solution have fallback mechanism to work with existing RTP application using standard mechanism such as RTCP SR/RR. The upcoming WG solution should also consider that fact that there could be application out in the Internet which falls in to real-time interactive category but does not adapt at all.

I disagree with 1+2. Does anyone disagree with 3+4?

Mo

BR -- Zahed ============================================ ANM ZAHEDUZZAMAN SARKER Ericsson AB Multimedia Technologies (MMT) Ericsson Research P.O. Box 920, SE-971 28, Luleå, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ============================================

Hi, I'm getting a bit lost here, see below: On Jul 18, 2012, at 3:06 PM, Mo Zanaty (mzanaty) wrote:

Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> wrote:

...

The only thing that can be expected is that the upcoming WG solution have fallback mechanism to work with existing RTP application using standard mechanism such as RTCP SR/RR. The upcoming WG solution should also consider that fact that there could be application out in the Internet which falls in to real-time interactive category but does not adapt at all.

About the latter sentence, in which way do you suggest that the WG should consider that fact?

Agreed. The fallback mechanism should be something better than the RTP circuit breakers draft. Some basic level of congestion control should be possible, and specified, when interoperating with existing RTP applications. That is, specify behavior in the absence of some (or perhaps all) feedback. There will be a long transition period as current adaptive and non-adaptive RTP applications migrate to the new congestion control standard (if/when that happens), so it is important to understand and specify interoperation for these cases.

Just to be clear, what is the scenario you're envisioning? An application where one side does new-rmcat-congestion-control and the other side doesn't, and the new side has to make the most out of the feedback that it gets from the other? Cheers, Michael

On 7/21/2012 4:46 PM, Mo Zanaty (mzanaty) wrote:

Michael Welzl <michawe@ifi.uio.no> wrote:

...

Just to be clear, what is the scenario you're envisioning? An application where one side does new-rmcat-congestion-control and the other side doesn't, and the new side has to make the most out of the feedback that it gets from the other? Right.

Since RTP flows are typically negotiated, it may be reasonable to assume that the rmcat-capable side knows it's talking to a non-rmcat-capable source (or even without negotiation, that it will know quickly). Or the behavior could be turned on by the first exchange of RTCP feedback messages specific to rmcat - there are a number of options. -- Randell Jesup randell-ietf@jesup.org

This happens all the time today. All widely deployed video communication products/services have some form of adaptive rate behavior, usually employing a combination of standard and proprietary feedback. When you mix vendors, only the standard feedback works. But the response to standard feedback is not standardized, so you get different behavior/rates on each side. RMCAT should avoid this chaos by specifying behavior in the absence of some or all of the newly standardized feedback, which will look just like unknown proprietary feedback to the non-RMCAT side. We should first focus on getting the right standard in place for RMCAT on both sides. But then we should also specify interop behavior with non-RMCAT peers. Mo -----Original Message----- From: rtp-congestion-bounces@alvestrand.no [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of Michael Welzl Sent: Sunday, July 22, 2012 9:01 AM To: Randell Jesup Cc: rtp-congestion@alvestrand.no Subject: Re: [R-C] BoF approved On Sun, 22 Jul 2012 08:40:32 -0400, Randell Jesup <randell-ietf@jesup.org> wrote:

On 7/21/2012 4:46 PM, Mo Zanaty (mzanaty) wrote:

...

Michael Welzl <michawe@ifi.uio.no> wrote:

...

Just to be clear, what is the scenario you're envisioning? An application where one side does new-rmcat-congestion-control and the other side doesn't, and the new side has to make the most out of the feedback that it gets from the other? Right.

Since RTP flows are typically negotiated, it may be reasonable to assume that the rmcat-capable side knows it's talking to a non-rmcat-capable source (or even without negotiation, that it will know quickly). Or the behavior could be turned on by the first exchange of RTCP feedback messages specific to rmcat - there are a number of options.

So I'm trying to understand how one could recommend a specific behavior for such a case. We are facing a situation where we may not get enough feedback. Say, we get way too little feedback: the IETF-conformant (TCP-friendly) thing to do, then, is to assume loss and react by at least halving the send rate. This may not be attractive for the application at all, depending very much on the content and on the likelihood that missing feedback is due to the other side sending little vs. loss from the network. All in all, I'm having trouble imagining that some reasonable general behavior can be recommended for this case. Cheers, Michael

On 2012-07-21 12:16, Michael Welzl wrote:

Hi,

I'm getting a bit lost here, see below:

On Jul 18, 2012, at 3:06 PM, Mo Zanaty (mzanaty) wrote:

...

Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> wrote:

...

The only thing that can be expected is that the upcoming WG solution have fallback mechanism to work with existing RTP application using standard mechanism such as RTCP SR/RR. The upcoming WG solution should also consider that fact that there could be application out in the Internet which falls in to real-time interactive category but does not adapt at all.

About the latter sentence, in which way do you suggest that the WG should consider that fact?

My thinking below- 1. The WG's should provide behavior guidelines for the standard compliant side when communicating with non-compliant side. It's task should not stop by only specifying new signals and behaviors where both side follows them. I understand that there could be lots of ways one endpoint becomes non-compliant and it will be tricky to cover all. Thus the WG should define how one endpoint becomes non-compliant and then simple guideline for the compliant endpoint about what to do with it. This is necessary otherwise people will try to solve it in their own ways and will result in lots of different solution to same problem. 2. When evaluating new solutions, WG should include the case where other flows sharing the same bottleneck node do not adapt at all but falls into same real time traffic category. How much the non adaptive flows will contribute to the congestion is an open question though. I believe at some point this to be formed WG will have to converge to some measurable figures to evaluate the proposed CC mechanism.

...

Agreed. The fallback mechanism should be something better than the RTP circuit breakers draft. Some basic level of congestion control should be possible, and specified, when interoperating with existing RTP applications. That is, specify behavior in the absence of some (or perhaps all) feedback. There will be a long transition period as current adaptive and non-adaptive RTP applications migrate to the new congestion control standard (if/when that happens), so it is important to understand and specify interoperation for these cases.

Just to be clear, what is the scenario you're envisioning? An application where one side does new-rmcat-congestion-control and the other side doesn't, and the new side has to make the most out of the feedback that it gets from the other?

yes, but it will be hard if the other endpoint does not use standard form of feedback for example standard RTCP SR/RR. As I believe if you don't understand the feedback you are receiving from other endpoint you can make nothing out of it. But the new-rmcat-congestion-control could very well include new as well as old standard congestion control feedback.

Cheers, Michael

-- Zahed ============================================ ANM ZAHEDUZZAMAN SARKER Ericsson AB Multimedia Technologies (MMT) Ericsson Research P.O. Box 920, SE-971 28, Luleå, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ============================================

Hi, just a short note on LEDBAT. LEDBAT will behave similar to TCP reno (maybe slightly slower increase) if the queue is too small to induce TARGET ms extra delay. Mirja On Saturday 07 July 2012 20:13:54 Jim Gettys 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-t o-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-bufferb loat-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: 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

-- ------------------------------------------------------------------- Dipl.-Ing. Mirja Kühlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de -------------------------------------------------------------------

Michael Welzl <michawe@ifi.uio.no> wrote:

...

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.

From RFC5434: ] ] In many cases, however, the intent is to form a WG. In those cases, the ] goal of the BOF is to demonstrate that the community has agreement that: ] ] - there is a problem that needs solving, and the IETF is the right ] group to attempt solving it. IMHO this is already given: alas, the problem is ill-defined... ] - there is a critical mass of participants willing to work on the ] problem (e.g., write drafts, review drafts, etc.). ] ] - the scope of the problem is well defined and understood, that ] is, people generally understand what the WG will work on (and ] what it won't) and what its actual deliverables will be. This needs work. IMHO it will need work _at_ the BoF. ] - there is agreement that the specific deliverables (i.e., ] proposed documents) are the right set. ] ] - it is believed that the WG has a reasonable probability of ] having success (i.e., in completing the deliverables in its ] charter in a timely fashion). Generally this is easy enough if the deliverables are properly defined. (This tends to require work before the BoF...)

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.

Restoring the context:

Bob Briscoe wrote:

...

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

John Leslie wrote:

Clearly the first needs to be in-scope for the WG.

IMHO the other two halves need to be discussed at the BoF.

Alas, I need to guess what Michael disagrees _with_... I guess he disagrees that the BoF needs any discussion of how * elastic traffic might harm RTP, and * network-layer might arbitrate between the two. Basically, I claim these two questions are insufficiently understood; thus I think some discussion at the BoF will be needed. -- John Leslie <john@jlc.net>

On Jul 8, 2012, at 7:54 PM, John Leslie wrote: [snip]

...

] - there is a critical mass of participants willing to work on the ] problem (e.g., write drafts, review drafts, etc.). ] ] - the scope of the problem is well defined and understood, that ] is, people generally understand what the WG will work on (and ] what it won't) and what its actual deliverables will be.

This needs work. IMHO it will need work _at_ the BoF.

To be clear, I meant it will need work at the BoF whether or not participants on this list find a consensus before then.

...

...

Bob Briscoe wrote:

...

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

John Leslie wrote:

...

Clearly the first needs to be in-scope for the WG.

IMHO the other two halves need to be discussed at the BoF.

"elastic harming RTP" might not be the right focus, exactly... When there is "TCP-friendly" elastic traffic at the bottleneck, it currently "harms" RTP traffic by driving up the delay. That much _needs_ to be understood to work on our problem at all. The "fault" isn't with the elastic traffic exactly: TCP congestion control depends on filling buffers to the point where packet loss occurs, whether by tail-drop or Active Queue Management or any other algorithm. In the "extreme," we call this buffer-bloat. But we only need about 100 milliseconds of buffer latency to perceptably "harm" RTP traffic. That much (IMHO) needs to be presented to the BoF. IMHO, it's a central part of the "problem" this BoF is convened to discuss. To some degree, QoS can help; the CoDel proposal could help a lot; possibly just a user-visible warning that competing traffic is driving up buffer latency would help. Or perhaps there's some different "mode" of RTP to switch to when latency grows too long... A BoF doesn't start with a charter -- it tries to draft a charter for a WG. The BoF starts with a problem statement and _possibly_ a proposed charter. IMHO proposing a charter is premature until the problem is better understood. "network arbitrating between the two" is quite close to the right focus. QoS arbitration is one appropriate way to do this. The RTP flow could request a particular bandwidth to go to the head of the queue at a point of congestion; but somebody would need to say how to do so, and there'd have to be equipment deployed to accept the request. This is practical if the congestion is only at the uplink from the customer to the ISP; but it may be less practical for congestion at the downlink from ISP to customer; and it's probably impractical for congestion somewhere in the middle. CoDel definitely deserves some discussion at the BoF. It would accomplish most of what QoS could promise without any need for a protocol to request dedicated bandwidth. It still needs deployment to routers where the congestion occurs; but IMHO such deployment is eminently practical for both uplink and downlink to the customer. (Deployment in the middle seems less necessary, but could follow _after_ the benefit is well demonstrated for the relatively few near-backbone routers that ever delay (as opposed to drop) traffic for 100 milliseconds.) "Mode" switching may well deserve some consideration in any case. (Separate arguments could be made for wireless-induced delay: I won't treat that here...) Michael Welzl <michawe@ifi.uio.no> wrote:

Your phrasing was "need to be discussed at the BoF", which I took to mean that we can't agree about these things beforehand.

I've already answered that, but I'm seeing less convergence than (IMHO) is needed. :^(

I think we can, and I think we should try.

I quite agree we should try... -- John Leslie <john@jlc.net>

My take on the BoF scope of work is fairly straightforward (I believe): - We're preparing to deploy a new set of RTP applications on the Internet. - There are Really Stupid Things that could happen if we don't do congestion control: - Internet Congestion Collapse (transmitting lots of packets and getting no useful throughput) - Random self-unfairness, where some channels in an app get good quality and other channels get bad quality, independent of what the app would prefer - Random unfairness to others, where you can't predict the behaviour of the call or of others' traffic even when you know the conditions it's operating under - I'm sure this list could go on for a while.... - Most previous deployments were (in practice) closed systems, and could do proprietary things. This one is intending to be open-standars-based, and depends on interoperability. Thus, the focus of the WG that comes out of the BOF should be on: - Getting something documented publicly that, if we all do it, prevents the most abysmally Stupid Things - Getting metrics defined that let us diagnose whether we're in trouble or not - Getting feedback from actual deployment that allows us to figure out whether we need to improve Note that the word "optimal" doesn't occur in the above. We should stop being Really Bad before we worry about being Really Good. (The fact that we're piggybacking deployment on the modern browser product cycle has certain advantages: Essentially, we can replace the entire installed base over a timescale of months. So the stuff that we learn from the first experience (which will certainly arrive ahead of an IETF-process-timescale standard!) can be fed back into the next generation of product fairly quickly.) In my opinion, the BoF scope of work is to nail down the charter for the WG that allows us to accomplish this. The architectural issues, half-baked ideas and orthogonal approaches (like "change the way queueing is done in the Internet") will all have been discussed in Saturday's IAB workshop, and lots of possible ideas for work in other parts of the IETF may be coming from that. This BoF needs to focus on the WG charter for documenting "interoperable ways of avoiding stupid behaviour". My opinion. Harald

Agreed. The BoF isn't about solving the problem. It's about agreeing what the problem is, and defining a charter for a working group to solve that problem. Colin On 18 Jul 2012, at 11:07, Harald Alvestrand wrote:

My take on the BoF scope of work is fairly straightforward (I believe):

- We're preparing to deploy a new set of RTP applications on the Internet.

- There are Really Stupid Things that could happen if we don't do congestion control: - Internet Congestion Collapse (transmitting lots of packets and getting no useful throughput) - Random self-unfairness, where some channels in an app get good quality and other channels get bad quality, independent of what the app would prefer - Random unfairness to others, where you can't predict the behaviour of the call or of others' traffic even when you know the conditions it's operating under - I'm sure this list could go on for a while....

- Most previous deployments were (in practice) closed systems, and could do proprietary things. This one is intending to be open-standars-based, and depends on interoperability.

Thus, the focus of the WG that comes out of the BOF should be on:

- Getting something documented publicly that, if we all do it, prevents the most abysmally Stupid Things - Getting metrics defined that let us diagnose whether we're in trouble or not - Getting feedback from actual deployment that allows us to figure out whether we need to improve

Note that the word "optimal" doesn't occur in the above. We should stop being Really Bad before we worry about being Really Good.

(The fact that we're piggybacking deployment on the modern browser product cycle has certain advantages: Essentially, we can replace the entire installed base over a timescale of months. So the stuff that we learn from the first experience (which will certainly arrive ahead of an IETF-process-timescale standard!) can be fed back into the next generation of product fairly quickly.)

In my opinion, the BoF scope of work is to nail down the charter for the WG that allows us to accomplish this. The architectural issues, half-baked ideas and orthogonal approaches (like "change the way queueing is done in the Internet") will all have been discussed in Saturday's IAB workshop, and lots of possible ideas for work in other parts of the IETF may be coming from that.

This BoF needs to focus on the WG charter for documenting "interoperable ways of avoiding stupid behaviour".

My opinion.

Harald

_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion

-- Colin Perkins http://csperkins.org/

Cullen Jennings <fluffy@iii.ca> wrote:

... Part of the purpose of a BOF to figure out what the scope of the work is and where to do it.

Exactly! It is perfectly possible for a BoF to be scheduled under one Area, but lead to forming a WG in a different Area. (IMHO, we would be ill-served by refusing to discuss work needed in an Area other than Transport.) There _is_ appropriate work within the Transport Area; but work in the Internet Area might turn out to be the critical path. -- John Leslie <john@jlc.net>

Michael Welzl <michawe@ifi.uio.no> wrote:

I think that we all want to work with RTP itself. Actually it was me who started with that all-over-SCTP idea, and I did that in thinking that the scope would be for rtcweb and nothing but rtcweb.

I now understand that the scope can be broader than that, and would like to see it broader, just like pretty much everyone else, it seems to me. Because of that, I would like to undo my all-over-SCTP proposal back. I think it's a bad idea because it limits everything we do to the rtcweb scope alone.

I believe that we probably have consensus about that. Does anyone disagree?

I don't really want to disagree (yet, anyway), but there were benefits that came from your coordinated-SCTP-congestion-control paradigm; and I'd rather not let those go right yet. I'm optimistic that the Saturday IAB workshop will enlighten us on how to think about these problems... -- John Leslie <john@jlc.net>