Re: [tcpm] AccECN field order

That seems to work. 

> On Jan 27, 2021, at 10:18 AM, Scheffenegger, Richard <Richard.Scheffenegger@netapp.com> wrote:
> 
> 
> Actually, your suggestion is at odds with our current flexible length of the accecn option. 
> 
> We already allow one, two or all three counters to be present - thus the requirement of an demarcation between the ordering.
> 
> With Len==5, a single counter option can only present either EE1B or EE0B.
> 
> However, we could allow Len==6 with
> 
> Kind | Length==6 | 32-bit ECEB
> 
> For a full allowable AccECN option set of:
> 
> Kind | Length==5 | 1bit order==0 | 23bit EE1B
> Kind | Length==5 | 1bit order==1 | 23bit EE0B
> Kind | Length==6 | 32bit ECEB
> Kind | Length==8 | 1bit order==0 | 23bit EE1B | 24bit ECEB
> Kind | Length==8 | 1bit order==1 | 23bit EE0B | 24bit ECEB
> Kind | Length==11 | 1bit order==0 | 23bit EE1B | 24bit ECEB | 24bit EE0B
> Kind | Length==11 | 1bit order==1 | 23bit EE0B | 24bit ECEB | 24bit EE1B
> 
> 
> Richard Scheffenegger
> 
> -----Ursprüngliche Nachricht-----
> Von: Joseph Touch <touch@strayalpha.com> 
> Gesendet: Mittwoch, 27. Jänner 2021 18:19
> An: Scheffenegger, Richard <Richard.Scheffenegger@netapp.com>
> Cc: Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org>; Michael Tuexen <tuexen@fh-muenster.de>; tcpm IETF list <tcpm@ietf.org>; Mirja Kuehlewind <ietf@kuehlewind.net>; tcpm-chairs@ietf.org
> Betreff: Re: [tcpm] AccECN field order
> 
> NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> 
> 
>> On Jan 27, 2021, at 1:43 AM, Scheffenegger, Richard <Richard.Scheffenegger@netapp.com> wrote:
>> 
>> Just for clarity, the suggestion would be something like:
>> 
>> Kind | Length | 1-bit ordering == 0 | 23-bit EE1B [ | 24-bit ECEB [ | 
>> 24-bit EE0B ] ] And Kind | Length | 1-bit ordering == 1 | 23-bit EE0B 
>> [ | 24-bit ECEB [ | 24-bit EE1B ] ]
>> 
>> With the two trailing 3-octet fields being optional in both cases.
>> 
>> An increment in the CE counter would require at least 1+1+3+3 = 8 byte TCP option space.
> 
> It would anyway unless we’re now talking about three TCP codepoints.
> 
> Strictly, if only the CE counter changed, that could be accomplished using only 5 bytes by adding another variant, determined by the length being 5:
> 
> Kind | Length | 24-bit ECEB
> 
> At some point, the flexibility in this option needs to be supported within the option itself.
> 
> Joe
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm