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

From: Neal Cardwell <[email-masked]>
Date: Mon, 11 Nov 2019 12:25:02 -0500

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

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 12 Nov 2019 16:09:13 +0000

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" <[email-masked] on behalf of ncardwell=[email-masked]> wrote:

    

    best,
    neal
    
    _______________________________________________
    tcpm mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/tcpm

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 13 Nov 2019 13:30:22 +0000

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

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

---

From: "Scharf, Michael" <[email-masked]>
Date: Wed, 13 Nov 2019 16:29:59 +0000

Wouldn't it make sense to work through that now if this gives a real-world benefit?

While AccECN is indeed extensible and this is documented in the document (thanks!), as far as I understand there is only so much one can do with few bits. At least to me it would be more convincing to understand now how this use case could be solved, in order to ensure that there are no open issues in whatever the initial spec describes.

Michael (with no hat)

> -----Original Message-----
> From: tcpm <[email-masked]> On Behalf Of Mirja Kuehlewind
> Sent: Tuesday, November 12, 2019 5:09 PM
> To: Neal Cardwell <ncardwell=[email-masked]>; [email-masked]
> Cc: Bob Briscoe <[email-masked]>
> Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09: AccECN option: why not
> EE1B first?
> 
> 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" <[email-masked]
> on behalf of ncardwell=[email-masked]> wrote:
>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 14 Nov 2019 11:06:18 +0100

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:
>> On 11.11.19, 18:25, "tcpm on behalf of Neal Cardwell"<[email-masked] on behalf of ncardwell=[email-masked]>  wrote:
>>
> Bob Briscoehttp://bobbriscoe.net/
>
>

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 14 Nov 2019 17:47:23 +0000

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

Richard, Inline...

Bob

> That would special-case the initial AccECN option (value order) from the
There's already text in the draft that special-cases the initial AccECN 
option to check the values for middlebox zeroing, and I suspect .

> 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.

> field values depening on some (possibly missed by passive observation)
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

>>> 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"<[email-masked] on behalf of 
>>> ncardwell=[email-masked]>  wrote:
>>>

---

From: Neal Cardwell <[email-masked]>
Date: Thu, 14 Nov 2019 13:00:59 -0500

> values would address this.

Two option kind values sounds like a nice solution, IMHO. Clear,
simple, and fast.

best,
neal

---

From: "Scharf, Michael" <[email-masked]>
Date: Thu, 14 Nov 2019 22:01:44 +0000

I am neither the shepherd for this document nor the owner of the meeting agenda. => Yoshi

Michael

> From: Bob Briscoe <[email-masked]>
> Sent: Thursday, November 14, 2019 6:47 PM
> To: Scheffenegger, Richard <[email-masked]>; [email-masked]; Scharf, Michael
> <[email-masked]>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 14 Nov 2019 14:10:49 -0800

Hi Bob,
You can make a request. We'll think about it and will get back to you.
--
Yoshi

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 15 Nov 2019 13:04:35 +0100

I too like two different option numbers more than initial magic numbers
- we aren't yet that constrained in the tcp options registry to not go
that route...

Richard

---

From: Joe Touch <[email-masked]>
Date: Fri, 15 Nov 2019 06:24:30 -0800

A better explanation would be important. Just not being “happy” and wanting “nice” doesn’t cut it.

The only justification for multiple code points for a single option would be the need to signals from both ends AT THE SAME TIME (I just went through this exercise for UDP options for PMTUD).

Joe

> On Nov 15, 2019, at 4:04 AM, Scheffenegger, Richard <[email-masked]> wrote:
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 15 Nov 2019 08:34:15 -0800

If it’s just binary info, can we allocate a bit for it?
-
Yoshi

---

From: Bob Briscoe <[email-masked]>
Date: Sat, 16 Nov 2019 02:34:11 +0800

Yoshi,

Unfortunately, we don't have any spare single bits. That's sort-of the 
problem.

If we have to use the initial magic no. approach, I guess checking a 
number is hardly different to toggling a bit.

Bob

On 15/11/2019 16:34, Yoshifumi Nishida wrote:
> On Fri, Nov 15, 2019 at 4:05 AM Scheffenegger, Richard <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > On Thu, Nov 14, 2019 at 12:47 PM Bob Briscoe
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     [email-masked] <mailto:[email-masked]>