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

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

On Thu, Nov 14, 2019 at 9:47 AM Bob Briscoe <ietf@bobbriscoe.net> wrote:

> 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"<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
> >>
>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>