[tcpm] Review: draft-ietf-tcpm-fastopen-07 and sharding

[Bob Briscoe <[e-mail]>]

Yuchung & co-authors,

Thx for the new draft.
* The more specific text in "6.1 Duplicate Data in SYNs" is better, thx.
* I'm happy with the text about the initial congestion window too.

I don't want to hold up this draft any further. However, I would 
prefer the IESG to see the following text about cookie-in-FIN in the 
draft. It raises the concern about sharding, and provides a potential 
solution if it becomes a problem.

I've also added some nits, that could be dealt with at the same time.

4.2.1
OLD:
    An alternate proposal is to request cookie in FIN instead since FIN-
    drop by incompatible middle-box does not affect latency. However such
    paths are likely to drop SYN packet with data later, and many
    applications close the connections with RST instead, so the actual
    benefit of this approach is not clear.
SUGGESTED:
    An alternate proposal is to request a TFO cookie in the FIN instead,
    since FIN-drop by incompatible middle-boxes does not affect latency.
    However paths that block SYN cookies may be more likely to drop a
    later SYN packet with data, and many applications close a connection
    with RST instead anyway.

    Although cookie-in-FIN may not improve robustness, it would give
    clients using a single connection a latency advantage over clients
    opening multiple parallel connections. If experiments with TFO find
    that it leads to increased connection-sharding, cookie-in-FIN may prove
    to be a useful alternative.
REASONING:
* The previous dismissal of cookie in FIN said what these boxes were 
likely to do, but gave no evidence, so I've made it more circumspect.
* When I originally proposed cookie in FIN, I gave two reasons for 
it, but the main one seemed to get overlooked - the advantage that 
TFO in SYN gives to sharding clients.
* I also improved the English.

NITS
====

Section 4.2.2
OLD:
    6. Advance to the SYN-RCVD state. If the FastOpened flag is set, the
       server MUST follow the congestion control [RFC5681] to set the
       initial congestion window [RFC3390], to send more data packets.
SUGGESTED:
    6. Advance to the SYN-RCVD state. If the FastOpened flag is set, the
       server MUST follow RFC 5681 (based on RFC 3390) to set the
       initial congestion window for sending more data packets.

Section 6.3.3
s/idem-potency/idempotency/

Section 7.3
s/Further experimentation regarding the congestion control impact are useful./
  /Further experimentation regarding the congestion control impact 
will be useful./

Section 8.3
s/Therefore applications like Web may not receive the latency benefit as TFO./
  /Therefore the latency of applications such as Web may be worse 
than with TFO./


Bob


________________________________________________________________
Bob Briscoe,                                                  BT