Re: [tcpm] Comments on draft-ietf-tcpm-newcwv-11

["Gorry (erg)" <[e-mail]>]

Thanks for this. 

We have submitted Rev 12 that incorporates these changes and minor language improvements. The editors think this is now ready for the IESG to review.

Gorry


> On 9 Jun 2015, at 13:46, Mirja Kühlewind <[e-mail]> wrote:
> 
> Hi Gorry,
> 
> thanks for taking care of this. All changes are great and now makes things absolutely clear to me. Please go ahead and submit.
> 
> Mirja
> 
> P.S.: The text below says somewhere "(Sect XX)"; that should probably be still replaced; just that you don't overlook it. And maybe also put a name in for the new reference.
> 
> 
> 
>> On 05.06.2015 17:16, [e-mail] wrote:
>> 
>> Mirja,
>> 
>> Raffaello and I have looked at these comments and we think they do help,
>> please find below suggested improvements to address these comments.
>> Please do check first that we have covered all things, and we'll then
>> revise and submit with all the changes.
>> 
>> Best wishes,
>> 
>> Gorry & Raffaello
>> 
>>> Mirja:
>>> 
>>> -------------------------------------------------------------------
>>>> 
>>>> pipeACK (section 4.1 and 4.2 and 4.5.1):
>>>> 1) Can you maybe add a sentence that explains why FlightSize is not
>>>> sufficient.
>>>> I understand the difference between the two variables but are there
>>>> actually
>>>> cases where it makes a big difference if one or the other is used?
>>>> - Added to section 1.
>>> 
>>> 
>>> That’s also good. But what I meant was: Why do you use pipeACK in your
>>> algorithm? I believe in most cases if you would use FlightSize instead
>>> of pipeACK, your algorithm your work the same way. Can you further
>>> explain when this is not the case.
>> We think that FS can give an under-estimation of capacity during recovery,
>> when recovering the end of a burst, and can over-estimate capacity when
>> the sender has been previously idle. This is because FS only measures
>> segments in flight, whereas pipeACK measures segments actually transferred
>> across the path.
>> 
>> To help explain places this can make a difference we suggest to add back
>> the following from the list discussion (A version of this text appeared in
>> the notes, which would be removed for publication, we suggest the above
>> edited version should be included in the RFC.) We think this would be
>> better included in the final document.
>> 
>> After final para in 4.2:
>> 
>> NEW:
>> 
>> NOTE: The use of pipeACK rather than FlightSize can change the behaviour
>> of TCP when a sender does not always have data available to send. One
>> example is when there is a pause in transmission after sending a sequence
>> of many packets, and the sender experiences loss at or near the end of its
>> transmission sequence. In this case, the TCP flow may have used a
>> significant amount of capacity just prior to the loss (which would be
>> reflected in the volume of data acknowledged, recorded in the pipeACK
>> variable), but at the time of loss the number of unacknowledged packets in
>> flight at the end of the sequence may be small (i.e., there is a small
>> FlightSize). After loss recovery, the  sender resets the congestion
>> control state.
>> 
>> [Fai12] explored the benefits of different responses to congestion for
>> application limited streams. If the response is based only on the Loss
>> FlightSize, the sender would assign a small cwnd and ssthresh based only
>> on the volume of data sent after the loss. When the sender next starts to
>> transmit it can incur may RTTs of delay in slow start before it reacquires
>> its previous rate. When the pipeACK value is also used to calculate the
>> cwnd and ssthresh (Sect XX), the sender can use values that also reflects
>> the recently used capacity before the loss. This prevents a variable-rate
>> application from being unduly penalised. When the sender resumes, it start
>> at one half its previous rate, similar to the behaviour of a bulk TCP flow
>> [Hos15]. This method requires that pipeACK variable to be reset after it
>> is used in this way to ensure an appropriate reaction to on-going
>> congestion.
>> 
>> --
>> 
>> [Hos15] PhD Thesis, A Study of Mechanisms to Support Variable-rate
>> Internet Applications over a Multi-service Satellite Platform, School of
>> Engineering, University of Aberdeen.
> 
> -- 
> ------------------------------------------
> Dipl.-Ing. Mirja Kühlewind
> Communication Systems Group
> Institute TIK, ETH Zürich
> Gloriastrasse 35, 8092 Zürich, Switzerland
> 
> Room ETZ G93
> phone: [phone]
> email: [e-mail]
> ------------------------------------------