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

[Piers O'Hanlon <[e-mail]>]

Hi,

Thanks for your comments on the draft. Since Ken has addressed most of your issues I thought I'd add a reference in response to your question on RED and media flows below.

On 27 Oct 2012, at 09:54, Michael Welzl wrote:
[snip]

>> ...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).
> 
There has been some work done in this area - see for example:
J.M. Pitts, X. Wang, Q. Yang, and J.A. Schormans, Excess-rate queuing theory for M/M/1/RED with application to VoIP QoS, IET Electronics Letters, 28 September 2006, Vol. 42, No. 20, pp.1188-1189
http://academic.research.microsoft.com/Publication/26843304/excess-rate-queuing-theory-for-m-m-1-red-with-application-to-voip-qos



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