Re: [tsvwg] draft-carlberg-tsvwg-ecn-reactions -- which WG?

[Bob Briscoe <[e-mail]>]

Ken,

Now I understand where you're coming from (which wasn't clear BTW) I 
can start to bite on your question...

Changing codecs is driven by a cc algo, it's just an algo with a 
discrete output, not a continuous output. One can think of it like an 
internal continuous rate-vs-congestion response that drives step rate 
changes - once it has remained below or above a codec-change 
threshold for sufficiently long. Sometimes they are actually written 
like that. Other times they are driven by hi/lo watermarks in the 
playout buffer.

But these are cc algorithms all the same. So if you think cc algos 
should go in RMCAT, then this should, because that is the main meat 
of this draft.

Indeed, I imagine most of the RMCAT output will be targetted at 
codecs with discrete steps in spatial & temporal resolution.

THe emergency comms section (5.3) is merely a different degree of cc 
response, so it ought to be under "CC ALgos" (section 3), not "Other 
responses" (section 5).

On the other kitchen sink of responses (triggering RSVP, Diffserv, 
Redundancy, FEC etc), I'm with Michael W. If you're just listing what 
implementers might do, then it has little value. If you're 
recommending what implementers shouldn't do or what they should, it 
would be worth keeping these. But none of these other responses you 
list seem to be that prevalent, important or practical.

If a codec isn't using RSVP, but the going gets tough part-way 
through, calling to RSVP for help would be a bit like a ship-wreck 
victim praying for a miracle to save them :) If RSVP is available on 
a particular network (<1% chance), and specific apps have been 
written to use it but they start-out not using it (<1% * <1%), I 
don't see it will help commentating on that remote possibility in this draft.

Similarly, nowadays, nearly always where Diffserv is used, the 
network decides to apply the markings at the edge, not the host. So 
if there were a case where the network took account of host-initiated 
Diffserv markings (<1% chance), and specific apps have been written 
to use it but they start-out not using it (<1% * <1%), I don't see it 
will help commentating on that remote possibility in this draft.

And I've already said the ECN + (Redundancy or FEC) items are pretty 
much corner-cases too.


Bob

At 12:25 25/10/2012, ken carlberg wrote:
>Bob,
>
>a good bounceback question.
>
>It wasn't our intention to say that "TFRC is good eough if you've 
>got ECN".  The main point we wanted to make is that TFRC exists now, 
>but there are some issues and that is being addressed in RMCAT in 
>the form of requirements and potentially new CC algorithms.  So 
>we'll need to fix our text to convey this properly.  Also, if our 
>draft was that narrowly focused, then yes, we'd move the Reactions 
>draft to RMCAT and probably fold that into one fo the deliverables 
>in the RMCAT charter.
>
>In writing RFC-6679 (ECN for RTP over UDP), the authors agreed that 
>a default approach of using a CC algorithm is what is needed to 
>reduce load when congestion is signaled.  Later on, I came across 
>some carriers (as well as some vendors) who were of the mind set 
>that they have a preference to swap codecs to one that produced less 
>load instead of using a CC algorithm.  From my perspective, this is 
>outside the scope and intent of RMCAT, and yet its a perfectly 
>reasonable approach to consider.  And discussions with others 
>brought up the ideas of on-demand invocation of FEC and RSVP as a 
>means of further protecting certain flows.   From my perspective, 
>this is outside the scope and intent of RMCAT, and yet its a 
>perfectly reasonable approach to consider.  In addition, sets of 
>users not responding to ECN would seem to be at the fringe of RMCAT's charter.
>
>And so we use the title "Reactions to ECN" to purposely be broad in 
>scope and not just focused on CC algorithms reactions to ECN.  That 
>is why I think this document should stay with TSVWG.  Piers and I 
>will also be participating in RMCAT, so we'll be sure to bring up 
>items that can contribute to the discussion and advancement of RMCAT.
>
>cheers,
>
>-ken
>
>
>On Oct 24, 2012, at 2:16 PM, Bob Briscoe wrote:
>
> > Ken,
> >
> > Perhaps we could bounce this question back to you: what is the 
> main single take-home message you want us to get from this draft? 
> THat should decide which WG it's in.
> >
> > I believe the primary message is "TFRC is good enough if you've 
> got ECN, so we can get started without RMCAT if we have ECN." I 
> don't think that's true (as I have been arguing on the list), but I 
> think that's the message the draft is wanting people to hear most. 
> If that were the case, then TSVWG would be reasonable.
> >
> > I would have thought the impact of users not responding to ECN 
> would be just as much in scope for RMCAT as TSVWG (and ConEx is 
> where policing/non-compliance is most being addressed, which is the 
> other side of this problem).
> >
> > Regarding FEC, I think this is a bit of a corner-case in this 
> draft, so I wouldn't decide which WG based on that.
> >
> >
> > Bob
> >
> > At 14:15 23/10/2012, ken carlberg wrote:
> >> Hi,
> >>
> >> I've been asked publically and privately about my thoughts as to 
> where this document should end up -- TSVWG or RMCAT.  When the 
> question was first brought up I was indifferent because I could see 
> a case for both.  However, when I thought about it for a while, I 
> felt more comfortable advancing this through TSVWG.
> >>
> >> The reason for this line of thoughts is that only a portion of 
> the ECN Reactions draft deals with congestion control 
> algorithms.  And while RMCAT talks about the generic term of 
> "mechanisms" in its charter, the heart of the charter and 
> deliverables seems to focus on algorithms, which is really just one 
> type of mechanism.  On the other hand, the Reactions draft looks 
> into other "mechanisms" like FEC, signaling, and most importantly, 
> the impact of a set of users not responding to ECN.  And its this 
> last item where we bring in some simulation work and is probably 
> the strongest reason (ie, the simulation results) as to why its 
> beneficial to have this in an IETF document.  And its these other 
> items that seem out of scope of RMCAT.
> >>
> >> Assuming this draft is accepted as a working group item in 
> TSVWG, I would also want to send the document to RMCAT for review 
> when we get to a WG last call for comments stage, though I sure the 
> core set of folks will be attending both sets of meetings and mailing lists.
> >>
> >> If folks feel I've missed something, please don't be shy in 
> letting us know :-)
> >>
> >> -ken
> >
> > ________________________________________________________________
> > Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design