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

[Bob Briscoe <[e-mail]>]

Michael,
I'll try to write concrete text before Monday.
Do we have time to discuss this in the TCPM mtg?

Richard, Inline...


Bob

On 14/11/2019 10:06, Scheffenegger, Richard wrote:
> That would special-case the initial AccECN option (value order) from the
> subsequent ones, right?
There's already text in the draft that special-cases the initial AccECN 
option to check the values for middlebox zeroing, and I suspect .

>
> Perhaps placing a different inital value in the first counter would
> implicitly signal this better?
I'll think about this - we can discuss at the hackathon.
Another possibility would be to assign two option kind values for two 
different option orders - I think I prefer this.

>
> 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...
Well, true. But I don't think that's a show-stopper. Two option kind 
values would address this.
>
> Certainly warrants more discussion!
Yup.


Bob



>
> 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"<[e-mail] on behalf of 
>>> ncardwell=[e-mail]>  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
>>>      [e-mail]
>>>      https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>>
>>
>> -- 
>> ________________________________________________________________
>> Bob Briscoehttp://bobbriscoe.net/
>>
>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/