[tcpm] Re: I-D Action: draft-ietf-tcpm-accurate-ecn-29.txt

[Ingemar Johansson S <[e-mail]>]

Hi
+1 on Stuart's comment below. 

We are getting close to having L4S support for 5G so it is definitely the case that the network side of the chicken and egg problem can be solved. We (and collaboration partners) have already run testing with TCP Prage based on the Linux patches provided by the L4S Team and the results are good. 
We should also be able to assist in further testing. 
One possible future (not related to accurate ECN) improvement is to enhance prague with faster than additive increase but that is however not critical for the deplyment of L4S, rather it is an improvement. 

Regards
Ingemar

> -----Original Message-----
> From: Stuart Cheshire <cheshire=[e-mail]>
> Sent: Tuesday, 23 July 2024 22:07
> To: [e-mail]
> Subject: [tcpm] Re: I-D Action: draft-ietf-tcpm-accurate-ecn-29.txt
> 
> On Jun 28, 2024, at 02:30, Richard Scheffenegger wrote:
> 
> > This version updates the text in section 3.3.4 to differentiate
> > between transmit and receive path TCP segmentation offload (TSO) and
> > Large Receive Offload (LRO). In particular, more specific guidance is
> > given what to consider when implementing AccEcn with TSO / LRO.
> >
> > Best regards,
> >   Richard Scheffenegger
> 
> Last weekend I read draft-ietf-tcpm-accurate-ecn-29 from start to finish.
> 
> I want to start by congratulating and thanking the authors for an excellent
> document.
> 
> The idea of Accurate ECN could be described in one page; the rest of the
> document is a very thorough analysis of all the forwards- and backwards-
> compatibility issues -- legacy servers that don’t support Accurate ECN,
> buggy servers that don’t even implement classic ECN negotiation properly,
> poorly designed middleboxes that try to “help” TCP connections and actually
> mess them up.
> 
> This draft dates back to 2015. It is long overdue that we get it published.
> Apple has implemented Accurate ECN. Wireshark correctly decodes Accurate
> ECN. We’d love to see Accurate ECN supported in mainline Linux too, but the
> Linux networking maintainers are quite reasonably cautious about what they
> put in the Linux networking code. The want to see a Standards-Track RFC
> that shows it has received IETF review and consensus. CableLabs and Comcast
> are rolling out L4S, but TCP can’t use L4S without Accurate ECN. A lot of
> progress has been made here, but we’re starting to see progress being held
> up by the lack of RFC publication. What can I do to help?
> 
> I also have a couple of minor editorial comments which I will send in a
> separate email.
> 
> Stuart Cheshire
> 
> _______________________________________________
> tcpm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]