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

[Bob Briscoe <[e-mail]>]

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.

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. The current draft 
solely gives SACK + MPTCP + TCP-AO as an example, but is that really 
something that can't be done today?

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.



Bob



At 22:05 22/05/2014, Joe Touch wrote:


>On 5/22/2014 11:58 AM, Wesley Eddy wrote:
>>On 5/22/2014 1:58 PM, Joe Touch wrote:
>>>>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.
>>>
>>>Oh, I certainly agree with this. The point of this proposal is twofold:
>>>
>>>      a) (primary) to put to bed the notion that 'there is a way'
>>>      to extend SYN option space without contaminating connections to
>>>      legacy hosts
>>>
>>>      b) (secondary) to do the only extension possible - post-SYN.
>>
>>
>>I agree with this.  In my view, we actually have had consensus
>>for a long time that extending the SYN is "really hard" (requiring
>>some creativity),
>
>Well, AFAICT we've also known for a long time that it's basically 
>impossible when needed - i.e., to new endpoints, without impacting 
>legacy endpoints (i.e., making their connections to new systems slow 
>or misinterpreting option info as user data).
>
>Yes, there are a few other potential solutions that need to be 
>discussed as non-viable, but IMO that's an important part of this doc.
>
>At the very least, even if it's not provably impossible, the obvious 
>solutions don't work and it's harder than it looks.
>
>Joe

________________________________________________________________
Bob Briscoe,                                                  BT