Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02

[Bob Briscoe <[e-mail]>]

Joe,

At 18:16 25/09/2014, Joe Touch wrote:


>On 9/25/2014 9:41 AM, Andrew Yourtchenko wrote:
> > Bob, Joe, all,
> >
> > some comments below, maybe with some obvious questions as I did not
> > follow the latest discussions very closely.
> >
> > On Thu, 25 Sep 2014, Bob Briscoe wrote:
> >
> >> Joe,
> >>
> >> At 23:25 24/09/2014, Joe Touch wrote:
> >>> Hi, Bob (et al.),
> >>>
> >>> It's good to have a more detailed description of the proposal.
> >>>
> >>> I still find a dual-SYN solution untenable, though, as it has been for
> >>> other upgrade paths in the past (e.g., IPv6).
> >>
> >> That's why I prefer syn-op-sis because it only uses 2 SYNs for
> >> transition.
> >
> > Both syn-op-sis and tcp-syn-ext-opt talk about using
> > different port pairs
>
>tcp-syn-ext-opt describes two different approaches:
>
>         SYN-EOS-OOB     uses one port pair, sends only one SYN
>
>         SYN-EOS-DS      uses two port pairs
>
>the DS variant is very similar to the one in syn-op-sis; both are Bob's
>suggestion. Mine was SYN-EOS-OOB.
>
>Bob - let me know if its useful to retain SYN-EOS-DS or if you want to
>replace it with syn-op-sis.

In my mind syn-op-sis solves problems with SYN-EOS-DS and doesn't 
introduce any new problems (AFAIK). So it's a pure upgrade.

Let's have an author-huddle off-list about how we deal with these.

Sorry for my last post crossing your response below.


> > - is this due to the explosion with the number of
> > possibilities for the three-way handshake recovery ?
>
>Two ports are used only when two SYNs are sent, largely to avoid the
>second SYN from affecting the progress of the first that arrives at a
>legacy endpoint.
>
> > (Of course the application will anyway see only 1 file descriptor, which
> > will assume the identity of the connection that succeeds, right ?)
>
>Yes.
>
> >> I've included a new section on ways to use only 1 SYN during
> >> transition (building a white-list) and ultimately moving to 1 SYN in
> >> the future, only falling back to the legacy SYN in series rather than
> >> parallel if you hit a legacy listener.
> >
> > The fundamental difference between the transition to the extended option
> > space and IPv4->IPv6 transition is the absence of the DNS to signal the
> > capabilities of the endpoint before the connection even starts - if the
> > target host has A&AAAA you only have to deal with the failures on the
> > path, while if the target host does not have AAAA record, it's worthless
> > to try IPv6.
> >
> > OTOH, when attempt to negotiate the extended option space, you do not
> > have any hints about the remote end - besides maybe past memory.
>
>You could have similar hints in SRV records, though those are used much
>less frequently.
>
>...
> > In today's conditions, a simple 300ms headstart for IPv6 if AAAA is
> > advertised might be sufficient, as the subpar IPv6 connectivity
> > disappears, and more of the corner cases get into play for RTTs.
> >
> > So, depending on how much of a drop rate we'd expect for a "new" SYN
> > across the variety of network scenarios, the simpler approach of just
> > using 300ms delay could be reasonable due to its simplicity - an
> > experiment could show.
>
>Sure, but it also has creates delay on either the legacy or upgraded
>connection - depending on which SYN is stalled.
>
>That's the advantage of the OOB method - there's no need to insert a
>stall on the sending side (an upgraded receiver might cache OOBs that
>arrive briefly before SYNs to avoid the need for an additional exchange)
>
> >> The other two in tcp-syn-ext-opt have to be 2-SYN for ever.
>
>They're two segments forever. Only one is two SYNs.
>
>Joe

________________________________________________________________
Bob Briscoe,                                                  BT