Re: [tcpm] AccECN field order

[Joseph Touch <[e-mail]>]

> On Jan 24, 2021, at 10:41 PM, Vidhi Goel <[e-mail]> wrote:
> 
> I apologize for the late response.
> 
> I support the "Two options” but with a suggestion which can help to eliminate the extra 1 byte.
> 
> How about using 1 Byte (instead of 2) for both Kind (3 bits = 7 Kinds) and Length (5 bits = 31 Bytes) combined? 

Where is this 1 byte? 

I thought we were talking TCP options. For SYNs and SYN/ACKs, the approach above violates RFC 793, which defines new TCP options as having both kind and length - that way, an endpoint can skip over options it doesn’t know.

For other segments, it defeats the point of not wanting to issue two codepoints, which is to conserve codepoints. Instead, it would effectively be assigning 64 codepoints to the same role. 

Both are not viable ways forward.

> 1. Kind field - With limited space for ECN code points in IP header, I don’t foresee that we would be able to have many different “kinds”.  
> 2. Length field - TCP option length is limited to 40 bytes and with common options like timestamp, SACK etc, I think 31 bytes for ACK ECN option should be more than what we can fit in.

FWIW, we do have a standards-track update to extend that option length arbitrarily in non-SYN segments (draft-ietf-tcpm-tcp-edo), once we have implementations at least.

Joe