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

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

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