Subject: Re: [tsvwg] ECT(1): Plan for Vancouver

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 5 Mar 2020 09:42:51 +0000

Hi

I believe that the outline looks good over all .

One problem is the term "starvation". Depending on who you ask and what the
preferences are, you are likely to get different opinions.
The discussion I have seen on this list is more about that certain traffic
classes are potentially treated more unfairly for a number of reasons. But
based on how I interpret the term "starvation" I don't agree that the term
describes the concerns. Perhaps, what is needed is to define what goes under
"starvation". 

To take one analogy.. Income inequality is a growing concern in Sweden (yes
it's true also for socialist Sweden!). Still, it can't be claimed that
people are starving, people have food on the table. 

/I

> 
> During the interim meeting
(https://datatracker.ietf.org/meeting/interim-2020-
> tsvwg-01/session/tsvwg), the plan for dealing with ECT(1) in Vancouver was
> discussed based on version -02 of the chairs slides that are posted here:
> https://datatracker.ietf.org/doc/slides-interim-2020-tsvwg-01-sessa-ect1-
> chairs-slides/ .  The chairs believe that the rough consensus of the TSVWG
WG is
> to proceed as outlined on slides 5-7 of that slide deck, whose contents
are
> reproduced below.  Anyone who disagrees with this course of action should
> reply to the list with an explanation.
> 
> -- Slide 5: ECT(1): Agreeing on the Decision to be Made
> 
> 
> *         Next two slides: TSVWG Chairs attempt to state the decision
> 
>   *   Goal of this Interim Meeting: Rough consensus on decision to be made
>   *   Non?goal of this Interim Meeting: Actually make the decision
> 
> 
> *         Vancouver meeting plan (in order):
> 
>   1.  Begin with revised versions of next two slides
>   2.  L4S and SCE each present a few slides on best use of ECT(1) for the
Internet
>   3.  TSVWG Chairs set time & content guidelines, review and post in
advance (1
> week or more)
>      *   TSVWG Chairs frame and moderate Vancouver meeting discussion
>   4.  A small miracle happens, and the decision is made (we hope)
> 
> 
> 
> *         Now: Review next two slides for content
> 
> *         Do not attempt to make decision now.
> 
> -- Slide 6: DRAFT Vancouver SLIDE 1: Framing the ECT(1) Codepoint Decision
> 
> Background: RFC 4774 ?Specifying Alternate Semantics for the Explicit
> Congestion Notification (ECN) Field?
> 
>   *   RFC 4774 assumes DSCP as signal of alternate ECN semantics.
>   *   TSVWG situation: Two proposals that use ECT(1) as that signal [L4S,
SCE]
> 
> Decision: How ECT(1) signals alternate ECN semantics to network:
> 
>   1.  Input, e.g., classifier for ?queue? selection [L4S]
>   2.  Output, e.g., indication of lesser degree of ?queue? congestion
[SCE]
> At Internet scope: Choose at most one, not both.
> 
> -- Slide 7: DRAFT Vancouver SLIDE 2: Friendly Coexistence with Competing
> Traffic
> 
> Both proposals [L4S, SCE] employ RFC 4774 Option 3 (section 4.3):
> 
>   *   Incremental Deployment Option 3: Friendly Coexistence with Competing
> Traffic
>   *   Competing Traffic uses existing TCP congestion control, e.g., Reno,
Cubic,
> etc.
> Coexistence Focus: Shared bottleneck queue with ECN AQM [RFC 3168]
> 
>   *   FQ network nodes: Not a significant cause of coexistence problems
> Scenario: Traffic competition at shared bottleneck queue:
> 
>   1.  Starvation of one class of traffic is not an acceptable outcome.
>      *   Starvation may occur in network and/or at endpoints (e.g., caused
by
> congestion response)
>   2.  Competing Traffic drives bottleneck queue occupancy level.
> Proposals need to explain how to deal with this scenario.
> 
> Thanks, --David (on behalf of David, Wes & Gorry - TSVWG chairs)
> 
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <https://mailarchive.ietf.org/arch/browse/tsvwg/attachments/20200303/4af66
> b29/attachment.html>
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 03 Mar 2020 16:17:11 -0800
> From: Stephen Farrell via Datatracker <[email-masked]>
> To: <[email-masked]>
> Cc: [email-masked],
> 	[email-masked], [email-masked]
> Subject: [tsvwg] Secdir last call review of
> 	draft-ietf-tsvwg-datagram-plpmtud-15
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="utf-8"
> 
> Reviewer: Stephen Farrell
> Review result: Has Issues
> 
> 
> Hi,
> 
> As Hilary Orman always nicely says: do not be alarmed,
> this is just a secdir review:-)
> 
> I classed this as "has issues," but the issues below should be
> fairly easy to fix.  Maybe all but 2 are real issues that say are
> worth fixing, if I'm right about 'em (but I'm also often wrong
> too:-)
> 
> Cheers,
> S.
> 
> - Abstract: This draft aims for proposed standard but is
> updating a BCP (RFC8085/BCP145).  I'm happy to leave the
> process-lawyering for that to others.
> 
> - 4.1: I'm not sure if this is recommending that PLs allow for
> padding outside of cryptographic protection. If so, that
> seems like an anti-pattern when considering the overall set of
> requirements one might envisage for a PL. If not, that's fine,
> but would it be worth stating that?
> 
> - 4.4: Would you count the AEAD tag length in the MPS of an
> AEAD-encrypting PL or not? I assume not, and the tag length
> is counted as PL overhead even if sent as a sort-of trailer
> within the ciphertext?
> 
> - 4.4: What'd be the MPS etc for an MP-TCP-like PL? Is that
> well-defined?
> 
> - 4.5: (a nit) "The validation SHOULD utilize information that
>   it is not simple for an off-path attacker to determine
> [RFC8085]." A SHOULD that's that vague seems likely prone to
> issues. Might be best to just s/SHOULD/ought/ or something
> like that.
> 
> - 6.2.3: what if TLS record layer padding is being done as
> well?  Probably just needs a mention, so people don't get
> their sums/APIs wrong.
> 
> - 6.3: I am surprised that the QUIC description here is ready
> to be an RFC before QUIC itself. I do see there are
> normative references, but the potential for a breaking change
> still exists, and seems a bit unwise. (I'd suggest, holding
> this in the WG 'till the referenced QUIC drafts are in the RFC
> editor queue, or else taking that bit out and putting it into
> a new I-D.)
> 
> - section 9: Ok this is a stretch so maybe not worth bothering
>   with but... A PL doing all this may be emitting oddly sized
> padding octets from time to time that piggy-back on
> application data. That (number of padding octets and the
> pattern with which those are emitted) seems like a medium-nice
> covert channel e.g. for exfiltrating data, not necessarily to
> the packet destination but to anyone on-path who can observe
> the signal.
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Wed,  4 Mar 2020 01:58:33 -0800 (PST)
> From: RFC Errata System <[email-masked]>
> To: [email-masked], [email-masked], [email-masked],
> 	[email-masked]
> Cc: [email-masked], [email-masked], [email-masked],
> 	[email-masked]
> Subject: [tsvwg] [Errata Held for Document Update] RFC3168 (4754)
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=UTF-8
> 
> The following errata report has been held for document update
> for RFC3168, "The Addition of Explicit Congestion Notification (ECN) to
IP".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid4754
> 
> --------------------------------------
> Status: Held for Document Update
> Type: Editorial
> 
> Reported by: Bob Briscoe <[email-masked]>
> Date Reported: 2016-07-31
> Held by: Mirja K?hlewind (IESG)
> 
> Section: Header block
> 
> Original Text
> -------------
> Updates: 2474, 2401, 2003, 793
> 
> 
> Corrected Text
> --------------
> Updates: 2474, 2401, 2003, 2473, 793
> 
> Notes
> -----
> RFC 3168 updates RFC 2473 but does not indicate this in its header block.
> 
> Specifically, Section 9 of RFC 3168 defined processing of the ECN field
for
> Encapsulated Packets, which updated section 6.4 of RFC 2473, where the
> creation of the "IPv6 Tunnel Packet Traffic Class" was specified. RFC3168
also
> updated the decapsulation behaviour of the ECN field in an IPv6 tunnel
header,
> which had not been specified in RFC2473.
> 
> Note 1: As well as tagging RFC3168 with this erratum, RFC2473 needs to be
> tagged (in the RFC index and associated tools outputs) to indicate that it
is
> updated by RFC3168.
> 
> Note 2: Originally, the "Updates:" header of RFC3168 did not contain
"2003",
> which was added as a result of Errata ID 2660.
> 
> Note 3: The first sentence of section 9.1 in RFC3168 should also be
modified as
> follows:
> Original text:
>    The encapsulation of IP packet headers in tunnels is used in many
>    places, including IPsec and IP in IP [RFC2003].
> Corrected text:
>    The encapsulation of IP packet headers in tunnels is used in many
>    places, including IPsec and IP in IP [RFC2003, 2473].
> Comment:
>    Nowadays RFC2473 would be a normative reference, but RFC3168 pre-dated
> the categorisation of references into normative and informative.
> 
> Note 4: Section 9 of RFC3168 has since been updated by RFC6040.
Nonetheless,
> that is already correctly identified in RFC6040.
> 
> This reported errata has be moved to "Held for Document Update". While the
> reported problem is correct and needs to be addressed, it is not just an
errata
> but a larger oversight at publication time.
> 
> --------------------------------------
> RFC3168 (draft-ietf-tsvwg-ecn-04)
> --------------------------------------
> Title               : The Addition of Explicit Congestion Notification
(ECN) to IP
> Publication Date    : September 2001
> Author(s)           : K. Ramakrishnan, S. Floyd, D. Black
> Category            : PROPOSED STANDARD
> Source              : Transport Area Working Group
> Area                : Transport
> Stream              : IETF
> Verifying Party     : IESG
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Wed, 4 Mar 2020 11:06:15 +0100
> From: Mirja Kuehlewind <[email-masked]>
> To: [email-masked]
> Cc: Bob Briscoe <[email-masked]>, [email-masked],
> 	[email-masked],  IESG <[email-masked]>
> Subject: Re: [tsvwg] [Errata Held for Document Update] RFC3168 (4754)
> Message-ID: <[email-masked]>
> Content-Type: text/plain;	charset=utf-8
> 
> Hi tsvwg,
> 
> I just moved this errata to ?Held for Document Update? as there are
multiple
> points in this errata which go beyond just being an errata.
> 
> However there is also errata 4997 which only address the missing update:
> 
> https://www.rfc-editor.org/errata/eid4997
> 
> Should this errata be verified and the update tag added?
> 
> Mirja
> 
> 
> 
> > On 4. Mar 2020, at 10:58, RFC Errata System <[email-masked]>
> wrote:
> >
> > The following errata report has been held for document update
> > for RFC3168, "The Addition of Explicit Congestion Notification (ECN) to
IP".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid4754
> >
> > --------------------------------------
> > Status: Held for Document Update
> > Type: Editorial
> >
> > Reported by: Bob Briscoe <[email-masked]>
> > Date Reported: 2016-07-31
> > Held by: Mirja K?hlewind (IESG)
> >
> > Section: Header block
> >
> > Original Text
> > -------------
> > Updates: 2474, 2401, 2003, 793
> >
> >
> > Corrected Text
> > --------------
> > Updates: 2474, 2401, 2003, 2473, 793
> >
> > Notes
> > -----
> > RFC 3168 updates RFC 2473 but does not indicate this in its header
block.
> >
> > Specifically, Section 9 of RFC 3168 defined processing of the ECN field
for
> Encapsulated Packets, which updated section 6.4 of RFC 2473, where the
> creation of the "IPv6 Tunnel Packet Traffic Class" was specified. RFC3168
also
> updated the decapsulation behaviour of the ECN field in an IPv6 tunnel
header,
> which had not been specified in RFC2473.
> >
> > Note 1: As well as tagging RFC3168 with this erratum, RFC2473 needs to
be
> tagged (in the RFC index and associated tools outputs) to indicate that it
is
> updated by RFC3168.
> >
> > Note 2: Originally, the "Updates:" header of RFC3168 did not contain
"2003",
> which was added as a result of Errata ID 2660.
> >
> > Note 3: The first sentence of section 9.1 in RFC3168 should also be
modified as
> follows:
> > Original text:
> >   The encapsulation of IP packet headers in tunnels is used in many
> >   places, including IPsec and IP in IP [RFC2003].
> > Corrected text:
> >   The encapsulation of IP packet headers in tunnels is used in many
> >   places, including IPsec and IP in IP [RFC2003, 2473].
> > Comment:
> >   Nowadays RFC2473 would be a normative reference, but RFC3168 pre-dated
> the categorisation of references into normative and informative.
> >
> > Note 4: Section 9 of RFC3168 has since been updated by RFC6040.
> Nonetheless, that is already correctly identified in RFC6040.
> >
> > This reported errata has be moved to "Held for Document Update". While
the
> reported problem is correct and needs to be addressed, it is not just an
errata
> but a larger oversight at publication time.
> >
> > --------------------------------------
> > RFC3168 (draft-ietf-tsvwg-ecn-04)
> > --------------------------------------
> > Title               : The Addition of Explicit Congestion Notification
(ECN) to IP
> > Publication Date    : September 2001
> > Author(s)           : K. Ramakrishnan, S. Floyd, D. Black
> > Category            : PROPOSED STANDARD
> > Source              : Transport Area Working Group
> > Area                : Transport
> > Stream              : IETF
> > Verifying Party     : IESG
> >
> >
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Wed, 4 Mar 2020 11:12:02 +0100
> From: Mirja Kuehlewind <[email-masked]>
> To: [email-masked]
> Cc: [email-masked], [email-masked], Magnus Westerlund
> 	<[email-masked]>, [email-masked], Gorry
> 	Fairhurst <[email-masked]>, Wesley Eddy <wes@mti-
> systems.com>,
> 	Richard Scheffenegger <[email-masked]>
> Subject: Re: [tsvwg] [Editorial Errata Reported] RFC3168 (5966)
> Message-ID: <[email-masked]>
> Content-Type: text/plain;	charset=utf-8
> 
> Hi tsvwg,
> 
> Another errata on RFC3168.
> 
> I think this whole errata is a change that goes beyond just being an
errata,
> therefore I would suggest to mark this as ?Held for Document Update?.
> 
> I guess we could have an errata for only adding the word ?new? in section
6.1
> but that would need to be a separate errata then.
> 
> Any opinions?
> 
> Mirja
> 
> 
> 
> > On 26. Jan 2020, at 01:57, RFC Errata System <[email-masked]>
> wrote:
> >
> > The following errata report has been submitted for RFC3168,
> > "The Addition of Explicit Congestion Notification (ECN) to IP".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid5966
> >
> > --------------------------------------
> > Type: Editorial
> > Reported by: Richard Scheffenegger <[email-masked]>
> >
> > Section: 6.1
> >
> > Original Text
> > -------------
> > Section 6.1 states:
> >
> >      * The sender sets the CWR flag in the TCP header of the next
> >        packet sent to the receiver to acknowledge its receipt of and
> >        reaction to the ECN-Echo flag.
> >
> > section 6.1.2 clarifies:
> >
> >
> >   We ensure that the "Congestion Window Reduced" information is
> >   reliably delivered to the TCP receiver.  This comes about from the
> >   fact that if the new data packet carrying the CWR flag is dropped,
> >   then the TCP sender will have to again reduce its congestion window,
> >   and send another new data packet with the CWR flag set.  Thus, the
> >   CWR bit in the TCP header SHOULD NOT be set on retransmitted packets.
> >
> >   When the TCP data sender is ready to set the CWR bit after reducing
> >   the congestion window, it SHOULD set the CWR bit only on the first
> >   new data packet that it transmits.
> >
> > Corrected Text
> > --------------
> > Section 6.1 should say:
> >
> >
> >      * The sender sets the CWR flag in the TCP header of the next new
> >        data packet sent to the receiver to acknowledge its receipt of
and
> >        reaction to the ECN-Echo flag.
> >
> > Section 6.1.2 should clarify, that a receiver MUST process an incoming
CWR
> > on any incoming segment, and not exclude non-new-data segments.
> >
> > This clarification allows new semantics to be used by a sender-side only
> > change, and should be taken into account by all documents updating
RFC3168.
> >
> > Notes
> > -----
> > Discrepancies in the above text lead to poorly interoperating
implementations.
> In NetBSD (and derived implementationd), the "SHOULD set CWR on new data"
> was used liberal in setting CWR on the very next packet to be sent,
regardless of
> type. While at the same time the Linux implementation performed very
stingent
> tests on the receiver side, if the sender was complying with the "SHOULD"
like a
> "MUST". In request-response session with frequently changing data
direction,
> this leads to a collapse of the congestion window, as the *BSD side will
continue
> to interpret the still latched ECE flag as an indication of another RTT of
> congestion.
> >
> > 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.
> >
> > --------------------------------------
> > RFC3168 (draft-ietf-tsvwg-ecn-04)
> > --------------------------------------
> > Title               : The Addition of Explicit Congestion Notification
(ECN) to IP
> > Publication Date    : September 2001
> > Author(s)           : K. Ramakrishnan, S. Floyd, D. Black
> > Category            : PROPOSED STANDARD
> > Source              : Transport Area Working Group
> > Area                : Transport
> > Stream              : IETF
> > Verifying Party     : IESG
> >
> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Wed, 4 Mar 2020 11:45:48 +0100
> From: "Richard Scheffenegger" <[email-masked]>
> To: "Mirja Kuehlewind" <[email-masked]>,	<[email-masked]>
> Cc: <[email-masked]>, <[email-masked]>, "Magnus Westerlund"
> 	<[email-masked]>, <[email-masked]>, "Gorry
> 	Fairhurst" <[email-masked]>, "Wesley Eddy" <wes@mti-
> systems.com>
> Subject: Re: [tsvwg] [Editorial Errata Reported] RFC3168 (5966)
> Message-ID: <32AD4D853B034B2EA08C71260781C3AC@srichardlxp2>
> Content-Type: text/plain; format=flowed; charset="UTF-8";
> 	reply-type=original
> 
> 
> I think clarification of the CWR handling should also be mentioned in
ECN++,
> since ECT setting there is allowed on every packet.
> 
> In the fbsd environment, as 3168 allows ECT only on new data packets while
> sending, it is easy to send out CWR only when ECT is also set (in the same
> check).
> 
> Simply enhancing this in ECN++ to allow setting ECT on any packet, may
> result in also sending CWR on control packets without data. And Bob made a
> compelling case, a sender needs to reliably know when a window, during
which
> congestion occured, ends (that is, sending cwr only with new data, or
> differently, setting cwr when the octete snd_max+1 is sent in the stream.
> 
> E.g. in ecn++, the below corrected text would be prudent to have.
> 
> Best regards,
>    Richard
> 
> ----- Original Message -----
> From: "Mirja Kuehlewind" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; "Magnus Westerlund"
> <[email-masked]>; <[email-masked]>; "Gorry
> Fairhurst"
> <[email-masked]>; "Wesley Eddy" <[email-masked]>; "Richard
> Scheffenegger" <[email-masked]>
> Sent: Wednesday, March 04, 2020 11:12 AM
> Subject: Re: [Editorial Errata Reported] RFC3168 (5966)
> 
> 
> Hi tsvwg,
> 
> Another errata on RFC3168.
> 
> I think this whole errata is a change that goes beyond just being an
errata,
> therefore I would suggest to mark this as ?Held for Document Update?.
> 
> I guess we could have an errata for only adding the word ?new? in section
> 6.1 but that would need to be a separate errata then.
> 
> Any opinions?
> 
> Mirja
> 
> 
> 
> > On 26. Jan 2020, at 01:57, RFC Errata System <[email-masked]>
> > wrote:
> >
> > The following errata report has been submitted for RFC3168,
> > "The Addition of Explicit Congestion Notification (ECN) to IP".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid5966
> >
> > --------------------------------------
> > Type: Editorial
> > Reported by: Richard Scheffenegger <[email-masked]>
> >
> > Section: 6.1
> >
> > Original Text
> > -------------
> > Section 6.1 states:
> >
> >      * The sender sets the CWR flag in the TCP header of the next
> >        packet sent to the receiver to acknowledge its receipt of and
> >        reaction to the ECN-Echo flag.
> >
> > section 6.1.2 clarifies:
> >
> >
> >   We ensure that the "Congestion Window Reduced" information is
> >   reliably delivered to the TCP receiver.  This comes about from the
> >   fact that if the new data packet carrying the CWR flag is dropped,
> >   then the TCP sender will have to again reduce its congestion window,
> >   and send another new data packet with the CWR flag set.  Thus, the
> >   CWR bit in the TCP header SHOULD NOT be set on retransmitted packets.
> >
> >   When the TCP data sender is ready to set the CWR bit after reducing
> >   the congestion window, it SHOULD set the CWR bit only on the first
> >   new data packet that it transmits.
> >
> > Corrected Text
> > --------------
> > Section 6.1 should say:
> >
> >
> >      * The sender sets the CWR flag in the TCP header of the next new
> >        data packet sent to the receiver to acknowledge its receipt of
and
> >        reaction to the ECN-Echo flag.
> >
> > Section 6.1.2 should clarify, that a receiver MUST process an incoming
CWR
> > on any incoming segment, and not exclude non-new-data segments.
> >
> > This clarification allows new semantics to be used by a sender-side only
> > change, and should be taken into account by all documents updating
> > RFC3168.
> >
> > Notes
> > -----
> > Discrepancies in the above text lead to poorly interoperating
> > implementations. In NetBSD (and derived implementationd), the "SHOULD
set
> > CWR on new data" was used liberal in setting CWR on the very next packet
> > to be sent, regardless of type. While at the same time the Linux
> > implementation performed very stingent tests on the receiver side, if
the
> > sender was complying with the "SHOULD" like a "MUST". In
request-response
> > session with frequently changing data direction, this leads to a
collapse
> > of the congestion window, as the *BSD side will continue to interpret
the
> > still latched ECE flag as an indication of another RTT of congestion.
> >
> > 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.
> >
> > --------------------------------------
> > RFC3168 (draft-ietf-tsvwg-ecn-04)
> > --------------------------------------
> > Title               : The Addition of Explicit Congestion Notification
> > (ECN) to IP
> > Publication Date    : September 2001
> > Author(s)           : K. Ramakrishnan, S. Floyd, D. Black
> > Category            : PROPOSED STANDARD
> > Source              : Transport Area Working Group
> > Area                : Transport
> > Stream              : IETF
> > Verifying Party     : IESG
> >
> 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Wed,  4 Mar 2020 03:30:26 -0800 (PST)
> From: RFC Errata System <[email-masked]>
> To: [email-masked], [email-masked], [email-masked],
> 	[email-masked], [email-masked],
> [email-masked]
> Cc: [email-masked], [email-masked], [email-masked],
> 	[email-masked]
> Subject: [tsvwg] [Errata Held for Document Update] RFC6335 (4999)
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=UTF-8
> 
> The following errata report has been held for document update
> for RFC6335, "Internet Assigned Numbers Authority (IANA) Procedures for
the
> Management of the Service Name and Transport Protocol Port Number
> Registry".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid4999
> 
> --------------------------------------
> Status: Held for Document Update
> Type: Technical
> 
> Reported by: Mark Nottingham <[email-masked]>
> Date Reported: 2017-04-19
> Held by: Mirja K?hlewind (IESG)
> 
> Section: GLOBAL
> 
> Original Text
> -------------
> 
> 
> Corrected Text
> --------------
> 
> 
> Notes
> -----
> Many port number assignments are to individuals, but the document does not
> contemplate how they should be handled when the assignee is dead or
> otherwise can't be contacted.
> 
> The most obvious procedure to follow is a transfer (8.5), but that
requires
> de-assignment (8.2), and that doesn't cover the case above.
> 
> --------------------------------------
> RFC6335 (draft-ietf-tsvwg-iana-ports-10)
> --------------------------------------
> Title               : Internet Assigned Numbers Authority (IANA)
Procedures for the
> Management of the Service Name and Transport Protocol Port Number Registry
> Publication Date    : August 2011
> Author(s)           : M. Cotton, L. Eggert, J. Touch, M. Westerlund, S.
Cheshire
> Category            : BEST CURRENT PRACTICE
> Source              : Transport Area Working Group
> Area                : Transport
> Stream              : IETF
> Verifying Party     : IESG
> 
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Wed, 4 Mar 2020 06:52:15 -0800
> From: Joseph Touch <[email-masked]>
> To: RFC Errata System <[email-masked]>
> Cc: Mark Nottingham <[email-masked]>, [email-masked],
> 	[email-masked], "Dr. Joe Touch" <[email-masked]>,
> 	[email-masked], [email-masked],
> 	[email-masked], [email-masked], [email-masked]
> Subject: Re: [tsvwg] [Errata Held for Document Update] RFC6335 (4999)
> Message-ID: <[email-masked]>
> Content-Type: text/plain;	charset=utf-8
> 
> Hi, all,
> 
> I disagree; Sec 8.4 allows for IANA-initiated deassignment. The
deassignment
> procedures there and in Sec 8.3 make it clear that there?s not much point
in
> focusing on cases when the assignee can?t be contacted (for whatever
reason).
> 
> Further, sec 7.9 of RFC 7605 underscores a point made throughout RFC 6335
-
> that port assignments aren?t intended to be changed. So the lack of such a
> contact isn?t really an issue except in very rare cases (for which the
exception
> processes in RFC 6335 are already sufficient).
> 
> Joe
> 
> > On Mar 4, 2020, at 3:30 AM, RFC Errata System
<[email-masked]>
> wrote:
> >
> > The following errata report has been held for document update
> > for RFC6335, "Internet Assigned Numbers Authority (IANA) Procedures for
the
> Management of the Service Name and Transport Protocol Port Number
> Registry".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid4999
> >
> > --------------------------------------
> > Status: Held for Document Update
> > Type: Technical
> >
> > Reported by: Mark Nottingham <[email-masked]>
> > Date Reported: 2017-04-19
> > Held by: Mirja K?hlewind (IESG)
> >
> > Section: GLOBAL
> >
> > Original Text
> > -------------
> >
> >
> > Corrected Text
> > --------------
> >
> >
> > Notes
> > -----
> > Many port number assignments are to individuals, but the document does
not
> > contemplate how they should be handled when the assignee is dead or
> > otherwise can't be contacted.
> >
> > The most obvious procedure to follow is a transfer (8.5), but that
requires
> > de-assignment (8.2), and that doesn't cover the case above.
> >
> > --------------------------------------
> > RFC6335 (draft-ietf-tsvwg-iana-ports-10)
> > --------------------------------------
> > Title               : Internet Assigned Numbers Authority (IANA)
Procedures for the
> Management of the Service Name and Transport Protocol Port Number Registry
> > Publication Date    : August 2011
> > Author(s)           : M. Cotton, L. Eggert, J. Touch, M. Westerlund, S.
Cheshire
> > Category            : BEST CURRENT PRACTICE
> > Source              : Transport Area Working Group
> > Area                : Transport
> > Stream              : IETF
> > Verifying Party     : IESG
> >
> 
> 
> 
> ------------------------------
> 
> Message: 9
> Date: Wed, 4 Mar 2020 16:33:06 +0100
> From: Mirja Kuehlewind <[email-masked]>
> To: Joseph Touch <[email-masked]>
> Cc: RFC Errata System <[email-masked]>, [email-masked],
> 	[email-masked], [email-masked], "Dr. Joe Touch"
> 	<[email-masked]>, Mark Nottingham <[email-masked]>, [email-masked],
> 	[email-masked]
> Subject: Re: [tsvwg] [Errata Held for Document Update] RFC6335 (4999)
> Message-ID: <[email-masked]>
> Content-Type: text/plain;	charset=utf-8
> 
> Hi Joe,
> 
> I?ve put this into ?hold for document update" because I think that is a
good
> point that can be further clarified if we ever update RFC6335 and thus
this is a
> good tool to remember. This was also how this was meant to be treated when
> Mark filed the errata; originally there was a note that this should be
hold for
> update from him which I obviously removed when I made the status change.
Of
> course anything we may or may not want to change needs further discussion.
> 
> Mirja
> 
> 
> 
> > On 4. Mar 2020, at 15:52, Joseph Touch <[email-masked]> wrote:
> >
> > Hi, all,
> >
> > I disagree; Sec 8.4 allows for IANA-initiated deassignment. The
deassignment
> procedures there and in Sec 8.3 make it clear that there?s not much point
in
> focusing on cases when the assignee can?t be contacted (for whatever
reason).
> >
> > Further, sec 7.9 of RFC 7605 underscores a point made throughout RFC
6335 -
> that port assignments aren?t intended to be changed. So the lack of such a
> contact isn?t really an issue except in very rare cases (for which the
exception
> processes in RFC 6335 are already sufficient).
> >
> > Joe
> >
> >> On Mar 4, 2020, at 3:30 AM, RFC Errata System
<[email-masked]>
> wrote:
> >>
> >> The following errata report has been held for document update
> >> for RFC6335, "Internet Assigned Numbers Authority (IANA) Procedures for
the
> Management of the Service Name and Transport Protocol Port Number
> Registry".
> >>
> >> --------------------------------------
> >> You may review the report below and at:
> >> https://www.rfc-editor.org/errata/eid4999
> >>
> >> --------------------------------------
> >> Status: Held for Document Update
> >> Type: Technical
> >>
> >> Reported by: Mark Nottingham <[email-masked]>
> >> Date Reported: 2017-04-19
> >> Held by: Mirja K?hlewind (IESG)
> >>
> >> Section: GLOBAL
> >>
> >> Original Text
> >> -------------
> >>
> >>
> >> Corrected Text
> >> --------------
> >>
> >>
> >> Notes
> >> -----
> >> Many port number assignments are to individuals, but the document does
not
> >> contemplate how they should be handled when the assignee is dead or
> >> otherwise can't be contacted.
> >>
> >> The most obvious procedure to follow is a transfer (8.5), but that
requires
> >> de-assignment (8.2), and that doesn't cover the case above.
> >>
> >> --------------------------------------
> >> RFC6335 (draft-ietf-tsvwg-iana-ports-10)
> >> --------------------------------------
> >> Title               : Internet Assigned Numbers Authority (IANA)
Procedures for the
> Management of the Service Name and Transport Protocol Port Number Registry
> >> Publication Date    : August 2011
> >> Author(s)           : M. Cotton, L. Eggert, J. Touch, M. Westerlund, S.
Cheshire
> >> Category            : BEST CURRENT PRACTICE
> >> Source              : Transport Area Working Group
> >> Area                : Transport
> >> Stream              : IETF
> >> Verifying Party     : IESG
> >>
> >
> >
> 
> 
> 
> ------------------------------
> 
> Message: 10
> Date: Wed, 4 Mar 2020 07:44:05 -0800
> From: Joseph Touch <[email-masked]>
> To: Mirja Kuehlewind <[email-masked]>
> Cc: Magnus Westerlund <[email-masked]>, TSVWG
> 	<[email-masked]>, "Dr. Joe Touch" <[email-masked]>, Mark Nottingham
> 	<[email-masked]>, IESG <[email-masked]>, [email-masked], RFC
> 	Errata System <[email-masked]>
> Subject: Re: [tsvwg] [Errata Held for Document Update] RFC6335 (4999)
> Message-ID: <[email-masked]>
> Content-Type: text/plain;	charset=utf-8
> 
> I think there are two related but importantly distinct issues, if we want
to do
> that:
> 
> - orphans (assignee cannot be contacted, for whatever reason)
> - organizational assignee transitions (company dissolves, takeover, etc)
> 
> Both of these arguably involve legal issues that may be difficult to
navigate. If a
> port goes with the assigned company, then is it also similarly inherited
upon
> death?
> 
> The note should point out that the assignee isn?t a shepherd of the
assignment;
> changes are always supposed to be a very rare exception exactly because it
is
> nearly impossible to prove a negative (that no deployed systems are
affected by
> changes).
> 
> Joe
> 
> > On Mar 4, 2020, at 7:33 AM, Mirja Kuehlewind <[email-masked]>
wrote:
> >
> > Hi Joe,
> >
> > I?ve put this into ?hold for document update" because I think that is a
good
> point that can be further clarified if we ever update RFC6335 and thus
this is a
> good tool to remember. This was also how this was meant to be treated when
> Mark filed the errata; originally there was a note that this should be
hold for
> update from him which I obviously removed when I made the status change.
Of
> course anything we may or may not want to change needs further discussion.
> >
> > Mirja
> >
> >
> >
> >> On 4. Mar 2020, at 15:52, Joseph Touch <[email-masked]> wrote:
> >>
> >> Hi, all,
> >>
> >> I disagree; Sec 8.4 allows for IANA-initiated deassignment. The
deassignment
> procedures there and in Sec 8.3 make it clear that there?s not much point
in
> focusing on cases when the assignee can?t be contacted (for whatever
reason).
> >>
> >> Further, sec 7.9 of RFC 7605 underscores a point made throughout RFC
6335
> - that port assignments aren?t intended to be changed. So the lack of such
a
> contact isn?t really an issue except in very rare cases (for which the
exception
> processes in RFC 6335 are already sufficient).
> >>
> >> Joe
> >>
> >>> On Mar 4, 2020, at 3:30 AM, RFC Errata System
<[email-masked]>
> wrote:
> >>>
> >>> The following errata report has been held for document update
> >>> for RFC6335, "Internet Assigned Numbers Authority (IANA) Procedures
for
> the Management of the Service Name and Transport Protocol Port Number
> Registry".
> >>>
> >>> --------------------------------------
> >>> You may review the report below and at:
> >>> https://www.rfc-editor.org/errata/eid4999
> >>>
> >>> --------------------------------------
> >>> Status: Held for Document Update
> >>> Type: Technical
> >>>
> >>> Reported by: Mark Nottingham <[email-masked]>
> >>> Date Reported: 2017-04-19
> >>> Held by: Mirja K?hlewind (IESG)
> >>>
> >>> Section: GLOBAL
> >>>
> >>> Original Text
> >>> -------------
> >>>
> >>>
> >>> Corrected Text
> >>> --------------
> >>>
> >>>
> >>> Notes
> >>> -----
> >>> Many port number assignments are to individuals, but the document does
> not
> >>> contemplate how they should be handled when the assignee is dead or
> >>> otherwise can't be contacted.
> >>>
> >>> The most obvious procedure to follow is a transfer (8.5), but that
requires
> >>> de-assignment (8.2), and that doesn't cover the case above.
> >>>
> >>> --------------------------------------
> >>> RFC6335 (draft-ietf-tsvwg-iana-ports-10)
> >>> --------------------------------------
> >>> Title               : Internet Assigned Numbers Authority (IANA)
Procedures for
> the Management of the Service Name and Transport Protocol Port Number
> Registry
> >>> Publication Date    : August 2011
> >>> Author(s)           : M. Cotton, L. Eggert, J. Touch, M. Westerlund,
S. Cheshire
> >>> Category            : BEST CURRENT PRACTICE
> >>> Source              : Transport Area Working Group
> >>> Area                : Transport
> >>> Stream              : IETF
> >>> Verifying Party     : IESG
> >>>
> >>
> >>
> >
> 
> 
> 
> ------------------------------
> 
> Message: 11
> Date: Wed, 4 Mar 2020 16:55:19 +0100
> From: Mirja Kuehlewind <[email-masked]>
> To: Joseph Touch <[email-masked]>
> Cc: Magnus Westerlund <[email-masked]>, TSVWG
> 	<[email-masked]>, Mark Nottingham <[email-masked]>,
> 	[email-masked]
> Subject: Re: [tsvwg] [Errata Held for Document Update] RFC6335 (4999)
> Message-ID: <[email-masked]>
> Content-Type: text/plain;	charset=utf-8
> 
> Hi Joe,
> 
> At this point I can not easily change the note anymore. I would need to
ask the
> RFC Editor to move the state back to ?Reported" but given this is not a
verified
> errata but just a reminder for a potentially document update, I?m not sure
if that
> really needed.
> 
> Mirja
> 
> 
> 
> > On 4. Mar 2020, at 16:44, Joseph Touch <[email-masked]> wrote:
> >
> > I think there are two related but importantly distinct issues, if we
want to do
> that:
> >
> > - orphans (assignee cannot be contacted, for whatever reason)
> > - organizational assignee transitions (company dissolves, takeover, etc)
> >
> > Both of these arguably involve legal issues that may be difficult to
navigate. If
> a port goes with the assigned company, then is it also similarly inherited
upon
> death?
> >
> > The note should point out that the assignee isn?t a shepherd of the
> assignment; changes are always supposed to be a very rare exception
exactly
> because it is nearly impossible to prove a negative (that no deployed
systems are
> affected by changes).
> >
> > Joe
> >
> >> On Mar 4, 2020, at 7:33 AM, Mirja Kuehlewind <[email-masked]>
wrote:
> >>
> >> Hi Joe,
> >>
> >> I?ve put this into ?hold for document update" because I think that is a
good
> point that can be further clarified if we ever update RFC6335 and thus
this is a
> good tool to remember. This was also how this was meant to be treated when
> Mark filed the errata; originally there was a note that this should be
hold for
> update from him which I obviously removed when I made the status change.
Of
> course anything we may or may not want to change needs further discussion.
> >>
> >> Mirja
> >>
> >>
> >>
> >>> On 4. Mar 2020, at 15:52, Joseph Touch <[email-masked]> wrote:
> >>>
> >>> Hi, all,
> >>>
> >>> I disagree; Sec 8.4 allows for IANA-initiated deassignment. The
> deassignment procedures there and in Sec 8.3 make it clear that there?s
not
> much point in focusing on cases when the assignee can?t be contacted (for
> whatever reason).
> >>>
> >>> Further, sec 7.9 of RFC 7605 underscores a point made throughout RFC
6335
> - that port assignments aren?t intended to be changed. So the lack of such
a
> contact isn?t really an issue except in very rare cases (for which the
exception
> processes in RFC 6335 are already sufficient).
> >>>
> >>> Joe
> >>>
> >>>> On Mar 4, 2020, at 3:30 AM, RFC Errata System <rfc-editor@rfc-
> editor.org> wrote:
> >>>>
> >>>> The following errata report has been held for document update
> >>>> for RFC6335, "Internet Assigned Numbers Authority (IANA) Procedures
for
> the Management of the Service Name and Transport Protocol Port Number
> Registry".
> >>>>
> >>>> --------------------------------------
> >>>> You may review the report below and at:
> >>>> https://www.rfc-editor.org/errata/eid4999
> >>>>
> >>>> --------------------------------------
> >>>> Status: Held for Document Update
> >>>> Type: Technical
> >>>>
> >>>> Reported by: Mark Nottingham <[email-masked]>
> >>>> Date Reported: 2017-04-19
> >>>> Held by: Mirja K?hlewind (IESG)
> >>>>
> >>>> Section: GLOBAL
> >>>>
> >>>> Original Text
> >>>> -------------
> >>>>
> >>>>
> >>>> Corrected Text
> >>>> --------------
> >>>>
> >>>>
> >>>> Notes
> >>>> -----
> >>>> Many port number assignments are to individuals, but the document
does
> not
> >>>> contemplate how they should be handled when the assignee is dead or
> >>>> otherwise can't be contacted.
> >>>>
> >>>> The most obvious procedure to follow is a transfer (8.5), but that
requires
> >>>> de-assignment (8.2), and that doesn't cover the case above.
> >>>>
> >>>> --------------------------------------
> >>>> RFC6335 (draft-ietf-tsvwg-iana-ports-10)
> >>>> --------------------------------------
> >>>> Title               : Internet Assigned Numbers Authority (IANA)
Procedures for
> the Management of the Service Name and Transport Protocol Port Number
> Registry
> >>>> Publication Date    : August 2011
> >>>> Author(s)           : M. Cotton, L. Eggert, J. Touch, M. Westerlund,
S. Cheshire
> >>>> Category            : BEST CURRENT PRACTICE
> >>>> Source              : Transport Area Working Group
> >>>> Area                : Transport
> >>>> Stream              : IETF
> >>>> Verifying Party     : IESG
> >>>>
> >>>
> >>>
> >>
> >
> >
> 
> 
> 
> ------------------------------
> 
> Message: 12
> Date: Wed, 4 Mar 2020 15:55:20 +0000
> From: Gorry Fairhurst <[email-masked]>
> To: Stephen Farrell <[email-masked]>, [email-masked]
> Cc: [email-masked],
> 	[email-masked], [email-masked]
> Subject: Re: [tsvwg] Secdir last call review of
> 	draft-ietf-tsvwg-datagram-plpmtud-15
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Thanks for this review Stephen.
> 
> On 04/03/2020 00:17, Stephen Farrell via Datatracker wrote:
> > Reviewer: Stephen Farrell
> > Review result: Has Issues
> >
> >
> > Hi,
> >
> > As Hilary Orman always nicely says: do not be alarmed,
> > this is just a secdir review:-)
> >
> > I classed this as "has issues," but the issues below should be
> > fairly easy to fix.  Maybe all but 2 are real issues that say are
> > worth fixing, if I'm right about 'em (but I'm also often wrong
> > too:-)
> >
> > Cheers,
> > S.
> >
> > - Abstract: This draft aims for proposed standard but is
> > updating a BCP (RFC8085/BCP145).  I'm happy to leave the
> > process-lawyering for that to others.
> We spoke with our TSV ADs and they? don't see any issue with this. BCP
> and Standards track are equivalent.
> > - 4.1: I'm not sure if this is recommending that PLs allow for
> > padding outside of cryptographic protection. If so, that
> > seems like an anti-pattern when considering the overall set of
> > requirements one might envisage for a PL. If not, that's fine,
> > but would it be worth stating that?
> We suggest adding to the security considerations, see later.
> > - 4.4: Would you count the AEAD tag length in the MPS of an
> > AEAD-encrypting PL or not? I assume not, and the tag length
> > is counted as PL overhead even if sent as a sort-of trailer
> > within the ciphertext?
> 
> Yes, all PL-overhead is included, but I think worth noting explicitly in
> Section 4.1 to avoid doubt. I suggest we add:
> 
> OLD:
> Protocols that permit exchange of control messages
> (without an application data block) can generate a probe packet by
> extending a control message with padding data.
> NEW:
> Protocols that permit exchange of control messages
> (without an application data block) can generate a probe packet by
> extending a control message with padding data. The total size of a
> probe packet includes all headers and padding added to the payload data
> being sent (e.g., including  protocol option fields, security-related
> fields such as an AEAD tag and TLS record layer padding).
> 
> > - 4.4: What'd be the MPS etc for an MP-TCP-like PL? Is that
> > well-defined?
> 
> For MP-TCP this isn't an issue, but each PL could have it's own issues
> and needs to work out what MPS means.
> 
> > - 4.5: (a nit) "The validation SHOULD utilize information that
> >    it is not simple for an off-path attacker to determine
> > [RFC8085]." A SHOULD that's that vague seems likely prone to
> > issues. Might be best to just s/SHOULD/ought/ or something
> > like that.
> 
> RFC8085 does provide some examples, and this is a common-enough
> transport requirement to protect from DDOS. Could the SHOULD be retained
> and this be fixed by a more specific reference perhaps?
> 
> (see Section 5.1 of [RFC8085]).
> 
> > - 6.2.3: what if TLS record layer padding is being done as
> > well?  Probably just needs a mention, so people don't get
> > their sums/APIs wrong.
> Agree. Please see proposeed text above and the proposed adds to the
> security considerations below.
> > - 6.3: I am surprised that the QUIC description here is ready
> > to be an RFC before QUIC itself. I do see there are
> > normative references, but the potential for a breaking change
> > still exists, and seems a bit unwise. (I'd suggest, holding
> > this in the WG 'till the referenced QUIC drafts are in the RFC
> > editor queue, or else taking that bit out and putting it into
> > a new I-D.)
> >
> > - section 9: Ok this is a stretch so maybe not worth bothering
> >    with but... A PL doing all this may be emitting oddly sized
> > padding octets from time to time that piggy-back on
> > application data. That (number of padding octets and the
> > pattern with which those are emitted) seems like a medium-nice
> > covert channel e.g. for exfiltrating data, not necessarily to
> > the packet destination but to anyone on-path who can observe
> > the signal.
> 
> I think this is useful. Security thoughts are always welcome. How about
> adding two extra paras to the Security Considerations, are these near?:
> 
> "DPLPMTUD methods can introduce padding data to inflate the length of
> the datagram to the total size required for a probe packet. The total
> size of a probe packet includes all headers and padding added to the
> payload data being sent (e.g., including security-related fields such as
> an AEAD tag and TLS record layer padding). The value of the padding data
> does not influence the DPLPMTUD search algorithm, and therefore needs to
> be set consistent with the policy of the PL.? A secure PL MUST provide
> cryptographic protection for the padding if this is needed to satisfy
> the security requirements of that PL.
> 
> A PL that implements this spec would send probe packets, whose size and
> frequency can be observed by the network. Designers of search algorithms
> need to consider whether the size of probe packets and the pattern of
> probing could result in a potential covert channel (e.g., for
> exfiltrating data to an on-path device or the endpoint of the connection).
"
> 
> Gorry
> 
> >
> 
> 
> 
> ------------------------------
> 
> Message: 13
> Date: Wed, 4 Mar 2020 17:42:15 +0000
> From: Bob Briscoe <[email-masked]>
> To: [email-masked]
> Cc: RFC Errata System <[email-masked]>, KK Ramakrishnan
> 	<[email-masked]>, "BLack, David" <[email-masked]>,
> [email-masked],
> 	[email-masked]
> Subject: Re: [tsvwg] [Errata Held for Document Update] RFC3168 (4754)
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
> 
> Mirja,
> 
> I don't even remember writing this Erratum, it's so old (or maybe it's
> me that's so old - don't comment on that tho).
> 
> The main reason for reporting omissions in the "Updates" header is to
> ensure that people who are responsible for implementations of updated
> RFCs know that they are meant to watch RFC3168 (and its updates). It
> would be useful if the tools view showed accepted errata to the Updates
> header below the "Updated by" field (in the grey area at the top of the
> HTML of a draft).
> 
> Any chance that this is possible?
> 
> 
> FYI, according to the 3168 errata list, there are 3 missing refs in the
> updates header of 3168 now. But they each have a different status:
> 
> Errata ID: 2660 <https://www.rfc-editor.org/errata/eid2660>*Status:
> Verified* Add "Updates: 2003"
> Errata ID: 4997 <https://www.rfc-editor.org/errata/eid4997> *Status:
> Reported *Add "Updates: 2460"
> Errata ID: 4754 <https://www.rfc-editor.org/errata/eid4754>*Status: Held
> for Document Update *Add "Updates: 2473"
> 
> 
> Bob
> 
> On 04/03/2020 09:58, RFC Errata System wrote:
> > The following errata report has been held for document update
> > for RFC3168, "The Addition of Explicit Congestion Notification (ECN) to
IP".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid4754
> >
> > --------------------------------------
> > Status: Held for Document Update
> > Type: Editorial
> >
> > Reported by: Bob Briscoe <[email-masked]>
> > Date Reported: 2016-07-31
> > Held by: Mirja K?hlewind (IESG)
> >
> > Section: Header block
> >
> > Original Text
> > -------------
> > Updates: 2474, 2401, 2003, 793
> >
> >
> > Corrected Text
> > --------------
> > Updates: 2474, 2401, 2003, 2473, 793
> >
> > Notes
> > -----
> > RFC 3168 updates RFC 2473 but does not indicate this in its header
block.
> >
> > Specifically, Section 9 of RFC 3168 defined processing of the ECN field
for
> Encapsulated Packets, which updated section 6.4 of RFC 2473, where the
> creation of the "IPv6 Tunnel Packet Traffic Class" was specified. RFC3168
also
> updated the decapsulation behaviour of the ECN field in an IPv6 tunnel
header,
> which had not been specified in RFC2473.
> >
> > Note 1: As well as tagging RFC3168 with this erratum, RFC2473 needs to
be
> tagged (in the RFC index and associated tools outputs) to indicate that it
is
> updated by RFC3168.
> >
> > Note 2: Originally, the "Updates:" header of RFC3168 did not contain
"2003",
> which was added as a result of Errata ID 2660.
> >
> > Note 3: The first sentence of section 9.1 in RFC3168 should also be
modified as
> follows:
> > Original text:
> >     The encapsulation of IP packet headers in tunnels is used in many
> >     places, including IPsec and IP in IP [RFC2003].
> > Corrected text:
> >     The encapsulation of IP packet headers in tunnels is used in many
> >     places, including IPsec and IP in IP [RFC2003, 2473].
> > Comment:
> >     Nowadays RFC2473 would be a normative reference, but RFC3168 pre-
> dated the categorisation of references into normative and informative.
> >
> > Note 4: Section 9 of RFC3168 has since been updated by RFC6040.
> Nonetheless, that is already correctly identified in RFC6040.
> >
> > This reported errata has be moved to "Held for Document Update". While
the
> reported problem is correct and needs to be addressed, it is not just an
errata
> but a larger oversight at publication time.
> >
> > --------------------------------------
> > RFC3168 (draft-ietf-tsvwg-ecn-04)
> > --------------------------------------
> > Title               : The Addition of Explicit Congestion Notification
(ECN) to IP
> > Publication Date    : September 2001
> > Author(s)           : K. Ramakrishnan, S. Floyd, D. Black
> > Category            : PROPOSED STANDARD
> > Source              : Transport Area Working Group
> > Area                : Transport
> > Stream              : IETF
> > Verifying Party     : IESG
> 
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <https://mailarchive.ietf.org/arch/browse/tsvwg/attachments/20200304/dd74
> 294d/attachment.html>
> 
> ------------------------------
> 
> Message: 14
> Date: Wed, 4 Mar 2020 19:37:48 +0100
> From: Mirja Kuehlewind <[email-masked]>
> To: Bob Briscoe <[email-masked]>
> Cc: "BLack, David" <[email-masked]>, TSVWG <[email-masked]>, KK
> 	Ramakrishnan <[email-masked]>
> Subject: Re: [tsvwg] [Errata Held for Document Update] RFC3168 (4754)
> Message-ID: <[email-masked]>
> Content-Type: text/plain;	charset=utf-8
> 
> Hi Bob,
> 
> I?ve sent a note about this on tsvwg list.
> 
> However, I now see that I got a bit confused about this. I thought this
errata and
> 4997 would add the same RFC in updates, which is not the case as you
correctly
> stated below.
> 
> Errata 2660 was verified a while ago and the RFC editor actually added the
> respective update tags for that RFC. So we could do the same for RFC2460
and
> RFC2473 (meaning that if ?Held for update? was not correct for this one, I
can
> request the RFC editor to revert it). However, I would like to get further
input
> from the group if that is the correct thing to do.
> 
> Mirja
> 
> 
> 
> > On 4. Mar 2020, at 18:42, Bob Briscoe <[email-masked]> wrote:
> >
> > Mirja,
> >
> > I don't even remember writing this Erratum, it's so old (or maybe it's
me that's
> so old - don't comment on that tho).
> >
> > The main reason for reporting omissions in the "Updates" header is to
ensure
> that people who are responsible for implementations of updated RFCs know
> that they are meant to watch RFC3168 (and its updates). It would be useful
if the
> tools view showed accepted errata to the Updates header below the "Updated
> by" field (in the grey area at the top of the HTML of a draft).
> >
> > Any chance that this is possible?
> >
> >
> > FYI, according to the 3168 errata list, there are 3 missing refs in the
updates
> header of 3168 now. But they each have a different status:
> >
> > Errata ID: 2660 Status: Verified Add "Updates: 2003"
> > Errata ID: 4997 Status: Reported Add "Updates: 2460"
> > Errata ID: 4754 Status: Held for Document Update Add "Updates: 2473"
> >
> >
> > Bob
> >
> > On 04/03/2020 09:58, RFC Errata System wrote:
> >> The following errata report has been held for document update
> >> for RFC3168, "The Addition of Explicit Congestion Notification (ECN) to
IP".
> >>
> >> --------------------------------------
> >> You may review the report below and at:
> >>
> >> https://www.rfc-editor.org/errata/eid4754
> >>
> >>
> >> --------------------------------------
> >> Status: Held for Document Update
> >> Type: Editorial
> >>
> >> Reported by: Bob Briscoe
> >> <[email-masked]>
> >>
> >> Date Reported: 2016-07-31
> >> Held by: Mirja K?hlewind (IESG)
> >>
> >> Section: Header block
> >>
> >> Original Text
> >> -------------
> >> Updates: 2474, 2401, 2003, 793
> >>
> >>
> >> Corrected Text
> >> --------------
> >> Updates: 2474, 2401, 2003, 2473, 793
> >>
> >> Notes
> >> -----
> >> RFC 3168 updates RFC 2473 but does not indicate this in its header
block.
> >>
> >> Specifically, Section 9 of RFC 3168 defined processing of the ECN field
for
> Encapsulated Packets, which updated section 6.4 of RFC 2473, where the
> creation of the "IPv6 Tunnel Packet Traffic Class" was specified. RFC3168
also
> updated the decapsulation behaviour of the ECN field in an IPv6 tunnel
header,
> which had not been specified in RFC2473.
> >>
> >> Note 1: As well as tagging RFC3168 with this erratum, RFC2473 needs to
be
> tagged (in the RFC index and associated tools outputs) to indicate that it
is
> updated by RFC3168.
> >>
> >> Note 2: Originally, the "Updates:" header of RFC3168 did not contain
"2003",
> which was added as a result of Errata ID 2660.
> >>
> >> Note 3: The first sentence of section 9.1 in RFC3168 should also be
modified
> as follows:
> >> Original text:
> >>    The encapsulation of IP packet headers in tunnels is used in many
> >>    places, including IPsec and IP in IP [RFC2003].
> >> Corrected text:
> >>    The encapsulation of IP packet headers in tunnels is used in many
> >>    places, including IPsec and IP in IP [RFC2003, 2473].
> >> Comment:
> >>    Nowadays RFC2473 would be a normative reference, but RFC3168 pre-
> dated the categorisation of references into normative and informative.
> >>
> >> Note 4: Section 9 of RFC3168 has since been updated by RFC6040.
> Nonetheless, that is already correctly identified in RFC6040.
> >>
> >> This reported errata has be moved to "Held for Document Update". While
the
> reported problem is correct and needs to be addressed, it is not just an
errata
> but a larger oversight at publication time.
> >>
> >> --------------------------------------
> >> RFC3168 (draft-ietf-tsvwg-ecn-04)
> >> --------------------------------------
> >> Title               : The Addition of Explicit Congestion Notification
(ECN) to IP
> >> Publication Date    : September 2001
> >> Author(s)           : K. Ramakrishnan, S. Floyd, D. Black
> >> Category            : PROPOSED STANDARD
> >> Source              : Transport Area Working Group
> >> Area                : Transport
> >> Stream              : IETF
> >> Verifying Party     : IESG
> >>
> >
> > --
> >
> ________________________________________________________________
> > Bob Briscoe
> > http://bobbriscoe.net/
> 
> 
> 
> End of tsvwg Digest, Vol 191, Issue 3
> *************************************

---

From: Jonathan Morton <[email-masked]>
Date: Thu, 5 Mar 2020 12:47:37 +0200

> On 5 Mar, 2020, at 11:42 am, Ingemar Johansson S <ingemar.s.johansson=[email-masked]> wrote:
> 

> people are starving, people have food on the table. 

It's an interesting analogy, though one which may provoke political rants.  Let me put the analogy in context briefly, and then put it aside.

Many economists point to a period some decades ago, before the rise of "trickle down" economics, as an example of good practice - when CEOs tended to earn about 20x as much as their front-line employees.  It's enough of a difference to reward the more skilled and those taking on risks and responsibilities, without actually sucking huge amounts of capital into a black hole where it does no economic good (because the extremely rich can only spend so much).  Today's situation, where a 200x factor is more common than 20x, is clearly suboptimal - and while not too many people are actually *starving* in Western society, there are supposedly rich countries where most people cannot afford life-saving medical care, or to take a few sick days off work (they wouldn't make rent), or to replace a bald tyre.  That's because food is relatively cheap these days, compared to these other necessities.  In places like Sweden, the situation is improved by the progressive taxation of the wealthy, to provide public services and income support for those less fortunate.

In networking, it's difficult to hold up any given traffic as being more deserving of the use of capacity than others.  This is why Fair Queuing, which enforces equality of throughput for capacity-seeking flows, is often held up as an ideal.  The next best thing, in the status quo, is equal congestion window sizes, which lead to throughputs inversely proportional to the baseline RTT when the queue is kept arbitrarily short, and converges towards equality of throughput when the effective RTT is equalised via a longer queue.

Both L4S and SCE potentially disrupt this status quo in their design, for different reasons.  What the Chairs wish to ensure, I think, is that this disruption does not severely reduce the utility of the Internet, either for existing traffic using conventional congestion control, or for the new traffic using high-fidelity congestion control.

In that sense, even if a precise threshold for unfairness cannot be agreed upon, there is clearly a qualitative difference between a system which imposes a 15-fold reduction of available throughput on existing traffic, versus one which accepts a 2-fold reduction of throughput to itself, when deployed in a shared environment without FQ.  I think when shown that way, consensus that one is acceptable but the other is not would be straightforward to achieve.

 - Jonathan Morton

---

From: Greg White <[email-masked]>
Date: Sun, 8 Mar 2020 07:35:20 +0000

On 3/5/20, 3:47 AM, "tsvwg on behalf of Jonathan Morton" <[email-masked] on behalf of [email-masked]> wrote:

[snip]

     - Jonathan Morton

[GW] I hope that there isn't anyone reading this mailing list who believes that the above is an accurate characterization of the debate between L4S and SCE.   To provide some balance to the above, here is (in my opinion) a more accurate characterization.  

The SCE proposal penalizes any sender that adopts it (2-fold reduction in throughput with no improvement in latency) in many cases, and gives a benefit that is nearly on par with the L4S benefit (this is still to be shown, but it is theoretically possible) when FQ is used in the bottleneck.  Based on this, why would a sender ever adopt SCE?  Why would the IETF ever want to consider using this last codepoint for that purpose?

In comparison, L4S provides a benefit to the adopter (better throughput and lower latency) and no significant penalty to others in the majority of cases (including FQ) and only results in the significant penalty to older systems in some (highly?) unlikely cases if RFC3168 fallback is not implemented.

-Greg

---

From: Jonathan Morton <[email-masked]>
Date: Sun, 8 Mar 2020 11:27:16 +0200

> On 8 Mar, 2020, at 9:35 am, Greg White <[email-masked]> wrote:
> 

Funny, I thought single-queue AQMs were supposed to be rare on today's Internet?  Or at least that's what the L4S team has repeatedly claimed in the past.  Now, suddenly, they are a big problem for SCE but somehow still rare and thus insignificant for L4S traffic?  Isn't that strange, when the SCE team are the big advocates for FQ!

What is perhaps less obvious about the CodelAF system is that the 2:1 ratio is mostly independent of the relative RTT of the two flow types, even though the underlying window-based congestion control remains dependent on RTT.  That's because the flows are signalled to independently, and thus have independent control loops, coupled only by the single queue their packets travel through.

The 2:1 ratio is simply the ratio of queue occupancy (and thus relative throughput) needed to balance out the 2:1 ratio in target sojourn time between the CE-marking and SCE-marking portions of the AQM, via the very simple AF weighting scheme we are demonstrating.  I'm sure a more sophisticated weighting scheme, perhaps involving an integrating term, would be able to eliminate this too, but we have decided to prioritise other matters for now.  I think it's on the todo list for Madrid.

Now, as it happens, that is exactly how the TSVWG Chairs have now framed the debate.  Run both types of traffic through a conventional, RFC-3168 compliant, single AQM and evaluate the resulting behaviour.  SCE flows, in that case, will behave like conventional ones and there is no problem.  L4S flows, as far as the currently available codebase are concerned, will squash out any competing conventional traffic - which is a problem.  If your classic-detection code actually works as advertised, then there will be a period at the start of the flow in which you still squash out all conventional traffic, but then you will revert to conventional behaviour.  That's my prediction based on an educated reading of the proposed algorithm.

That is one of the major bases on which the decision about using ECT(1) as an input or an output will be taken.  It is a basis on which SCE has an undeniable advantage.

And there is also the situation of low-cost or high-speed network hardware which requires a simplified implementation of queuing and AQM to meet its other market goals.  I think it's fair to characterise DualQ as being in this category.  SCE has LFQ for low-cost hardware and CodelAF for high-speed hardware.  LFQ clearly achieves the best results here, as it is mathematically equivalent to DRR++, an FQ technique.  CodelAF achieves reasonable results, consistently, with very little complexity, and is capable of further development.

DualQ has so far not proved to be very robust, as Sebastian Moeller is keen to point out; the public implementation fails to integrate the queue protection logic and also fails to avoid (as advertised) giving a major throughput advantage to L4S traffic, at the expense of conventional traffic.  This latter effect is now the subject of one of the workarounds to be added to L4S endpoints, but which we have not yet seen in a testable form (only a demo video).

There are other points to consider, such as the overall robustness of the system and the potential for future innovation, which the workarounds presently being applied to L4S appear to belie in the former case, and close off in the latter by making some algorithms dependent on internal details or configuration of the others.  SCE's design space remains open for further innovation along many dimensions, and is straightforward to implement in its current form with relatively little chance of serious error.  Not bad for one year's work, I think.

I think it is time for L4S to demonstrate and publish a fully integrated solution to all its problems, or just go away and stop wasting everyone's time.  But that's just my opinion.

 - Jonathan Morton

---

From: Sebastian Moeller <[email-masked]>
Date: Sun, 8 Mar 2020 12:53:34 +0100

Hi Greg,

I find your description to be slightly off as well...

more below in-line

> On Mar 8, 2020, at 08:35, Greg White <[email-masked]> wrote:
> 

	[SM] Because from the IETF's perspective, the important issue should to be how to reliably, robustly and safely enable 1/p congestion control over the wider internet. IMHO that is where tsvw comes in, the claimed (and hyped up*) latency improvements that L4S promises seem more a commercially relevant questions.
	IMHO SCE offers a relative clean, backward-compatible and hence safe way to deploy 1/p-type congestion control that leaves basically all doors open for future improvements, for example in latency-under-load increase. Put differently SCE sets out to tackle one specific important thorny problem and solves it in a clean and minimally invasive way with minimal side-effects, and hence should be considered by the IETF.

*) Hyped-up, because the state of the art today are ~5-10ms latency-under-load increase not 100s of millisecond, sure 1 < 5, but I fail to see any use-case that both will qualitatively suffer significantly by going from 1ms to 5ms additional queueing delay, that is a reasonable to use the wider bet-effort internet as transport medium. THat is not to say that going from 5 to 1 would ne be a good thing, but lest keep benefits and associated costs in a realistic perspective here.

> In comparison, L4S provides a benefit to the adopter (better throughput and lower latency) and no significant penalty to others in the majority of cases (including FQ) and only results in the signi…

	[SM] Today, in all realistic current conditions, no ECN-based AQM, both will behave exactly identical, so in other words there is exactly ZERO benefit for the adopter of any of the two ECT(1) definitions. Both proposals, as I was able to get Koen to commit to, aim for per-flow fairness* even though Bob explicitly disagrees**, and both can signal 1/p-type CC response. So far so similar. The biggest difference I can see, is that L4S with its flawed dualQ AQM has a somewhat working implementation of a method how to translate 1/p type responses into lower queueing latency, while SCE currently does not. But dualQ could easily modified to a) use DSCPs for queue separation and b) to use SCE-type signaling for the LL-queue. 
Low-latency queueing and 1/p-type congestion signaling really are two orthogonal issues, that best are tackled independently. L4S demonstrates that coupling them is not the best idea by such questionable engineering like the TCP Pragues hack to work around the dual queue coupled AQM's poor  sharing behaviour at low RTTs. Mind you, that hack is not to account for some undesirable property of code/gear already widely deployed and used in the field, but rather to two components that still have not left really the lab. (Not only that, but the 15ms hack has not landed in the official TCP Prague repository at https://github.com/L4STeam/linux, and according to Koen is not intended to make it into TCP Prague at least in the current form).

Best Regards
	Sebastian

*) Even though it starts to look, that the only robust guarantee that L4S is willing to give is one of "non-starvation" while at the same time aiming to make it appear as if it was delivering equitable sharing between flows of 1/p and 1/sqrt(p). 
	And yes, under sufficiently narrow conditions L4S can deliver roughly equitable sharing, but alas, it fails to do so for the shorter and shorter content-to-end-users paths that get more and more common; the shorter the path the more it gives L4S flows an undeserved and unexpected advantage. 
	This would all be less irritating if equitable sharing between flows would be a pie-in-the-sky objective that nobody ever had achieved. But given the real world existence and deployment of bi-directional FQ-AQMs that pretty much solve the biggest part of the L4S agenda (getting latency under-load-increase down from >= 100ms into the single digit millisecond range) it seems like a waste of engineering resources by the L4S team to having worked hard to re-invent the wheel (pseudo FQ without the guarantees that make FQ a decent "good enough" solution in the first place) instead of adding their good ideas, like getting 1/p congestion control in the field and potentially using paced chirping to help improving the "slow start phase". Sure everybody can decide where to spend her/his time 

**) At the end of https://mailarchive.ietf.org/arch/msg/tsvwg/1kVZWJRm0TBqDYC4wLN00zS3viQ/ Bob wrote
"The main reason the early L4S proponents sunk years into developing the dualQ coupled AQM was to provide a way to do low latency without FQ."

@L4S team, please get your messaging straight, what is it "aiming for equitable sharing between all flows" aka FQ or "low latency without FQ", both seem mutually exclusive.

	By now, I am prone to believe Bob's narrative over Koen's, as it is way more consistent with a number of otherwise hard to explain design decisions that disadvantage non-LL traffic for the benefit of LL-traffic, like the 15ms latency reference target for the non-LL-queue's PIE instance.