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

[[e-mail]]

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.

-- 

>
>
>> 1) Maybe add one sentence saying "A connection is also in non-validated
>> phase if
>> pipeACK is zero which means the connection is idle". Saying this explicit
>> would
>> help me to understand things better.
>> - Idle isn’t quite correct, what it means is no new data was ACK’ed -
>> there could be data sent and pending ACK/ We changed 4.5.2 to clarify
>> this.
>>
>> I just notice that this might actually not be true because in the section
>> above
>> you say that pipeACK is set to undefined if no measurements are available
>> and
>> that would mean the connection goes into validated phase... okay I think
>> there
>> is some clarification needed here.
>> - see above
>
>
> Just to make sure again that this is right. From understanding the
> document currently says, that if there are no measurements for a
> certain time, pipeACK will be undefined and if pipeACk is undefined
> the connection is in validated phase. That means as soon as a
> congestion gets idle and has no measurements anymore it will go into
> validated phase without any adjustments…
>
> I believe this sentence is wrong (in 4.3):
>
> "Validated phase: pipeACK >=(1/2)*cwnd, or pipeACK is undefined.“
>
> It should be:
>
> "Validated phase: pipeACK >=(1/2)*cwnd, or the connection just started
> and therefore pipeACK is undefined.“
>
>

Section 4.3:

OLD:
Validated phase: pipeACK >=(1/2)*cwnd, or pipeACK is undefined.

NEW:
Validated phase: pipeACK >=(1/2)*cwnd, or pipeACK is undefined (at the
start or directly after loss recovery).
---

In fact you're right, the "no measurement" condition only occurs at the
start or after a loss detection (this was contradicted in the intro,
thanks
for noting this):

Section 4.2:

OLD:
When no measurements are available (e.g., a sender that has been idle will
have sent no data and received no ACKs), the pipeACK variable is set to
the "undefined value".

NEW:
When no measurements are available (e.g., a sender that has just started
transmission or immediately after loss recovery), the pipeACK variable is
set to the "undefined value".

---

When no measurement are available during a transmission without losses,
the idle period are ignored as explained in 4.5.1, which is equivalent to
set pipeACK samples to zero.
>
> The text between brackets in the 5th par of sec 4.2 should be changed to:
>
>    When no measurements are available (i.e. when the connection is
>    started or after pipeACK
>    was invalidated following loss detection),  the pipeACK variable is
>    set to the "undefined value".
>
I think it would also be useful to add a sentence (see below) in 4.5.1
that explicitly calls out what happens in idle in the implementation example.

Section 4.5.1, example:

OLD:
    There was also a
    period of inactivity between samples B and C during which no
    measurements were taken (because no new data segments were
    acknowledged).
NEW:
    There was also a
    period of inactivity between samples B and C during which no
    measurements were taken (because no new data segments were
    acknowledged). During this period the pipeACK samples
    may be regarded as zero, and hence do not contribute to the
    calculated pipeACK value.

>
>> 5) "ssthresh is adjusted using the standard TCP method."
>>    This is not clear to me. Is ssthresh set to cwnd/2 before the
>> adjustment or
>> to cwnd-1 after the adjustment? The first option would restart the
>> connection in
>> Slow Start... Please clarify!
>> - We use the standard method, with no change.
>
>
> The problem is I don’t know what you mean by standard method. RFC5681
says
>
> "ssthresh = max (FlightSize / 2, 2*SMSS)“
>
> If that is what you want, the please refer to RFC 5681.
>
> However, I think don’t think that this is what you want because this
> would mean that the connection usually starts in Slow Start.
>
> I guess you actually want to set ssthresh=cwnd-1.
>
>
We actually referred to the FR/FR algorithm in Sec 3.2 of RFC 5681.
In step 6 there is a method that assigns ssthresh=cwnd at the end of the
recovery.

Section 4.4.1:

OLD:
ssthresh is adjusted using the standard TCP method.

NEW:
The ssthresh is adjusted using the standard TCP method (Step 6 in Section
3.2 of RFC 5681 assigns the ssthresh a value equal to cwnd at the end of
the loss recovery).
---


>
>> 2) "An application that remains in the non-validated phase for a period
>>    greater than the NVP is required to adjust its congestion control
>>    state.  If the sender exits the non-validated phase after this
>>    period, it MUST update the ssthresh:"
>>
>>    This is not fully clear to me. Do I have to adapt cwnd and ssthresh
>> right
>> after NVP or as soon as I leave the non-validated phase after being for at
>> least
>> NVP time in this phase? If I'm not idle, but only sending with a low rate,
>> I
>> should probably do this adjustment with the next ACK, no...?
>> - Not sure of the difference, e hope the new intro helps with this.
>
>
> I think this was me thinking of the implementation of this: do I need
> a timer or just need to remember the time when I entered the
> non-validated phase. I guess there is actually no difference in the
> algorithm. So that’s fine as it is!
>
Yes, there is no difference.

Section 4.5.1:
--- This section contained a note at its end to illustrate how to
implement the method without using OS timers. To make this more clear, the
text has been re-written as a separate implementation consideration, as
below:

REPLACEMENT:

The method requires a number of measurements of time. These measurements
could be implemented using protocol timers, but do not necessarily require
a new timer to be implemented. Avoiding the use of dedicated timers can
save operating system resources, especially when there may be large
numbers of TCP flows.

The NVP could be measured by recording a timestamp when the sender enters
the non-validated phase. Each time a sender transmits a new segment, this
timestamp can be used to determine if the NVP has expired. If the measured
period exceeds the NVP, the sender can then take into account how many
units of the NVP have passed and make one reduction (XREF) for each NVP.

Similarly the time measurements for collecting pipeACK samples and
determining the Sampling Period could be derived by using a timestamp to
record when each sample was measured, and to use this to calculate how
much time has passed when each new ACK is received.


>>
>> 3) Further, these adjustments mean that the connection will be in Slow
>> Start. If
>> I understand this correctly, this is not a problem as long as the
>> connection
>> stays in non-validated as the cwnd will not be further increased. But as
>> soon as
>> it leaves non-validated phase it will increase its cwnd as in Slow Start.
>> I
>> would like to have this spelled out explicitly.
>> - ???
>
>
> The adjustment in section 4.4.3 will (usually) lead to ssthresh>cwnd
> at the end of the non-validated period. That means the connection is
> in Slow Start. If this is intended, please add one sentence says:
> „These adjustment will set the connection in Slow Start (as ssthresh >
> cwnd).“
>
That's correct. We added that sentence. Note that this also
happened in RFC 2861 after one RTO idle period.

Section 4.4.3, Note:

OLD:
Note: This adjustment ensures that the sender responds conservatively...

NEW:
Note: These cwnd and ssthresh adjustments cause the sender to enter
slow-start (since ssthresh > cwnd). This adjustment ensures that the
sender responds conservatively...
---

>
>
> Thanks,
> Mirja
>
>
>