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

[Mirja Kühlewind <[e-mail]>]

Hi Nandita,

sorry for the delay but I'm now about to submit another version addressing your 
comments. Thanks for the review! See some comments below.

Mirja

On 25.11.2014 07:17, Nandita Dukkipati wrote:
> 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.

Thanks. Done.

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

Done.

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

I didn't change something here up to now because the idea was to give a high 
level overview in the section that starts with "Section 2..." and then provide 
further infos on the subsections, first talking about loss and then about ECN. I 
understand that this feels a little like jumping around but there is a structure 
and I don't really see how to organize this better..?


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

Done.


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

I now have the following:

    flight_bytes:      current flight size in bytes
    retransmit_bytes:  payload size of the retransmission

    At the first retransmission in a congestion event LEC is set:

       LEC = flight_bytes - 3*SMSS

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

    Then during the first RTT of the congestion event:

       For each retransmission:
          LEG += retransmit_bytes
          LEC -= retransmit_bytes

       For each ACK:
          LEC -= SMSS
	

    After one RTT:

       LEG += LEC

       (The LEC now estimates the number of outstanding bytes
       that should be ConEx L marked.)

    After the first RTT for each following retransmissions:

       if (LEC > 0): LEC -= retransmit_bytes
       else if (LEC==0): LEG += retransmit_bytes

       if (LEC < 0): LEG += -LEC

       (The LEG is not increased for those bytes that were
       already accounted.)

Is this better?

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

Done.

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

Done.

Mirja