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

[ken carlberg <[e-mail]>]

Bob,

> 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,

yes and no.  In RMCAT, and what its trying to accomplish, I would wholeheartedly agree.  How this is done can still be an open question, but we are in agreement that this approach is reasonable.  Another approach to take is to simply key off the presence of congestion (loss, or CE feedback) and swap codecs to one that produces an average lower tx rate without reliance on a particular CC algo.  Now, before you express your heartburn at that idea, I'm not advocateing (or recommending :-) this idea.  I'm just pointing out what others are considering.  There is an ITU document being written on this approach, and I'm waiting for it to sttle down a bit before I include it as a reference.

And i know in a previous response to Piers that you're not keen on citing work from outside the IETF.  But I think we want to do this so that "our" community is aware of what's being proposed, or can be considered, so that we can provide our own response (like this is a bad idea for these specific reasons, blah, blah, blah).

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

again, the purpose of the reactions draft is to point out one's options and not be solely constrained with CC algorithms.  I do agree what what you say above, and this should find its way in another more focused document in RMCAT.

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

well, we could split the "other responses" into a subsection that describes a less aggressive CC algo into section 3, and a rationale behind it. I need to give this more thought. 

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

I think what is missing in those sections is more discussion about the pro's and con's of the various approaches.  For example, (a) the need for, and difficulty in achieving, transitive trust between nodes under different administrative control for diff-serv code points, or on the other hand (b) the added value of adding markings to packets that could influence downstream traffic engineering on an as-needed basis.  I prefer to stay away from recomendations because that can be entirely scenario and user-group specific.  

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

agreed, these are corner cases.  But I'm inclined to come across these corner cases in real life, and i think we make a mistake in ignoring them.  They do exist, but just not in the scale that many others come across.

cheers,

-ken