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

[ken carlberg <[e-mail]>]

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