Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09: AccECN option: why not EE1B first?

That would special-case the initial AccECN option (value order) from the
subsequent ones, right?

Perhaps placing a different inital value in the first counter would
implicitly signal this better?

The folks from IPPM will not be all too happy with the semantics of
field values depening on some (possibly missed by passive observation)
initial value though...

Certainly warrants more discussion!

Richard

Am 13.11.2019 um 14:30 schrieb Bob Briscoe:
> Neal,
>
> Rather than the IETF have to decide up front which ECT value will be
> more prevalent, I did suggest the following mechanism to my co-authors.
> However, even tho it's fairly simple, we decided wasting some space was
> simpler.
>
> Given TCP Option space is in short supply, if the WG prefers, we can
> include that idea in the spec:...
>
> The data sender for each half-connection currently initializes
>
> 	r.e0b = 1 and r.ceb = r.e1b.= 0
>
> then communicates these to the other end in the option. We could make
> the initial values into a signal that determines whether ECT1 feedback
> comes first for feedback on that half connection. For example:
>
> 	r.e0b = 0 and r.ceb = r.e1b.= 1
>
> could mean ECT0 & ECT1 will be the other way round.
>
>
> Bob
>
> On 12/11/2019 16:09, Mirja Kuehlewind wrote:
>> Hi Neal,
>>
>> that's a good point. The order of the field was based on what is expected to be the most likely case. Currently most traffic, if it uses ECN at all, will set the codepoint to ECT(0). With deployment of L4S this could change in future, however, there are also still ways to extend the negotiation in the AccECN TCP handshake to e.g. support this case better in future.
>>
>> Mirja
>>
>>
>>
>> On 11.11.19, 18:25, "tcpm on behalf of Neal Cardwell"<tcpm-bounces@ietf.org on behalf of ncardwell=40google.com@dmarc.ietf.org>  wrote:
>>
>>      A particular question in regards to the AccECN option:
>>
>>        https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-09#section-3.2.6
>>
>>      The AccECN option spec lists the EE0B field first, with the EE1B field
>>      at the end.
>>
>>      Given that L4S plans on using ECT(1) for data packets, and unchanging
>>      counter values can be omitted from the end of the AccECN option, why
>>      not list EE1B first, and EE0B last? With EE1B first and EE0B last it
>>      seems that in the common case for an L4S connection the (unchanged)
>>      EE0B could be omitted, allowing 4 extra bytes of payload per packet.
>>      AFAICT this extra 4 bytes would increase goodput for applications
>>      using IPv4 or IPv6 with an MTU of 1500 by about 0.3%, by my
>>      back-of-the-envelope calculations.
>>
>>      best,
>>      neal
>>
>>      _______________________________________________
>>      tcpm mailing list
>>      tcpm@ietf.org
>>      https://www.ietf.org/mailman/listinfo/tcpm
>>
>>
>
> --
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>