[conex] Comments on WGLC for draft-ietf-conex-tcp-modifications-06

[Nandita Dukkipati <[e-mail]>]

Mirja and Richard,

Thanks! for the draft. Some comments below:

* Introduction

"First congestion information have to be extracted from loss or ECN
feedback in TCP as described in section 3"... ".
Remove the extra quotes.

*
"It is therefore recommend to use the SACK extension when using TCP with ConEx."
It is therefore recommended...

* " This document describes congestion accounting for both TCP with
and without the Selective Acknowledgment (SACK) extension [RFC2018] in
section 3.1.
...
The detailed mechanism to respectively set the L bit in response to
loss- based congestion feedback signal is given in section 4.1."

"The congestion accounting for both, with the classic ECN feedback as
well as a more accurate ECN feedback are explained in detail in
section 3.2 while the setting of the E bit in response to ECN-based
congestion feedback is again detailed in section 4.1."

This jumps around around describing Section 3.1 -> Section 4.1 ->
Section 3.2 -> and back to Section 4.1

Suggestion is to consolidate to keep all the Section 3 material by
itself and Section 4 material by itself.

Also the last three paragraphs of the Intro. seem disconnected with
the rest. The para starting with "Section 2 provides an overview of
the needed modifications for TCP senders to implement ConEx..."
already laid out the Section contents.

* Accounting Congestion
Reword the first sentence.

A ConEx sender maintains two counters: one that accounts congestion
byte-wise based on the congestion information received by loss
detection, and a second that accounts for ECN based congestion
feedback.

* 3.1.1 Without SACK Support

The last para of Section 3.1.1:

"At this point of time in the transmission, in the worst case, all
packets in flight minus three that trigged the dupACks could have been
lost.  For each retransmission that is sent, the LEG will still be
increased but the LEC will also be decreased by the payload size of
the retransmission.  During the following RTT, LEC should be reduced
by SMSS for each ACK that is received.  Thus after one RTT the LEC
estimates the number of outstanding bytes that should be ConEx L
marked.  To not further delay this information, now LEG should be
increased by LEC.  From then on every following retransmission should
only reduce the LEC and not increase the LEG until the LEC is zero, as
those bytes were already accounted."

Have you considered putting the above in a pseudo code:

On a retransmission:
    XXX

On receipt of ACK:
    XXX

* 5.  Loss of ConEx information
"Of course also packets..."
-> Packets carrying ConEx can also get lost.

6.  Timeliness of the ConEx Signals
nodewith -> node with
avoiad -> avoid