As much as we all love ECN, implementation will not be willed into existence via some IETF MUSTs. Let's keep track of properties as they exist in reality, not as we would like them to exist. +1 to editorial / hold for update.
David On Fri, Mar 3, 2023 at 5:42 AM Lucas Pardue <lucaspardue.2...@gmail.com> wrote: > (wearing no hats) > > There seems to be a broad assumption here that QUIC is being conveyed over > UDP. Since RFC 9000 shipped, there's been activity in the MASQUE WG to > support UDP tunneling over HTTP, of which one manifestation is > QUIC-over-QUIC. While possible to add support for ECN as an extension to > this, it doesn't exist today. > > That's just one example. I find the current text (and the proposed text) > suitably generic enough to highlight the reality that, for the purposes of > QUIC, ECN cannot be fully depended on to be available. > > Editorial + hold for update sounds good to me. > > Cheers, > Lucas > > On Fri, Mar 3, 2023 at 1:02 PM Michael Tuexen < > michael.tue...@lurchi.franken.de> wrote: > >> > On 3. Mar 2023, at 11:37, Magnus Westerlund <magnus.westerlund= >> 40ericsson....@dmarc.ietf.org> wrote: >> > >> > Hi Vidhi, >> > So on Windows 5 years ago was not that easy to do it bi-directionally. >> I think reading was the hard part there, it was easy to set, but hard to >> read on a per packet basis. Then there has been the question of what rights >> you needed to have to access the bits, and finally there is even an >> implementation language problem. For example I looked into Go a couple of >> years ago which at that time had no support in its network libraries to >> access the ECN bits. I know the situation has improved, but that doesn’t >> change the previous >> When using the socket API, the way to handle the ECN bits is via CMSGs. So >> you can get/set this for each sent/received UDP packet. I don't think >> you need special privileges for that. >> Whether you have access to this functionality in libraries of specific >> programming languages is not tied to operating systems, but to these >> libraries. >> >> Best regards >> Michael >> > rough consensus. I would love to make it clear that reading ECN bit >> really should be implemented. But an errata is not the tool to change the >> existing consensus. Thus, I think the right way forward here is to mark >> this editorial and hold for update. >> > I think the ECN part should be reviewed when we do a QUIC v1 bis, or >> the next QUIC version. >> > Cheers >> > Magnus >> > From: QUIC <quic-boun...@ietf.org> on behalf of Vidhi Goel >> <vidhi_goel=40apple....@dmarc.ietf.org> >> > Date: Thursday, 2 March 2023 at 22:01 >> > To: Magnus Westerlund <magnus.westerlund=40ericsson....@dmarc.ietf.org> >> > Cc: Martin Thomson <m...@lowentropy.net>, quic@ietf.org <quic@ietf.org> >> > Subject: Re: [Technical Errata Reported] RFC9000 (7374) >> > Hello Magnus, >> > AFAIK, linux, Windows, Mac - all support reading ECN bits on received >> packets. Could you let me know which OS doesn’t support this? >> > Vidhi >> > >> > >> > On Feb 28, 2023, at 4:31 AM, Magnus Westerlund <magnus.westerlund= >> 40ericsson....@dmarc.ietf.org> wrote: >> > Hi, >> > I support Martin’s proposed way forward with this errata. The reality >> here is that we in no way could force ECN reporting due to the state of >> difficulties to access the ECN bits on received packets on some OS, and >> from user space QUIC implementations so that was never the intention. So I >> think this is only an editorial issue of not appear conflicting in the text. >> > Cheers >> > Magnus >> > From: QUIC <quic-boun...@ietf.org> on behalf of Martin Thomson < >> m...@lowentropy.net> >> > Date: Tuesday, 28 February 2023 at 01:23 >> > To: quic@ietf.org <quic@ietf.org> >> > Subject: Re: [Technical Errata Reported] RFC9000 (7374) >> > This change would not hurt if we were actively editing, but I don't >> think it is necessary. Not implementing ECN is a great way to ensure that >> ECN markings are unavailable to an endpoint. Bob is right that we create >> confusion by making a distinction in one place and not the other, but it >> doesn't really change the meaning. >> > >> > I suggest that we reassign this to Editorial and mark it Hold for >> Document Update. >> > >> > On Tue, Feb 28, 2023, at 10:04, RFC Errata System wrote: >> > > The following errata report has been submitted for RFC9000, >> > > "QUIC: A UDP-Based Multiplexed and Secure Transport". >> > > >> > > -------------------------------------- >> > > You may review the report below and at: >> > > https://www.rfc-editor.org/errata/eid7374 >> > > >> > > -------------------------------------- >> > > Type: Technical >> > > Reported by: Bob Briscoe <i...@bobbriscoe.net> >> > > >> > > Section: 13.4.1 >> > > >> > > Original Text >> > > ------------- >> > > If an >> > > endpoint does not implement ECN support or does not have access to >> > > received ECN fields, it does not report ECN counts for packets it >> > > receives. >> > > >> > > Even if an endpoint does not set an ECT field in packets it sends, >> > > the endpoint MUST provide feedback about ECN markings it receives, >> if >> > > these are accessible. >> > > >> > > Corrected Text >> > > -------------- >> > > If an >> > > endpoint does not have access to >> > > received ECN fields, it does not report ECN counts for packets it >> > > receives. >> > > >> > > Even if an endpoint does not set an ECT field in packets it sends, >> > > the endpoint MUST provide feedback about ECN markings it receives, >> if >> > > these are accessible. >> > > >> > > Notes >> > > ----- >> > > In the second sentence, the only allowed exception to "MUST provide >> > > feedback about received ECN markings" is inaccessibility. The first >> > > sentence contradicts this by allowing two exceptions: inaccessibility >> > > and just "not implementing ECN support". >> > > >> > > If "not implementing ECN support" was really intended to be an >> allowed >> > > exception, the capitalized "MUST" would have been pointless. >> > > >> > > Therefore it is proposed that the words "does not implement ECN >> support >> > > or " are deleted from the first paragraph. >> > > >> > > Instructions: >> > > ------------- >> > > This erratum is currently posted as "Reported". If necessary, please >> > > use "Reply All" to discuss whether it should be verified or >> > > rejected. When a decision is reached, the verifying party >> > > can log in to change the status and edit the report, if necessary. >> > > >> > > -------------------------------------- >> > > RFC9000 (draft-ietf-quic-transport-34) >> > > -------------------------------------- >> > > Title : QUIC: A UDP-Based Multiplexed and Secure >> Transport >> > > Publication Date : May 2021 >> > > Author(s) : J. Iyengar, Ed., M. Thomson, Ed. >> > > Category : PROPOSED STANDARD >> > > Source : QUIC >> > > Area : Transport >> > > Stream : IETF >> > > Verifying Party : IESG >> >> >>
