Subject: Re: [tcpm] Review of draft-ietf-tcpm-accecn-reqs-02

From: Bob Briscoe <[email-masked]>
Date: Tue, 13 Aug 2013 23:31:56 +0100

Richard, Mirja,

As promised, my detailed review of draft-ietf-tcpm-accecn-reqs-03 is here:
<http://bobbriscoe.net/projects/2020comms/accecn/>

I have written my suggested changes as mods to the XML source of the 
draft merely for convenience. Pls feel free to copy & paste from my 
XML, to accept or reject each change. I have provided a diff against 
the original draft-03, which will be the best way to read the suggestions.

Most of the changes are editorial - you've often tended to use a 
German-like sentence structure. It's understandable to an English 
eye, but it doesn't really flow in English. In a number of places, 
I've also tried to explain what I think you were meaning a little better.

Superficially it looks like a total re-write, but it's not really. 
Unfortunately, the large number of editorial suggestions have caused 
the more significant (e.g. technical) changes to become swamped. So I 
have tried to list the main changes I have suggested here:

* Suggested 'fine-grained' would be a better term than 'more 
accurate' throughout.
* Suggested to add paras introducing ConEx & DCTCP to the Intro
* Suggested adding more motivation to Intro, esp interoperation 
between DCTCP implementations.
* Suggested adding explanation of why it's not so bad to re-use the 
nonce bits (in IP & TCP headers)
* Suggested shifting certain requirement sentences that I thought 
were not under the most appropriate requirement bullet
* Suggested adding more specific requirements relating to delayed acks
* Suggested adding requirements on backward & forward compatibility 
(including shifting some sentences that were under other headings 
into this one).

__________________
Finally, there were a couple of sentences I thought were incorrect, 
so I suggested deleting or altering them. If you intended them to be 
this way, pls explain:

"While classic ECN provides a reliable (inaccurate) feedback of a 
maximum of one congestion signal per RTT, the proposed schemes do not 
implement any acknowledgement mechanism." [They do.]

"Providing wrong feedback information could otherwise lead to 
throttling of certain connections." [I would have thought certain 
connections would go faster than intended, not be throttled?]

Bob

At 08:15 07/08/2013, Michael Welzl wrote:
>Hi all,
>
>I second what Bob says below. Let's avoid having various proprietary 
>signaling methods for the same thing deployed and instead 
>standardize a single one.
>
>Cheers,
>Michael (W)
>
>
>On 6. aug. 2013, at 17:26, Bob Briscoe wrote:
>
> > Michael,
> >
> > I plan to do this in the next few days.
> > I will produce a rev of the xml, so the authors can use any text 
> directly (or not).
> >
> > The main things I plan to add, other than editorial stuff, is to 
> motivate standardisation for interoperation:
> > * Although DCTCP was presented at the IETF, a protocol spec has 
> not being offered for standardisation so far
> > * DCTCP is becoming widely deployed and it uses a non-standard 
> TCP wire protocol for feedback
> > * The way the Windows 8 DCTCP negotiates use of this non-standard 
> TCP feedback protocol is proprietary and unspecified
> > * We do not want widespread deployment of a proprietary TCP 
> feedback negotiation protocol to burn up the few remaining flags or 
> options so that de facto they become unavailable for use in standards.
> > * The feedback protocol used in the Windows 8 DCTCP assumes no 
> losses and quickly gets very confused about ECN feedback if there 
> are losses as well
> > * Other implementations of DCTCP (Linux, FreeBSD) seem to be 
> inventing their own different feedback protocols
> > * These different wire protocols have not been specified to 
> interwork with each other - they all seem to assume that the other 
> end is using the same implementation
> >
> >
> > However, I want to properly investigate the ground truth under as 
> many of these statements as I can first (I've done most of them).
> >
> >
> >
> > Bob
> >
> > At 15:40 06/08/2013, Scharf, Michael (Michael) wrote:
> >> Hi all,
> >>
> >> According to our minutes, you volunteered in the TCPM meeting to 
> review draft-ietf-tcpm-accecn-reqs-02. The TCPM chairs appreciate 
> this a lot, since this document didn't get a lot of feedback recently.
> >>
> >> It would really help if you could have a look at the document 
> and post your thoughts to the TCPM mailing list. We are 
> specifically interested whether the problem statement and the 
> requirements are complete. It would also be of interest if the 
> survey of the design approaches misses something.
> >>
> >> Again, thanks a lot for volunteering!
> >>
> >> Michael
> >
> > ________________________________________________________________
> > Bob Briscoe,                                                  BT

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: Michael Welzl <[email-masked]>
Date: Sun, 25 Aug 2013 13:24:04 +0200

Ahhh, sorry, it went to tcpm-chairs, not tcpm… my bad, I didn't see the mistake in the receiver address, thanks for noticing!!
So I'm cc'ing tcpm now, as has always been my intention, sorry again!

Michael

On Aug 23, 2013, at 7:54 PM, "Scharf, Michael (Michael)" <[email-masked]> wrote:

> Hi Michael,
> 
> Thanks!
> 
> Have you shared this very useful review with the authors? (Possibly also with the list?)
> 
> Michael
> 
> 
>> -----Original Message-----
>> From: Michael Welzl [mailto:[email-masked]] 
>> Sent: Monday, August 12, 2013 3:34 PM
>> To: [email-masked]
>> Subject: Re: Review of draft-ietf-tcpm-accecn-reqs-02
>> 
>> Hi all,
>> 
>> On 6. aug. 2013, at 16:40, Scharf, Michael (Michael) wrote:
>> 
>>> Hi all,
>>> 
>>> According to our minutes, you volunteered in the TCPM 
>> meeting to review draft-ietf-tcpm-accecn-reqs-02. The TCPM 
>> chairs appreciate this a lot, since this document didn't get 
>> a lot of feedback recently.
>>> 
>>> It would really help if you could have a look at the 
>> document and post your thoughts to the TCPM mailing list. We 
>> are specifically interested whether the problem statement and 
>> the requirements are complete. It would also be of interest 
>> if the survey of the design approaches misses something.
>>> 
>> Here's my review! Answering your questions about completeness 
>> of the problem statement and requirements, I think so.
>> My comments are mostly editorial. Here they are, section by 
>> section - sorry that they're a mix of nits (many) and 
>> slightly more important things (not so many).
>> 
>> Secondly, a disclaimer about English: I'm not an English 
>> speaker, so I might be criticizing things that are in fact 
>> okay, as I always try to suggest something that I know to be 
>> correct in case of doubt. More feedback is better than less, 
>> I guess, so here it goes, all of it:
>> 
>> 
>> Abstract:
>> 
>> don't think feedback can be used as a word. General fix: 
>> search "feedback X" and change to "feed X back" (e.g. problem 
>> is also in intro)
>> 
>> "more accurate ECN feedback information" seems redundant, 
>> enough with "...ECN feedback" or "...ECN information"
>> 
>> last sentence: requirement_s_
>> 
>> 
>> Intro:
>> 
>> "A sender using DCTCP congestion control and 
>> s/supports/supporting ConEx:"
>> 
>> next item (standard TCP sender) - I'd remove this, it seems 
>> quite unnecessary here.
>> 
>> Next par: "deliver identical performance" seems strange to 
>> me, as it's just a signaling scheme - I'd say "as much 
>> information" or "provide the same signal" or something like that.
>> 
>> 
>> sec. 1.1:
>> 
>> last par: "more congestion marks belong_ing_ to the same overload..."
>> 
>> 
>> sec 2:
>> 
>> par 2: s/This leads always/This always leads last line of par 
>> 2: should be "can not _be_ signaled back..."
>> 
>> next par, last line: "nonce sum is maintain_ed_ that counts..."
>> 
>> 
>> sec 3:
>> 
>> item resilience:
>> "in most cases only every second data packet triggers an 
>> ACK." isn't precise, in most cases it's *at most every second 
>> data packet*, but it could well be less.
>> last line of this par: "take delayed ACK_s_ and ACK loss..."
>> 
>> next par:
>> s/out dated/outdated
>> "high dynamic" - didn't get what this means and it sounds 
>> wrong. Maybe best to stop the sentence before "due to..."
>> 
>> next par: "should be provided how a machanism" - the "how" 
>> seems wrong somehow, maybe "on how" would be correct. Later 
>> same sentence: "re-ensure" can just be replaced by ensure to 
>> be clearer.
>> 
>> next par: "congestion event(remove "s") occurs at least one..."
>> 
>> next par: The very first sentence ("Of course, the more 
>> accurate..") seems strange and out of place, I'd suggest to 
>> remove it. Second, it's a bit odd that all the items are 
>> positive except for the last two (complexity and overhead - 
>> I'd suggest to replace "Complexity" with "Simplicity" and 
>> "Overhead" with "Coding efficiency").
>> 
>> next par: "prepared to s/proved/provide a method to fall-back 
>> to well known RFC3160 signaling (remove comma) if the new signal..."
>> 
>> 
>> sec 4:
>> 
>> last line: "any acknowledgement mechanism." -  I think *I* 
>> understand what you mean: that they don't acknowledge back 
>> from the sender to the receiver, like normal ECN does with 
>> CWR. However, given that there is a lot of talk about ACKs 
>> everywhere, this bit could be hard to understand, and I'd 
>> rather phrase this clearer (maybe simply say "do not 
>> implement reliable signaling").
>> 
>> 
>> sec 4.1 and 4.2:
>> 
>> This is so full of mistakes that I'm actually faster 
>> copy+pasting the corrected text here, so here it goes, with 
>> my fixes marked:
>> 
>> **********
>>   The three ECN/NS header *flags*, ECE, CWR and NS are 
>> re-used (not only for
>>   additional capability negotiation during the TCP handshake exchange
>>   but) to signal the current value of *a* CE counter at the receiver.
>>   This approach only provides ** ["a" removed] limited 
>> resilience against ACK *loss*
>>   depending of the number of used bits.
>> 
>>   There are several codings proposed so far: *A* one bit scheme sends
>>   one ECE for each CE received (while ** ["the" removed] CWR 
>> could be used to
>>   introduce redundant information in *the* next ACK to increase the
>>   robustness against ACK loss).  An 3 bit counter scheme 
>> uses all three
>>   bits for continuously feeding *back* the three most 
>> significant bits of a CE
>>   counter ** ["back" removed].  *A* 3 bit codepoint scheme 
>> encodes either a CE counter
>>   or an ECT(1) counter in 8 codepoints.
>> 
>>   The proposed schemes *provide* accumulated information on ECN-CE-
>>   marking feedback, similar to the number of acknowledged 
>> bytes in the
>>   TCP header.  Due to the limited number of bits the ECN feedback
>>   information will wrap-around more often (than the acknowledgement).
>>   [I don't understand this bracket and suggest removing it.]
>>   Thus with a smaller number of ACK losses it is already possible to
>>   loose feedback information.  The resilience could be increased by
>>   introducing redundancy, e.g. send each counter increase 
>> twice or more
>>   times.  Of course any of these additional mechanisms will increasee
>>   the complexity.  If the congestion rate is larger *than* 
>> the ACK rate
>>   (multiplied with the number of feedback *signals* 
>> ["information" cannot be counted I think] that can be
>>   *transmitted* per ACK), the congestion information cannot 
>> correctly be
>>   *fed* back.  Thus an accurate ECN feedback mechanism needs 
>> to be able
>>   to also cover the worst case situation where every packet is CE
>>   marked.  This can potentially be realized by dynamically 
>> *adapting* the
>>   ACK rate and redundancy which again increases complexity and also
>>   potentially the signaling overhead.  For all schemes, an integrity
>>   check is only provided if ECN Nonce can be supported.
>> 
>> 4.2.  Use of Other Header Bits
>> 
>>   As seen in Figure 1, there are currently three unused 
>> *flags* ["bits" removed] in
>>   the TCP header.  The proposed 3 bit or codepoint schemes could be
>>   extended by one or more bits ["," removed] to add higher 
>> resilience against ACK
>>   loss.  The relative gain would be proportionally higher resilience
>>   against ACK loss, while the respective drawbacks would remain
>>   identical.
>> 
>>   Moreover, the Urgent Pointer could be used if the Urgent 
>> Flag is not
>>   set.  As this is often the case, the *resilience* could by 
>> increased
>>   without additional signaling overhead.
>> 
>> *********
>> 
>> sec 4.3:
>> 
>> There is the following sentence here "E.g. ECN for RTP/UDP 
>> provides explicit (should be "explicitly provides") the 
>> number of ECT(0), ....". I was waiting for such a statement 
>> to appear much earlier! Here it is out of place, it should be 
>> move to somewhere in the introduction, and it needs a 
>> reference to RFC 6679. Similarly, SCTP counts the number of 
>> ECN marks, and that should also be stated with a reference to 
>> the RFC or draft specifying it. Putting this in the 
>> introduction is valuable I think, as it makes it it clear 
>> that this functionality is really only missing in TCP, it's 
>> already there in SCTP and RTP/UDP!
>> 
>> "ECN feedback is not such a critical information": remove "a" 
>> before "critical", and "not such" doesn't sound good I 
>> think... it's also a rather imprecise statement. Maybe "not 
>> extremely critical information" would be better? I don't like 
>> that one very much either but it's the best I can come up 
>> with right now.
>> 
>> 
>> sec 7: par 1 starts with "this scheme" => which scheme?? The 
>> draft only discusses schemes. You could say "schemes that 
>> signal more precise ECN information" here. In sentence 2 you 
>> also say "those schemes" which is strange now but would okay 
>> if you fix sentence 1.
>> 
>> 
>> Finally, the last 5 references are not cited in the text. 
>> AFAIK it's bad style to add references but not cite them - if 
>> you don't cite them they are unnecessary.
>> 
>> 
>> That's all folks - I hope it's helpful!
>> Michael
>>