Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-01.txt

[John Leslie <[e-mail]>]

Bob Briscoe <[e-mail]> wrote:
> 
> Returning to the question of adoption, we have to 
> address the question of why previous attempts to 
> do this have failed. I don't believe it is as 
> simple as that they tried to include options on 
> SYNs, so all we have to do is avoid the SYN problem.

   Of course, it's not that simple; but we've so far failed to convince
folks that the schemes for expanding option-space for SYNs are safe.

> 1) There is obviously the re-segmentation 
> problem, which Olivier/Costin have usefully 
> highlighted, and I agree an optional checksum would at least detect this.

   Yes.

> 2) However, I think the main problem is that many 
> important cases will need as large or larger TCP 
> option space on the SYN as on non-SYNs.

   No.

   We have not yet passed the point where the needed initial-negotiate
can't fit in an un-expanded SYN.

   We will, of course, if we continue to do nothing. :^(

> The option space pressure for all the following 
> (except SACK) is at least as critical for the SYN as for non-SYN segments:
> * SACK          (SYN << non-SYN)
> * MPTCP (SYN > non-SYN - typically)
> * Timestamp     (SYN = non-SYN)
> * Window scale  (SYN > non-SYN)
> * TCP-AO        (SYN = non-SYN)
> * TFO init      (SYN << non-SYN - but no use without TFO resume as well)
> * TFO resume    (SYN >> non-SYN)

   Of those, certainly MPTCP can adapt to a really-small SYN.

   The Timestamp/Window-Scale is scary, but not actually fatal.

   (We may, of course, need to eventually design a way to push the
initial-negotiate issue beyond the _initial_ SYN into the SYN-ACK, but
that's not something we need to solve in tcpm-tcp-edo.)

> Given the above list, if bigger TCP options are 
> not available for SYNs, is a critical mass really 
> going to be persuaded that it is worth the effort 
> of implementing, deploying, debugging, 
> supporting, etc? And we need a critical mass, 
> because until EDO is deployed at both ends it 
> does nothing, so early implementers have to work on faith.

   The critical-mass will be slow to develop anyway. What will drive
the speed of adoption, IMHO, is whether it is perceived as risk-free.

> Admittedly, EDO is partly trying to make space 
> for future options and partly trying to solve a 
> problem we already have with existing options. 
> So, I admit that the relative size of existing 
> options is not the whole story. However, even new 
> options have to fit with the existing ones.

   They can't, already. :^(

> 3) The EDO draft implies that it is provably 
> impossible to increase the option space on a SYN. 

   I don't read it that way.

> A couple of ways have been proposed to solve this problem:
> * LOIC <draft-yourtchenko-tcp-loic-00> that sends 
> two parallel SYNs; a regular one and one with a 
> longer TCP option space AND a newly defined 
> checksum calculation, so that it will be discarded by legacy TCPs.

   That's too big of a change to ask folks to believe it safe.

> * An out-of-band control channel, e.g. <draft-paasch-mptcp-control-stream>

   That's workable, but really doesn't belong as part of an option-space
expansion update to TCP.

> Much earlier in this thread, you dismissed the latter, wrongly I believe:

   I don't agree; but that question is not germane.

> This seems to miss the point that there could be 
> a whole class of solutions where we create an 
> associated connection, precisely in order to add 
> a control channel of unlimited size to one (or 
> more) data channels. This brings its own 
> problems, not least it loses the intrinsic 
> security binding when control and data are in the 
> same segment. So, I wouldn't separate off a 
> control channel if we were starting from scratch. 
> But it's probably the most promising approach, 
> given we have to add a carbuncle to a wart.

   Yes.

> 4) Finally, the EDO draft cites 
> <draft-ananth-tcpm-tcpoptext-00> as if it is just 
> another solution. It's not. It's actually a very 
> useful survey of all the previous attempts to 
> solve this problem, including a useful 
> enumeration of the problems that have to be surmounted.

   How would _you_ like it cited?

> The arguments on this thread show that we don't 
> agree on the problem space. So, I suggest we 
> adopt Anatha's draft, and as we develop it, we 
> agree on the problem we are trying to solve 
> first. Boring, but apparently necessary.

   I don't believe we'll be taken seriously trying to resurrect a
two-year-old draft.

   IMHO, we need to concentrate on a smaller piece of the problem.

   YMMV, of course...

--
John Leslie <[e-mail]>