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

[John Leslie <[e-mail]>]

Wesley Eddy <[e-mail]> wrote:
> On 5/5/2014 10:41 AM, John Leslie wrote:
>>
>> (That's one of the reasons I prefer to have "Data Offset" be a clearly
>> invalid value whenever it is overridden by EDO: any middlebox will then
>> have fair warning that it is clueless.)
> 
> I think I agree.  IMHO, the tradeoff comes down to whether it's more
> desirable for the middlebox to end up doing something violent like:
> 
> - dropping the segment

   This should always be "legal" for a middlebox. (I certainly prefer
it to damaging some unrelated part of the packet.) It's easy enough
to detect.

> - resetting the TCP connection

   This isn't quite "legal", but is certainly easy to detect.

> - generating an ICMP

   Would anyone actually do this? (Hopefully, it would be in combination
with dropping the packet.)

> - crashing

   That's my most-preferred one. There's no excuse to blame anyone but
the middlebox vendor. ;^)

> versus just doing something to the segments which the receiver can
> detect and possibly work-around with greater size and complexity in
> the mechanism itself.

   I'd _much_ rather not start down the road of guessing what
unrelated part of the packet has been damaged!

> It ends up being a matter of transition and whether we really
> expect offending nodes to be found and fixed over time, and can
> stand some deployment hassles and complaints in the meantime.

   IMHO, that's always the case -- it just is, sometimes the transition
takes decades. :^(

> If not, then the design needs to be a bit more complicated forever
> in order to accommodate today's legacy.

   Now we're arguing over price: how much is "a bit"?

> If there are significant advantages to being able to use long
> options that relate to real business problems, then I think the
> legacy won't be as much of a problem, but don't really know.

   We've already over-packed the Options field: there are already
_multiple_ business cases for supporting an expanded field.

   How much of a problem the legacy proves to be depends a lot on
how we design EDO...

--
John Leslie <[e-mail]>