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

[Joe Touch <[e-mail]>]

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