[R-C] BoF approved

[Mirja Kuehlewind]

Hi Bob,

independent if the question if RTP will harm TCP or the other way around, I'd 
say one important aspect is to have any kind of congestion for RT 
communication to avoid a congestion collapse. This is independent of QoS. 

But, yes, if we do some work here, it would be nice to also get it right in 
respect to QoS. From my point of view this can only be done if behavior of 
legal TCP congestion control and network elements is in scope.

Mirja


On Saturday 07 July 2012 19:35:47 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).
>
> 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 at alvestrand.no
> >>[mailto:rtp-congestion-bounces at alvestrand.no ] On Behalf Of John Leslie
> >>Sent: Friday, July 06, 2012 11:38 AM
> >>To: Bob Briscoe
> >>Cc: rtp-congestion at alvestrand.no; Michael Welzl
> >>Subject: Re: [R-C] BoF approved
> >>
> >>Bob Briscoe <bob.briscoe at 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 at 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 at 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 at ikr.uni-stuttgart.de
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------