Re: [tcpm] A review for draft-ietf-tcpm-rack-09

[Yuchung Cheng <[e-mail]>]

On Tue, Aug 18, 2020 at 6:42 AM Gorry Fairhurst <[e-mail]>
wrote:

> I have read draft-ietf-tcpm-rack-09 in preparation for TCPM to publish
> this document, and do have some comments. I note that this new rev is
> much easier to read this time, so thanks for the significant work to
> produce a clear spec, and I see also that you have already addressed my
> major concerns - thanks. (I'll separately catch a set of minor editorial
> notes on this rev).
>
Thank you for the review!


>
> (1) I don’t understand this clause:
> “  3.  The RACK reordering window SHOULD leverage that to adaptively
> estimate the duration of reordering events, if the receiver uses
> Duplicate Selective Acknowledgement (DSACK) [RFC2883].”
> - What does “leverage that” actually mean?
> - Might it mean something like: can be increased if the sender receives
> a Duplicate Selective Acknowledgement (DSACK) [RFC2883], that suggests
> the window is too small, and has resulted in spurious retransmission." …
> or does it mean something different?
>
It means exactly what you said :-)

Here is the latest rev based on Theresa' suggestion:
"The RACK reordering window SHOULD adaptively increase if the sender
receives the Duplicate Selective Acknowledgement (DSACK) [RFC2883],
suggesting the window is too small which causes spurious retransmission."

Let me know if that's better?




>
> (2) I did not understand this part in Section 3.3:
> “However, the fact that the initial reordering window is low, and the
>     reordering window's adaptive growth is bounded, means that there will
>     continue to be a cost to reordering to disincentivize excessive
>     network reordering over highly disjoint paths.  For such networks
>     there are good alternative solutions, such as MPTCP.“
> - Is this intended to read as /reordering that disincentivizes excessive/
> - If that was intended, the spec appears to be for a single path, MPTCP
> would still view this path with reordering as a single path, so I do not
> understand how MPTCP helps unless the awareness of the disjoint paths is
> somehow known at the endpoints? Please explain.
>
> - (You’d need a REF for MPTCP if you keep this senetnce and the
> explanation).
>
Yes that's the intention. Will removing the last sentence (about MPTCP)
help?


>
> (3)
>   Question in Section 7.4.2.
> /If the TLP
>     sender does not receive such an indication, then it SHOULD assume
>     that either the original data segment or the TLP retransmission were
>     lost, for congestion control purposes./
> - Why is this not a MUST?
> - Under what conditions would it be safe to ignore a SHOULD?
>
We use SHOULD because the ACK could be lost instead of the data, so if the
sender has some mechanism to detect ACK losses well, it may be safe not to
assume data was lost.

But I agree this is over-thinking the corner cases so how about

If the TLP sender does not receive such an indication, then it *MUST*
assume that either the original data segment, or the TLP retransmission
were lost*, or their ACKs* are lost for congestion control purposes.


>
> (4) in Section 6.2. I was also left with a potential concern about
> “min_RTT” with respect to “a simple global minimum of all RTT
> measurements from the connection”.  This method results in a significant
> path change from low to high RTT exhibiting an invalid RTT. Even a
> simple windowed min-filtered estimate - mentioned here - would avoid
> this effect on reordering detection.
>
> - I’d prefer adding a short sentence  so people know why the updates to
> min_RTT might be useful.
>
Good point. (some) windowed-filter is definitely prefered. how about:

The sender SHOULD track a windowed min-filtered estimate of recent RTT
measurements to adapt migrating to significant longer paths, compared to a
simple global minimum of all RTT measurements.




>
> (5) In section 8.1, I expected more discussion of the potential
> disadvantages (even if the authors seem to suggest these are not
> significant) :
>
> * I still was left without understanding whether there is an impact from
> a path with a varying RTT (perhaps one that uses a link layer
> retransmission or access technology). My feeling is that if there is
> excessive variation the method could go wrong when the RTT increases,
> but I wonder if this is usually captured by inflating the SRTT and that
> more excessive variation is not common. I think this case should be
> discussed briefly.
>
AFAIU the scenario you are referring is when the link-layer retransmitted
packets took a much longer > current SRTT to be delivered. Then RACK
reordering window (and its SRTT-bound) requires DSACK and new RTT
measurement to raise to capture this variation. Depending on the RTT
variation, it may take multiple round trips to adapt to. The idea is for
short flows, RACK may not be able to cope with it (and we welcome any
simple idea to improve that). For long flows, RACK should eventually adapt
to these high varying RTT. Hence we've tested RACK with high varying degree
of reordering (in time) in synthetic benchmarks. In production experiments,
we have not found such high variation too common tho: the wireless radio
does not alter its transmission rate too often or change its retry count
dynamically. But of course, we try to avoid any mention of "empirical case
frequency" :-)

It that addresses your question, we can add some words in the reordering
design rationale about this.


> * As I read it, RACK can also send more retransmissions after there has
> been loss, where it is making spurious retransmissions - from timer
> events, or as a result of multiple segments from a single TSO segment
> being retransmitted. While it seems to be argued these are not
> significant, it could none the less a disadvantage in some scenarios,
> and should be captured in section 8.1.
>
The first case spurious RACK timer expiration is possible. So we can append
to the end of 8.1 with
"Another disadvantage is the reordering timer may expire prematurely (like
any other retransmission timer) to cause higher spurious retransmission
especially if DSACK is not supported".

However RACK should not cause extra spurious retransmission with TSO (vs
non-TSO) as a loss detection algorithm. Perhaps some text in TSO was not
clear on this?


>
> * Also there seem cases where RACK allows TCP to continue to increase
> the congestion window upon receiving ACKs after loss, making the sender
> more aggressive. This is noted in 8.3, but I think should be listed in
> the disadvantages in 8.1.
>
Section 8.3 clearly states RACK can make C.C. more aggressive. Disadvantage
or not depends on how one looks at  it. IMO really beyond the scope of this
doc.


>
> (6) Section 8.4 talks about ACK loss or a delayed ACK without a DSACK,
> but does not mention Stretch ACKs, which have also been experienced, and
> need some form of mention!
>
There are two kinds of stretched ACKs I knew of: (a) ACKs delayed by the
receiver in hope to accumulate more.  (b) ACKs "compressed" or decimated by
the receiver or middle-boxes. It's the former (a) that affects RACK so we
use delayed ACK in the general delayed stretched ACK form.


>
> (7) Why isn't TCP-NCR (RFC4653) at least mentioned and discussed in the
> intro?
>
It is briefly mentioned in
https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-2.2 and
discussed a bit more in
https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-8.2


> Gorry
>
>
>