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

[ken carlberg <[e-mail]>]

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

A good catch, which is appreciated, but no.  In previous versions of the draft, we had made a recommendation of using TFRC as *the* default CC algo discussed in rfc-6679.  The rationale was that there was some measure of implementation of TFRC and that we had an RFC to point to.  Feedback during meetings about this recommendation appeared to be in the form of tepid agreement and disagreement.  But our concerns about TFRC and the work ramping up for RMCAT made it seem that it was best to remove the recomendation and point to RMCAT.

As you will have noticed further into the reactions draft, we state a couple of times where in bringing up a type of reaction, we also bring up some issues to consider, but we refrain from giving specific recomendations.  Andas I stated to Bob, we can add more text (experience, best common practice, insights -- like what Ruediger brought up earlier in this discussion) on some of the various reactions we bring up.

So again, thanks for the catch and we scrub the abstract more cleanly next time.

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

I couldn't give a definitive answer to your question.  I think the answer comes from how the CC algo's in RMCAT are designed and the results we see in their simulation/implementation.

I think I've responded to the rest of your comments in a previous response to Bob's email.

cheers,

-ken


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