Re: [tcpm] I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt

[Joseph Touch <[e-mail]>]

> On Feb 12, 2021, at 9:52 AM, Yoshifumi Nishida <[e-mail]> wrote:
> 
> OK. So, in my understanding, what you're suggesting are the followings.
> 
> - Aggregated options would be useful. but, the format can be simple 4 bytes length option that can accomodate 16 options.

Yes,

> - The tricks to avoid reflecting options in SYN ACK will not be needed because it's the receiver's responsibility.

Yes.

> - Delayed negotiation might be possible. But, no generic framework is needed. Each option should be designed for its own way to support it.

Yes.

> But, once thing I am wondering is that we can still combine Aggregated options and delayed negotiation even with this one.

Delayed negotiation is a completely separate and very complicated issue. It’s not as simple as “do it later”; in the TWHS, the sequence of messages is defined. Elsewhere, messages can come out of order - at which point the meaning of options with respect to that order has to be defined. That’s a can of worms and completely independent of whether aggregated options are supported.

> if you are meaning options not appeared in SYN cannot be used in the following segments, I think accecn option might be a precedent for this.  

Accecn may not appear in an option explicitly, but it is communicated using SYN flags. That’s very close to what the compressed options achieves.

I.e., the option value itself need not appear in the SYN, but the use of that option *is* signaled using the SYN/SYN-ACK, either way.

Again, doing that negotiaton after the TWHS is a separate and more complex issue that I believe should be defined for each option (even if you want to define it for a separate post-SYN aggregate option); it can’t be generalized for existing options.

Joe