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

[Michael Welzl <[e-mail]>]

Hi all,

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

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

As for the simulation study, this looks pretty useless. It doesn't  
have enough details to be repeatable (e.g., the queue length is  
missing, and "RED parameters as recommended by Sally Floyd" isn't  
quite telling us all we need to know, either (e.g., gentle mode used  
or not?) ). As Bob has pointed out, it's also only one specific  
scenario, omitting other possible situations... if the point of  
documenting a simulation is just to illustrate a case with numbers to  
be able to explain them better, then that may be okay to have in a  
draft, but if the point is to justify a decision, as here, this would  
be better published in a paper, after peer review, and then cited, I  
think.

So, now I can get to what Bob wrote below - this message seems to be  
the most fitting one to answer:

If we could agree on removing ideas and sticking with just  
recommendations, then:

On Oct 24, 2012, at 8: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.

...this would be true, but:


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

indeed, I would have thought that too.


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

FEC is just one of the ideas I talk about above, and, as such, should  
be removed IMO.

Cheers,
Michael

PS: a nit: section 3: you can't say that "TCP congestion control ...  
favours reliability over timeliness."  TCP does, but this is not its  
congestion control.