Re: [tcpm] WGLC for draft-ietf-tcpm-rack-08 - 3 issues

[Gorry Fairhurst <[e-mail]>]

I reviewed the latest version of RACK as a part of the TCPM WGLC and 
this email contains 3 points I think are more important for the WG to 
consider.

(1) Why re-specify the DupACK Thresold?

I have a question why does RACK need to say this, effectively 
over-riding any future change to the DupACK threshold:
“then RACK SHOULD honor the classic 3-DUPACK rule for initiating fast 
recovery.”.
I suggest:
“then RACK SHOULD honor the
        classic DUPACK rule for fast recovery as specified in [RFC5681].”
and later:
“and use of the 3-DUPACK rule” rather than “DUPACK Rule [RFC5681]”.
- If that spec changes, I think RACK should also. I do not see the 
reason to restrict this to the constant three for the purpose of RACK.

—
(2) Can the document be clearer about how RTTs are used and what happens 
on paths where the RTT varies significantly?

“The RACK reordering window MUST be bounded and this bound SHOULD
        be one round trip.”
- Which round trip estimate? Is the smoothed RTT, the RTO? the last 
measured RTT? I think this needs to be explained, because it also 
appears later

“  Since an ACK can also acknowledge retransmitted data packets, and
    retransmissions can be spurious, the sender must take care to avoid
    spurious inferences.  For example, if the sender were to use timing
    information from a spurious retransmission, the RACK.rtt could be
    vastly underestimated.”
- ‘must take care’? is that “needs” or if not, what does “take care” 
really mean?
- Why ‘vastly’ - I would have thought that was possible,  but doesn’t 
the problem emerge when any underestimate is present. Please clarify by 
removing “vastly” or explaining this.
—
    “Use the RTT measurements obtained via [RFC6298] or [RFC7323] to
    update the estimated minimum RTT in RACK.min_RTT.”
- I don’t see either of these specifications define a minimum RTT. I 
understand that QUIC doesn’t have a way to maintain an accurate minimum 
RTT,  how does a sender determine the minimum RTT?
- Considering robustness to path changes, how does the minimum RTT take 
into account the variation of the path RTT?
- How does this relate to RTO Consider 
(https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-10), which 
appears to place strong demands on timers tracking variance and path 
changes?
—
** “In such cases RACK may not detect losses from
    ACK events and the recovery would then resort to the (slower) TLP or
    RTO timer-based recovery.  However, such events should be rare and
    the connection would pick up the new minimum RTT when the recovery
    ends, so the sender can avoid repeated similar failures.”
- I’d strongly suggest changing that “may” to “could” to be really clear 
this is not permitting something.
- I’m also not sure how a sender would know that “such events should be 
rare” - isn’t that dependent on path characteristics?
—
“"To be more robust to reordering, RACK uses a more conservative RTT 
value to decide if an unacknowledged packet should be considered lost, 
RACK.rtt"
-
- Why is this not normative? I think this is either a SHOULD or a MUST?

There's suggestions that much of this may be covered in various places, 
and that could just need editorial work? As I noted before in the 
working group, I do like the idea of RACK, but I do have concerns about 
what happens on paths where there is a large variation in the RTT. With 
a DUPACK-based recovery the variability extends the recovery time, and 
RTO inflates - both are safe. I do not have any feeling that a sender 
would not be overly aggressive when used over a widely varying path RTT.

This seems like it is not safe unless you include a variance term in the 
RTT, or as an enabling function to using the method.

I really do think this has to be explained and addressed.

—
(3)

There are places where the text explcitly motivates a change to the 
network forwarding behaviour, saying almost that this is an allowed 
outcome of deploying RACK for TCP.

Section 4 in particular is a concern:

" The reordering behavior of networks can evolve (over years) in

    response to the behavior of transport protocols and applications, as
    well as the needs of network designers and operators.  From a network
    or link designer's viewpoint, parallelization (eg. link bonding) is
    the easiest way to get a network to go faster.  Therefore their main
    constraint on speed is reordering, and there is pressure to relax
    that constraint.  If RACK becomes widely deployed, the underlying
    networks may introduce more reordering for higher throughput. "
and later:
"  This handles reordering caused by path divergence in small time
    scales (reordering within the round-trip time of the shortest path),
    which should tolerate much of the reordering from link bonding,
    multipath routing, or link-layer out-of-order delivery."

As explained in TSVWG (within the context of L4S), my own opinion is 
that it would be good to have greater tolerance to reordering and that 
the presence of paths with significant reordering is a motivation for 
that work.

Beyond that, I would urge much caution: Writing anything that could 
suggest RACK enables greater reordering has implications on a wide range 
of IETF protocols and would represent a very significant change in 
advice for the network. I would even suggest that such advice is wrong, 
until methods such as RACK have been deployed in transports as a whole, 
not just TCP. I also think this sort of advice and reasoning does not 
belong within the specification of a protocol mechanism.

Gorry