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

[Michael Welzl <[e-mail]>]

Hi,


On Oct 26, 2012, at 6:01 PM, ken carlberg wrote:

> I'm sorry, but i think you need to take a little more time in  
> reading the related threads as well as the draft.

I have given the draft a close read. It should be self-contained.


>> I have read the document and only now got around to look at the  
>> thread. The view that I got from reading the document seems to  
>> match a lot of the criticism that this draft is receiving.
>>
>> One first concern is: the draft seems to consist of one  
>> recommendation (using TFRC),
>
> As I told Bob previously, the draft is *not* meant to be a  
> recommendation.  It is meant to discuss the various reactions that  
> can be used with ECN signaling -- and I'll add that we wanted to add  
> some insight as well.  And with respect to TFRC, we are *not*  
> recommending its use as the default CC algorithm as stipulated in  
> rfc-6679.  If you look carefully at the *end* of this paragraph...

"Not meant to be a recommendation": Here's the first sentence of your  
abstract:
"This document presents recommendations for response to Congestion  
Experience (CE) notifications by real time applications that have  
negotiated end-to-end support of Explicit Congestion Notification  
(ECN)."

So it's obvious that, upon reading it, I believe the draft is meant to  
be a recommendation, no?


>   However it should be noted that TFRC is only recommended for real- 
> time
>   media use with ECN response. TFRC is not recommended for non-ECN  
> paths
>   due to its loss based operation which leads to full queues with
>   maximised latencies. It is assumed that ECN markings will usually  
> occur
>   with lower queue occupancy and thus lower latency. However it is
>   understood that ECN marks may not provide for sufficiently low
>   latencies in some situations so other congestion control solutions
>   would be preferable.
>
> ...we state that "other congestion control solutions would be  
> preferable".  The paragraph is meant to be read and taken as a  
> whole. What we can do, based on Bob's initial feedback, is to add/ 
> alter the first part of the paragraph to reinforce the understanding  
> that TFRC is one example of a CC algorithm.

I got that. I agree, however, with Bob's point that you can't really  
expect ECN marking to lead to less delay (sure, AQMs might not follow  
RFC 3168, but that's rather speculative I guess? If it's not, a  
reference would be good).


>> and a ton of ideas (using DiffServ, using RSVP, using FEC,  
>> whatnot). I think that listing all the possible ideas of things one  
>> could possibly do in response to an ECN-mark is pretty pointless.  
>> Why not add NSIS? Why not change the packet size in response to  
>> ECN? Why not stop the flow if there is heavy congestion? And (rinse  
>> and) repeat? Why not change this in the codec, this in the codec,  
>> that in the codec? It's really an endless list!
>
> how many implementations by vendors have you seen of NSIS?  Which  
> vendors dynamically change packet size due to loss?  Perhaps I'm  
> long on the tooth, but I've seen *deployed* implementations (outside  
> of the research/academic lab) of diff-serv, RSVP, FEC, and CODECS  
> producing different load rates, along with a number of protocols  
> associated with these designs.  NSIS is an experimental protocol,  
> which I didn't feel comfortable including in the list, but if you  
> feel differently, I'll be happy to read any text you'd like to  
> propose.

My point was just that DiffServ, RSVP, .... looks like a list of  
random ideas to me. If your basis for presenting them as possible  
reactions to ECN is that they are deployed, then what you're  
presenting is a survey of deployed work, which may have its own merits  
- but then this should be listed as such, with appropriate references  
wherever possible.


>> So, why are the "ideas" only listed as such, and not as  
>> recommendations? Because you don't back them up with enough "meat"  
>> to make them recommendable. There's a ton of literature out there,  
>> on all these things - if you find something in it that lets you  
>> make a recommendation, go ahead, but as long as the things seem  
>> fishy to you, I would refrain from listing them because they end up  
>> being useless to the reader, too. (note, I have nothing against  
>> recommending things other than "let's just use TFRC", if this is  
>> convincingly written, based on citations to documents that make it  
>> clear that these things are indeed good ideas).
>
> see above.  And if your sole interest is to see a set of  
> recomendations, I would suggest writing your own document and I'll  
> be happy to review it with the same courtesy that you have shown.   
> But complaining about something that the document is not meant to be  
> is a bit pointless.

I agree with you that it's pointless to complain about something that  
the document is not meant to be.

This is really the key issue here, I don't understand the purpose of  
this draft. I mean, yes, you have clearly stated that this is a follow- 
on effort of RFC6679, but why should anyone read it, and what should  
that person learn from it?
It seems to me now that your draft is recommending one behavior and  
surveying some other implemented alternatives with a critical  
discussion of their value. Is that what it is? Then just state that.  
Personally, I'm not sure if the survey of implemented stuff is very  
useful unless it is an experience report, i.e. "this has been found to  
work well, as documented here..." and "this has been found to work  
poorly, as documented there...".


Cheers,
Michael