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

[Bob Briscoe <[e-mail]>]

Joe,

I was asking for an example of something useful that /can/ be done with EDO.

I'm sure you can come up with one. However, you have shown 
conclusively that the example in the draft (SACK + MPTCP + TCP-AO), 
when added to the widespread basic options, /cannot/ be done with 
EDO, because it needs 7 more bytes of options than a SYN allows.


Bob

At 18:30 28/05/2014, Joe Touch wrote:


>On 5/28/2014 10:16 AM, Bob Briscoe wrote:
>>Joe,
>>
>>I don't think this sufficiently answers the question to justify WG
>>adoption. You seem to be confirming that this is an academic exercise.
>
>You asked for a specific example - one that the MPTCP community has 
>raised. It's not a proof that there's "some set" that might overload 
>the space; it's based on a *specific* request.
>
>I gave other reasons - including educating the community as to the 
>issues. If you want to call that "academic", sure - in part.
>
>But I don't see that as interfering with WG adoption - we do that 
>sort of thing all the time (that's the basis of a BCP).
>
>Joe
>
>>At 17:55 23/05/2014, Joe Touch wrote:
>>>Hi, Bob,
>>>
>>>On 5/23/2014 3:03 AM, Bob Briscoe wrote:
>>>>Joe, and everyone else who wants to work on this,
>>>>
>>>>Just because it's easier to make a chocolate teapot than a cast-iron
>>>>one, doesn't imply that there is any need for chocolate teapots.
>>>
>>>You don't get a cast iron teapot just because you want one either ;-)
>>>
>>>>IOW, we will be asking the IESG to spend reviewer time on EDO, so we
>>>>need to give some plausible indication that someone might find it useful
>>>>and it's not just an academic exercise.
>>>
>>>Sometimes the answer "you can't have A, but at least here's B" is more
>>>than an exercise; it educates the community. By not providing either
>>>answer, we have continued to drag this issue around the block for far
>>>too long -- and spent far too many cycles in this and other WGs
>>>seeking solutions.
>>>
>>> > The current draft solely gives
>>>>SACK + MPTCP + TCP-AO as an example, but is that really something that
>>>>can't be done today?
>>>
>>>Current total for SYN options in widespread concurrent use (as already
>>>described in sec 6.4):
>>>
>>>         2       SACK permitted
>>>         10      timestamp
>>>         3       window scale
>>>         4       MSS
>>>         ------------------
>>>         11 bytes
>>>
>>>The current DO field is 4 bits, with a max value of 15 = 60 bytes for
>>>the total header, less 20 for the base TCP header which leaves 40 for
>>>options.
>>>
>>>So let's see what happens when we add:
>>>
>>>         11      widespread basic options
>>>         16      TCP-AO
>>>         20      MPTCP
>>>         --------------------
>>>         47
>>>
>>>That's more than 40.
>>>
>>>>Adding more complexity to the TCP stack (with the potential for more
>>>>vulnerabilities) is only worthwhile if there's an identifiable benefit,
>>>>otherwise few production stacks are going to implement it anyway.
>>>
>>>There are two identifiable benefits:
>>>
>>>         1) explain the ways we already know we can't extend the SYN
>>>         so we stop wasting time trying them repeatedly (i.e., education)
>>>
>>>         2) provide a solution for the other segments, so that can be
>>>         used - e.g., for large SACK responses
>>>
>>>         3) educate the community
>>>
>>>Joe
>>
>>________________________________________________________________
>>Bob Briscoe,                                                  BT
>
>________________________________________________________________
>Bob Briscoe,                                                  BT