Subject: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-02.txt

From: [email-masked]
Date: Mon, 22 Oct 2012 11:57:39 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF.

	Title           : TCP Fast Open
	Author(s)       : Yuchung Cheng
                          Jerry Chu
                          Sivasankar Radhakrishnan
                          Arvind Jain
	Filename        : draft-ietf-tcpm-fastopen-02.txt
	Pages           : 22
	Date            : 2012-10-22

Abstract:
   TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK
   packets and consumed by the receiving end during the initial
   connection handshake, thus saving up to one full round trip time
   (RTT) compared to standard TCP which requires a three-way handshake
   (3WHS) to complete before data can be exchanged.

Terminology

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-fastopen-02

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 22 Oct 2012 15:22:23 -0700

>    (3WHS) to complete before data can be exchanged.
ChangeLog since 01:

- elaborate more on the issue of duplicate SYN-data (sec 2.1)

- use draft-tcpm-experimental-options (sec 10)

- add a new subsection about attacks from behind NAT (sec 6.3)
  and discuss Bob Briscoe's idea on defending with TCP-TS and
  cookies

- use null cookie (end of sec 4.1.2) (courtesy of Bob Briscoe)

- explain the problem of cookie option in FIN (end of 4.2.1)

- re-emphasize other than including data in SYN packet. TFO
  draft does not change any part of congestion control, and
  the transmission MUST be governed by CC (sec 4.2.2)

- a bunch of minor edits

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 26 Oct 2012 21:57:25 +0200

Yuchung,

You state that fast open does not change the congestion control, but I am still wondering whether this is actually true. My impression is that fast open can have side effects that affect congestion control, at least in corner cases. But please correct me if I am wrong.

Let's assume that the downlink between a HTTP server and a HTTP client is severely congested.

With current TCP, the client will send a SYN, and the server will respond by SYN-ACK. Even if the SYN carries data, the server cannot respond. That implies that the server sends one packet to a congested downlink. If it gets dropped, the whole connection backs off for a moment. That may help to reduce the congestion.

With fast open, the client will send SYN+data, and the server will potentially respond by a series of packets as allowed by the initial congestion window. According to RFC 3390, this implies sending 3 packets to the severely congested downlink. That is apparently worse...

Thus, unless I miss something here, the amount of data that a server could send to a severely congested link can be significantly larger with fast open. Fast open may thus cause self-congestion in such a scenario. Theoretically it could maybe also harm other traffic (fairness...).

It is not entirely clear to me whether that difference indeed matters in reality with RFC 3390, since fast open mostly affects *when* data is sent. Maybe this is a corner case only. But at least it might be worthwile to mention that side-effect in the draft. That might also help to understand what would happen if fast open and IW10 are used at the same time. That question was raised several times already.

Thanks

Michael (as individual)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Yuchung Cheng
> Sent: Tuesday, October 23, 2012 12:22 AM
> To: [email-masked]
> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-02.txt
>

---

From: Yuchung Cheng <[email-masked]>
Date: Sat, 27 Oct 2012 13:03:19 -0700

> You state that fast open does not change the congestion control, but I am still wondering whether this is actually true. My impression is that fast open can have side effects that affect congestion…

Which part in RFC5681 needs to be updated by Fast Open if you don't
think it's true?

> Thus, unless I miss something here, the amount of data that a server could send to a severely congested link can be significantly larger with fast open. Fast open may thus cause self-congestion in…

What if the handshakes finish smoothly in current TCP, but the network
becomes congested as you sketched by the time server is ready to send?
and many servers today do not change cwnd after idle. It's certainly
not a corner case then. How about changing the scenarios with
syn-cookies?

We appreciate you scrutinizing the draft. but I suggest you experts
look congestion control on at higher level. How about loss-based
algorithm causing huge queues with BB. Ok I am deviating now ...

> It is not entirely clear to me whether that difference indeed matters in reality with RFC 3390, since fast open mostly affects *when* data is sent. Maybe this is a corner case only. But at least it…
As I said, IW10 is part of RFC5681. TFO does not update RFC5681
currently. Should I mention TCP-SACK in TFO too?

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Sun, 28 Oct 2012 21:14:23 +0100

Yuchung,

I did not suggest that the draft must update RFC 5681.

My proposal is that the draft discusses more explicitly what the different sending behavior implies to a (congested) network. Right now, the draft mainly stresses the performance benefit for applications. Well understood. But it seems to me a valid question whether this benefit comes at some cost for the network, at least in corner cases.

I think that some text on that would be good to complete the document. This could be a short paragraph e. g. in Section 5. This is a quite low-hanging fruit. It could basically be a better phrasing of our discussion here.

Michael (as individual)

________________________________________
Von: Yuchung Cheng [[email-masked]]
Gesendet: Samstag, 27. Oktober 2012 22:03
An: Scharf, Michael (Michael)
Cc: [email-masked]
Betreff: Re: draft-ietf-tcpm-fastopen-02 vs. congestion control

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 30 Oct 2012 14:42:34 -0700

On Sun, Oct 28, 2012 at 1:14 PM, Scharf, Michael (Michael) <
[email-masked]> wrote:

> My proposal is that the draft discusses more explicitly what the different
> sending behavior implies to a (congested) network. Right now, the draft
> mainly stresses the performance benefit for applications. Well understood.
> But it seems to me a valid question whether this benefit comes at some cost
> for the network, at least in corner cases.
>
> I think that some text on that would be good to complete the document.
> This could be a short paragraph e. g. in Section 5. This is a quite
> low-hanging fruit. It could basically be a better phrasing of our
> discussion here.
>
How about this
"If SYNACK is lost during handshake, in Fast Open the server may send up to
an initial window of data because the loss is detected afterwards. But in
regular handshake, the server detects the loss first and reduces the
initial congestion window according to RFC".

> > You state that fast open does not change the congestion control, but I
> am still wondering whether this is actually true. My impression is that
> fast open can have side effects that affect congestion control, at least in
> corner cases. But please correct me if I am wrong.
>
> > With current TCP, the client will send a SYN, and the server will
> respond by SYN-ACK. Even if the SYN carries data, the server cannot
> respond. That implies that the server sends one packet to a congested
> downlink. If it gets dropped, the whole connection backs off for a moment.
> That may help to reduce the congestion.
> >
> > With fast open, the client will send SYN+data, and the server will
> potentially respond by a series of packets as allowed by the initial
> congestion window. According to RFC 3390, this implies sending 3 packets to
> the severely congested downlink. That is apparently worse...
> >
> > Thus, unless I miss something here, the amount of data that a server
> could send to a severely congested link can be significantly larger with
> fast open. Fast open may thus cause self-congestion in such a scenario.
> Theoretically it could maybe also harm other traffic (fairness...).
>
> > It is not entirely clear to me whether that difference indeed matters in
> reality with RFC 3390, since fast open mostly affects *when* data is sent.
> Maybe this is a corner case only. But at least it might be worthwile to
> mention that side-effect in the draft. That might also help to understand
> what would happen if fast open and IW10 are used at the same time. That
> question was raised several times already.
> >

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 31 Oct 2012 12:45:49 -0700

Hi Yuchung,

On Tue, Oct 30, 2012 at 2:42 PM, Yuchung Cheng <[email-masked]> wrote:

>> My proposal is that the draft discusses more explicitly what the
>> different sending behavior implies to a (congested) network. Right now, the
>> draft mainly stresses the performance benefit for applications. Well
>> understood. But it seems to me a valid question whether this benefit comes
>> at some cost for the network, at least in corner cases.
>>
> "If SYNACK is lost during handshake, in Fast Open the server may send up
> to an initial window of data because the loss is detected afterwards. But
> in regular handshake, the server detects the loss first and reduces the

I'm wondering it might be advisable to have a mechanism which can
invalidate the cookie for lossy destinations.
Or, it could be a job for the drafts like IW10 to recommend to set
appropriate IW size for lossy destinations. Any thoughts on this?

Thanks,
--
Yoshifumi

>> > It is not entirely clear to me whether that difference indeed matters
>> in reality with RFC 3390, since fast open mostly affects *when* data is
>> sent. Maybe this is a corner case only. But at least it might be worthwile
>> to mention that side-effect in the draft. That might also help to
>> understand what would happen if fast open and IW10 are used at the same
>> time. That question was raised several times already.
>> >