Re: [tcpm] Comments on draft-zimmermann-tcpm-echo-option

["Scheffenegger, Richard" <[e-mail]>]

Hi,

> * it would be nice to have a few examples in the intro about how this
> could be used. I gather you are planning a separate document for spurious
> timeouts, and separate document is good, but some motivating examples also
> here would not harm.

Certainly; SYN Cookies (drafted by Bob) is another example that needs the different semantics.


> * It is required that at most one Echo option is included per segment. Is
> there any reason to limit the number of options? I couldn't immediately
> see why having multiple instances of the option would cause problems, or
> could it?


Yes, there are issues with that, and they are plentiful. The easy way out was to side-step this, and only allow (just as with every other TCP option so far) only a single instance of the option, and only reflect the option most recently observed by the receiver.

Issues include, but are not limited to
o) semantics
o) ordering
o) meddleboxes
o) receiver state
o) implementation issues


> * "A TCP sender MAY send an empty TCP Echo option with Length=2 on the
> SYN..." - this would not have to be limited just to SYNs, right? Can't think
> of any useful reason for sending empty echo pings mid-connection (some
> sort of diagnostics, perhaps?), but can't see any reason to disallow that
> either. Also, it might be helpful clarification to note that when ExID is
> used, length will be different.

We did not want this document to specify a full in-session negotiation protocol - as that problem has been discussed on the list earlier, it's a hard issue and beyond the scope of what we want to achive with this draft.


> * "it is NOT RECOMMENDED to send easily decipherable data in the clear as
> data in the TCP Echo option..." - I don't think this recommendation is
> necessary. Depends on the intended use, I guess. There are other ways for
> encrypting TCP header when that is needed.

Even when only the receiver can decode (or make educated guesses about) the contents of a field that is supposed to be immutable, it has shown issues in the past (reference early cubic implementations, that could be persuaded to give very large shares of bandwidth to a receiver that slightly modifies the TCP timestamp echo value). We also believe that this recommendation (not even a SHOULD or MUST) is in-line with RFC7258. 

 
> Will send some additional editorial nits to authors directly...

Thanks, we'll fix these in the next revision.

Best regards,
  Richard