Subject: [tcpm] TCPCT Rapid Restart -00a

From: William Allen Simpson <[email-masked]>
Date: Sun, 20 Mar 2011 13:42:03 -0400

As I promised a few days ago, I've done my own competing variant of this
proposal as a follow-on to TCPCT for comparison and discussion.  It's
mostly complete, or at least as complete as I could whip up in a weekend.
It helps that I'd already thought through the various problems over a
year ago....

Other than actually having better security, a major difference is a more
moderate approach to the restart congestion window.

Rather than banging out a SYN with 10 segments several minutes after the
most recent transmission (Fast Open + IW10), or reducing the window after
only 1 RTT (RFC5681), I've taken a more gradualist approach of reducing by
half per RTT (RFC2861).  But then, it's experimental....

Available upon request.

---

From: Mark Allman <[email-masked]>
Date: Sun, 20 Mar 2011 23:17:33 -0400

> half per RTT (RFC2861).  But then, it's experimental....

Maybe I don't understand what you're saying, but the whole point of this
sort of thing is to cut out of the 3WHS time.  So, if you're going to
restrict the initial window then that goes against the entire goal it
would seem.  Perhaps there would be some slightly different congestion
control response to loss in this area of the connection (e.g., because
losing a SYN would prevent the usual IW from being sent or something).
And, maybe we'd agree that the IW should be IW-1 to account for the SYN
segment.  Or, other such small items.  However, that is working the
edges.  From a congestion control perspective this fundamentally this
isn't much different from starting a new connection with the usual IW
(which would be perfectly legal).

allman

---

From: William Allen Simpson <[email-masked]>
Date: Mon, 21 Mar 2011 08:50:09 -0400

> (which would be perfectly legal).
Certainly.  My point is that the usual IW comes after a 3WHS, so there's
timing information available and you "know" enough bandwidth to carry the
3WHS....  But the current 1 RTO (RFC-5681) RW drop defeats the purpose of
keeping the bandwidth going for long-delay paths.  So, I'm proposing we go
back to the more gradual RFC-2861 approach for these purposes.

---

From: William Allen Simpson <[email-masked]>
Date: Mon, 21 Mar 2011 09:26:49 -0400

The wording of the critical section is:

3.1.  Responder TCB Retention

    By default, upon receipt of the Initiator <ACK(FIN)> (and
    verification of the Timestamps and Cookie-Pair options), the
    Responder removes its TCB.

    If the Responder (server) application has set the TCPCT_RETAIN flag,
    the Responder calculates the retention time.  This time is based on
    the anticipated decay of the congestion window during an idle period.
    For purposes of these calculations, the implementation SHOULD reduce
    its congestion window by half for every Round Trip Time (RTT) that
    the flow has remained idle.  [RFC2861]

    When the congestion window is less than or equal to
    TCP_SYN_ACK_DATA_LIMIT (or the local value in tcpct_s_data_desired)
    plus Maximum Segment Size (MSS), as limited by the retained Path
    Maximum Transmission Unit (PMTU), rapid restart offers no improvement
    over accelerated open.  At that time, the Responder removes its TCB.

All the rest is mechanism.  Critique requested.