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

[Joe Touch <[e-mail]>]

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