Subject: Re: [tcpm] draft-ietf-tcpm-fastopen-02 vs. congestion control

From: Yuchung Cheng <[email-masked]>
Date: Thu, 1 Nov 2012 09:19:23 -0700

On Wed, Oct 31, 2012 at 12:45 PM, Yoshifumi Nishida
<[email-masked]> wrote:
> Hi Yuchung,
>
> On Tue, Oct 30, 2012 at 2:42 PM, Yuchung Cheng <[email-masked]> wrote:
>>
>>
>>
>> On Sun, Oct 28, 2012 at 1:14 PM, Scharf, Michael (Michael)
>> <[email-masked]> wrote:
>>>
>>> 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.
>>
>> 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".
>
>
> 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?

The server can ack only SYN/initial sequence or send less data if it does
not want (e.g., based on some history of the destination). I will modify
step 4 in "Server: Receiving SYN and responding with SYN-ACK" to make
this option more explicit. Thanks for pointing that out.

>
> Thanks,
> --
> Yoshifumi
>
>>>
>>> ________________________________________
>>> 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
>>>
>>> On Fri, Oct 26, 2012 at 12:57 PM, Scharf, Michael (Michael)
>>> <[email-masked]> wrote:
>>> > 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.
>>>
>>> Which part in RFC5681 needs to be updated by Fast Open if you don't
>>> think it's true?
>>>
>>> >
>>> > 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...).
>>>
>>> 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 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.
>>> >
>>> As I said, IW10 is part of RFC5681. TFO does not update RFC5681
>>> currently. Should I mention TCP-SACK in TFO too?
>>>
>>>
>>> > 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
>>> >>
>>> >> On Mon, Oct 22, 2012 at 11:57 AM,  <[email-masked]> wrote:
>>> >> >
>>> >> > 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.
>>> >> 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
>>> >>
>>> >> >
>>> >> > 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/
>>> >> >
>>> >> > _______________________________________________
>>> >> > tcpm mailing list
>>> >> > [email-masked]
>>> >> > https://www.ietf.org/mailman/listinfo/tcpm
>>> >> _______________________________________________
>>> >> tcpm mailing list
>>> >> [email-masked]
>>> >> https://www.ietf.org/mailman/listinfo/tcpm
>>> >>
>>
>>
>>
>> _______________________________________________
>> tcpm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>