Re: [tcpm] Some ideas building on draft-ietf-tcpm-fastopen-01

<bob.briscoe@bt.com> Mon, 30 July 2012 20:49 UTC

Return-Path: <bob.briscoe@bt.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008B711E818E for <tcpm@ietfa.amsl.com>; Mon, 30 Jul 2012 13:49:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.998
X-Spam-Level:
X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ji67+jxM8Pj for <tcpm@ietfa.amsl.com>; Mon, 30 Jul 2012 13:49:30 -0700 (PDT)
Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3C811E8155 for <tcpm@ietf.org>; Mon, 30 Jul 2012 13:49:29 -0700 (PDT)
Received: from EVHUB71-UKRD.domain1.systemhost.net (10.36.3.154) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.264.0; Mon, 30 Jul 2012 21:49:28 +0100
Received: from EVMHT03-UKBR.domain1.systemhost.net (193.113.108.56) by EVHUB71-UKRD.domain1.systemhost.net (10.36.3.154) with Microsoft SMTP Server (TLS) id 14.2.298.4; Mon, 30 Jul 2012 21:49:27 +0100
Received: from EMV04-UKBR.domain1.systemhost.net ([169.254.1.122]) by EVMHT03-UKBR.domain1.systemhost.net ([193.113.108.56]) with mapi; Mon, 30 Jul 2012 21:49:27 +0100
From: bob.briscoe@bt.com
To: hkchu@google.com
Date: Mon, 30 Jul 2012 21:49:26 +0100
Thread-Topic: Some ideas building on draft-ietf-tcpm-fastopen-01
Thread-Index: AQHNbpTOd9k1XdzVuk606ETC/srmOg==
Message-ID: <69ACA3A4BA39B0499C1917FB0718BB254BE747BBA2@EMV04-UKBR.domain1.systemhost.net>
Accept-Language: en-US, en-GB
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
Content-Type: multipart/alternative; boundary="_000_69ACA3A4BA39B0499C1917FB0718BB254BE747BBA2EMV04UKBRdoma_"
MIME-Version: 1.0
Cc: tcpm@ietf.org, draft-ietf-tcpm-fastopen@tools.ietf.org
Subject: Re: [tcpm] Some ideas building on draft-ietf-tcpm-fastopen-01
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jul 2012 20:49:31 -0000

Jerry,

Re-instating tcpm list on distr. Inline...

At 19:41 30/07/2012, Jerry Chu wrote:
Hi Bob,

Thanks for your interest and sorry for the delay (Yuchung has been
traveling and I've
been busy preparing TFO's server side implementation for publication).

On Thu, Jul 26, 2012 at 9:35 PM, Bob Briscoe <bob.briscoe@bt.com> wrote:
> Yuchung, Jerry, Sivasankar, Arvind,
>
> I liked this enough to want to work on improving it. I have a couple of
> proposals that occurred to me, which I've finally made time to write up.
>
> (I'll send editorial nits from reviewing the draft later)

Sure.

>
> ==Proposal #1/ ==
> Fast Open Cookie Request MUST (SHOULD?) be on a FIN
>
> I believe it would be better for the reasons below if:
> * the client put a fast open cookie request in its FIN, not its SYN (whether
> or not the server has sent a FIN first).
> * Then the server can send the fastopen cookie on the FIN-ACK.
> * If the client times out waiting for a FIN-ACK, it just re-sends as usual.
> * If the server's FIN-ACK never arrives (perhaps because a middlebox has
> eaten it), the client just doesn't have a cookie for the next session and
> uses a 3WHS as normal.

Very interesting idea.

>
> Note, only the Request would have to be on a FIN. The Fast Open Cookie
> itself would obviously still be on the SYN of subsequent connections. Then,
> when a subsequent connection finishes, it can refresh the cookie on its FIN,
> ready for another connection later.
>
> This solves a couple of potential problems with a fastopen request-response
> on the initial SYN exchange:
> a) A FIN-cookie sidesteps the risk of unpredictable delay of the very first
> SYN due to some middleboxes dropping new TCP options (any timeouts due to
> non-delivery don't hold up the session, which has already finished)

This is a good point but from our experience unknown TCP options don't seem
to pose a real problem wrt middleboxes, SYN pkts w/ data do.

This is only half the reason for doing it (ie the two reasons together stregthen the case).


Also if there is middlebox on the route that will drop SYN pkts with
unrecognized
TCP options, requesting TFO cookie in FIN pkt only postpones the delay for
those servers that support TFO, i.e., to the subsequent connections with TFO
cookie+data.

My point is that sending the risky packet after you've sent all the data doesn't delay anything the user cares about - you just retransmit the FIN to close the connection - no big deal for anyone.

But I agree if there is still non-negligible % of
middleboxes dropping

The refs say there might be problems (today) with 6% of paths. In future it might be more. Might be less. That's not negligible.

SYN w/ unrecognized TCP option then requesting TFO cookie through FIN can
avoid the delay for those cases where the server doesn't support TFO.

Getting really bad delay variance on a proposal to cut delay isn't good.

> b) Transports GETting typical Web pages could (ab)use the fastopen cookie on
> the SYN exchange by opening multiple TCP connections during the initial
> connection without each one suffering the delay of a 3WHS. This creates a
> perverse incentive to use multiple parallel connections, because you can get
> the same latency benefit as HTTP pipelining [Yoshifumi posed this problem
> some time ago].  If clients can only request a fastopen cookie on a FIN,
> they don't have this perverse incentive to not bother with pipelining.

Interesting point. A motivated abuser may rush to FIN to get a cookie first.

Client can't send a FIN without closing the connection. That's the dilemma I'm proposing it has to face.

I'm not talking about an attack. I'm talking about lazy Web developers. This removes the benefit that fast-open gives to those who shard connections. If they want to avoid 3WHS for the /current/ set of objects they are trying to get, they have to use pipelining or SPDY.

Cookie on FIN deliberately defers the benefit of no 3WHS to subsequent connections.


>
> I have no evidence, but it seems intuitive that if the TCP option got
> through on the first FIN, it might be more likely to get through on the next
> SYN, altho I admit options on SYNs are looked at more closely by
> middleboxes.
>

I won't worry about the difference here because the real test for the middlebox
is SYN+data I think. Again do you have data showing middlebox still
having trouble
with unrecognized TCP options?

6% of paths - From memory this was Michio's work in the Trilogy project that you cite in the draft.


Will comment on your following proposals later.

Understood



Bob


Jerry

>