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

[ken carlberg <[e-mail]>]

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

   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.

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

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

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

we shall add more information about the simulation, and see about expanding its scope.  As for the scenario, yes, it is speciic because its reflective of what we've come across in the real world instead of simply an academic paper exercise.

<snip snip>

kindest regards,

-ken