Re: [tsvwg] MUST detect problems with legacy queue [was: Re: start of WGLC on L4S drafts]

[Mirja Kuehlewind <[e-mail]>]

Hi Bob,

From Jake's initial review, I believe this is what we are talking about:

>>         o  In uncontrolled environments, monitoring MUST be
>> implemented to
>>            support detection of problems with an ECN-capable AQM at
>> the path
>>            bottleneck that appears not to support L4S and might be in a
>>            shared queue.  Such monitoring SHOULD be applied to live
>> traffic
>>            that is using Scalable congestion control. Alternatively,
>>            monitoring need not be applied to live traffic, if
>> monitoring has
>>            been arranged to cover the paths that live traffic takes
>> through
>>            uncontrolled environments.
>>
>>      The current text requires monitoring, but only gives a single
>> SHOULD for
>>      live traffic, plus non-normatively permits one alternative. 
>> This allows
>>      operators to monitor but not cut off (so this requirement as
>> currently
>>      written would be satisfied by write-only logging for instance,
>> with the
>>      SHOULD easily dismissable with an "implementation complexity"
>> hand-wave
>>      while still following the spec).

I'm saying I don't see any need for a chance. If you read the whole part in the draft, there are a couple of MUST here, which is fine but probably doesn't necessarily help in practice. It just says what you must do when you detect a problem. So, as you say below this is conditioned on problems being detected and you can't have a MUST requirement on detecting all problems anyway...

Mirja


On 09.11.21, 16:25, "Bob Briscoe" <[e-mail]> wrote:

    [Adding to my previous post]


    On 09/11/2021 15:04, Bob Briscoe wrote:
    > Mirja,
    >
    > On 09/11/2021 12:52, Mirja Kuehlewind wrote:
    >> Hi Jake, hi Bob,
    >>
    >> On this specific point I would like to disagree. I don't think it is 
    >> possible at all to have a MUST requirement here. Congestion control 
    >> is a sender-side only implementation and any single endpoint can 
    >> decide to just use non-friendly congestion control anytime with any 
    >> marking and any AQM; maybe even for good reason in some cases. If you 
    >> e.g. look at section 3.1 in RFC8085 you won't find a MUST there for 
    >> good reasons. Requiring a MUST here without clear instructions what 
    >> exactly do to and when is similarly not useful.
    >
    > [BB] To be clear, I think you're saying you disagree with the MUST in 
    > the draft, and the MUST Jake is proposing in its place.
    > If so, this isn't a particularly constructive intervention. Is there 
    > something you'd prefer instead?
    >
    > Speaking for the text in the draft, the final MUST only applies in the 
    > case where scalable CC is already implemented. It is not saying CC 
    > MUST be implemented unless it already has been. Then the MUST comes 
    > into play, but conditioned on problems being detected.

    [BB2] Also note that the whole list of bullets are conditions for 
    setting ECT(1), so this is not for 'any marking'.

    >
    > Finally, it refers to Appx A.1.5 and l4sops which give a lot of 
    > examples of alternative things that can be done. In particular, Appx 
    > A.1.5 gives an offline test that should be able to detect 'problems' 
    > very simply (see table 2 in that appendix).
    >
    >
    > Bob
    >
    >>
    >> Mirja
    >>
    >>
    >> On 08.11.21, 15:54, "tsvwg on behalf of Holland, Jake" 
    >> <[e-mail] on behalf of 
    >> jholland=[e-mail]> wrote:
    >>
    >>      Hi Bob,
    >>
    >>      Thanks for your response. For the most part I'm satisfied, but with
    >>      regard to the responses to points #2 and #3, I'll top-post my 
    >> remaining
    >>      problem and ask that you suggest something appropriate to 
    >> address it.
    >>
    >>      The current text, as far as I can tell, does not *require* any 
    >> attempt
    >>      to detect problems due to "legacy queue" issues (only "SHOULD" 
    >> language
    >>      here, I think?), and then makes the safety response of failing 
    >> over to
    >>      classic CC conditional on "detecting problems".  Certainly if 
    >> there is
    >>      a "MUST" or "SHALL" requirement, it's hard for me to nail down 
    >> exactly
    >>      where.
    >>
    >>      As has been discussed, without some quite complex detection 
    >> efforts,
    >>      detection of problems is a major challenge with this technology, 
    >> and
    >>      thus the current text overall seems too weak to me on this point.
    >>
    >>      IMO, the docs need to make it clear that sending with this 
    >> technology
    >>      comes with a mandatory duty to look for and respond to likely 
    >> problems
    >>      caused to other senders due to the non-backward-compatible 
    >> signaling
    >>      response.
    >>
    >>      Best,
    >>      Jake
    >>
    >>
    >>      From: Bob Briscoe <[e-mail]>
    >>      Date: Sun,2021-11-07 at 8:40 AM
    >>      To: "Holland, Jake" <[e-mail]>, Wesley Eddy 
    >> <[e-mail]>, "[e-mail]" <[e-mail]>
    >>      Subject: Re: [tsvwg] start of WGLC on L4S drafts
    >>
    >>      Jake,
    >>
    >>      Thank you for your new reviews. Pls see [BB] inline...
    >>      On 21/08/2021 21:11, Holland, Jake wrote:
    >>      Overall:
    >>      The documents are in much better shape than the last time I 
    >> reviewed
    >>      them, thanks for all the improvements.
    >>
    >>      I'm reviewing l4s-id and l4s-arch but didn't have time to get to
    >>      dualq-aqm yet.  But I wanted to make sure these got posted, and
    >>      might not have more time before the deadline.
    >>
    >>      ----
    >>
    >>      draft-ietf-tsvwg-ecn-l4s-id-19:
    >>      There's a few major issues.  These really should be fixed before
    >>      sending it to the IESG, IMO, but with these fixed I'd be happy to
    >>      see it shipped.
    >>
    >>      Major:
    >>
    >>      1. This should be proposed standard, not experimental.
    >>
    >>      [snip]
    >>
    >>      [BB] See separate thread.
    >>
    >>
    >>
    >>
    >>      2. This text from Section 4.3 should be strengthened to recommend
    >>      detection of paths that might be classic-marking L4S traffic 
    >> (shared
    >>      queue or not):
    >>
    >>         o  In uncontrolled environments, monitoring MUST be 
    >> implemented to
    >>            support detection of problems with an ECN-capable AQM at 
    >> the path
    >>            bottleneck that appears not to support L4S and might be in a
    >>            shared queue.
    >>
    >>      Even in fq, the standing queue that will be built by a scalable 
    >> cc with
    >>      classic marking is contrary to "1-2ms latency at 99th 
    >> percentile" goal
    >>      of L4S, even leaving aside the harm to colliding flows (though 
    >> of course
    >>      the harm to colliding flows, including from hash collisions in 
    >> fq, is
    >>      also another reason to make this change).
    >>
    >>      [BB] If we make this requirement so that monitoring MUST report 
    >> all Classic ECN AQMs, operators could just have a sea of data that 
    >> doesn't say whether there are any of the single-queue AQMs out there 
    >> - much more likley to be a potential problem than FQ AQMs. The key 
    >> word in this requirement is 'problems'.
    >>
    >>      Also note that the word 'might' in 'might be in a shared queue' 
    >> allows for the case of a flow-queue that is exhibiting problems at 
    >> the time it is monitored (e.g. during real time monitoring when 
    >> within a VPN). BTW, we created a matrix of cases, and checked all the 
    >> possible cases when we wordsmithed this requirement.
    >>
    >>      Also, detecting a flow-queue that is ECN marking but appears to 
    >> exceed expected L4S delay is already in the flow's self-interest. So 
    >> I wouldn't worry about trying to legislate over-precisely about this 
    >> case. For instance, of the two OS developers that I have had detailed 
    >> conversations with about this, both are working on the basis that 
    >> it's worth taking sthg like the max of the responses to increasing 
    >> delay and to ECN marks, which will automatically lead to a 
    >> Classic-like response in an FQ-CoDel queue, as well as in other cases 
    >> like suddenly reduced capacity.
    >>
    >>
    >>
    >>      3. This text from Section 4.3 should be strengthened to require 
    >> that
    >>      sending L4S traffic in uncontrolled environments does not happen 
    >> when
    >>      classic marking of L4S traffic is detected for a shared queue, 
    >> and at
    >>      least recommend that it not happen even for fq:
    >>
    >>         o  In uncontrolled environments, monitoring MUST be 
    >> implemented to
    >>            support detection of problems with an ECN-capable AQM at 
    >> the path
    >>            bottleneck that appears not to support L4S and might be in a
    >>            shared queue.  Such monitoring SHOULD be applied to live 
    >> traffic
    >>            that is using Scalable congestion control. Alternatively,
    >>            monitoring need not be applied to live traffic, if 
    >> monitoring has
    >>            been arranged to cover the paths that live traffic takes 
    >> through
    >>            uncontrolled environments.
    >>
    >>      The current text requires monitoring, but only gives a single 
    >> SHOULD for
    >>      live traffic, plus non-normatively permits one alternative.  
    >> This allows
    >>      operators to monitor but not cut off (so this requirement as 
    >> currently
    >>      written would be satisfied by write-only logging for instance, 
    >> with the
    >>      SHOULD easily dismissable with an "implementation complexity" 
    >> hand-wave
    >>      while still following the spec).
    >>
    >>      Suggested alternative, feel free to edit:
    >>
    >>         o  In uncontrolled environments, L4S traffic MUST NOT be sent 
    >> without
    >>            monitoring to detect marking of L4S traffic by non-L4S 
    >> bottlenecks.
    >>            This monitoring can for example be performed on live 
    >> traffic, or
    >>            can rely on monitoring that covers the paths live traffic 
    >> takes
    >>            through uncontrolled environments.  Where non-L4S 
    >> bottlenecks are
    >>            observed marking L4S traffic, L4S sending MUST be disabled 
    >> if the
    >>            bottleneck is a shared queue, and SHOULD be disabled if it 
    >> is FQ.
    >>
    >>      [BB] Aside: Your middle sentence has (intentionally?) lost the 
    >> 'SHOULD' preference for monitoring live, rather than out of band.
    >>
    >>      I think the next para in the draft (not given in your quote) 
    >> with its mandatory final sentence is stronger than your alternative.
    >>            The detection function SHOULD be capable of making the 
    >> congestion
    >>            control adapt its ECN-marking response to coexist safely with
    >>            Classic congestion controls such as standard Reno 
    >> [https://protect2.fireeye.com/v1/url?k=6db358e7-32286186-6db3187c-86d8a30ca42b-f55753dc038cca88&q=1&e=ece40b18-e6b1-45e4-b56c-a064507e4aaf&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5681__%3B%21%21GjvTz_vk%21Hnqqz6_j8SIdAfFyCkZ-d1cMB2kGbO96HKTk-QSU1VUYsO2YkIK23b-uFrhRnEc%24] 
    >> as
    >>            required by 
    >> [https://protect2.fireeye.com/v1/url?k=0c7104e6-53ea3d87-0c71447d-86d8a30ca42b-16e14b6a81d3b652&q=1&e=ece40b18-e6b1-45e4-b56c-a064507e4aaf&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5033__%3B%21%21GjvTz_vk%21Hnqqz6_j8SIdAfFyCkZ-d1cMB2kGbO96HKTk-QSU1VUYsO2YkIK23b-uqCDg5WI%24] 
    >> Alternatively, if adaptation is not
    >>            implemented and problems with such an AQM are detected, the
    >>            scalable congestion control MUST be replaced by a Classic
    >>            congestion control.
    >>      The differences are:
    >>      * Replacement is a 'MUST' not a 'SHOULD', but conditional on 
    >> 'problems'
    >>      * It doesn't distinguish between shared queue and FQ.
    >>
    >>      We didn't think it was reasonable to give the sender a 
    >> requirement that depends on what type of queue it encounters, because 
    >> the sender doesn't know the type for sure. That's why we made this 
    >> conditional on 'problems' instead. The last sentence of this passage 
    >> from the referenced Appendix A.1.5 explains why:
    >>         CDN servers placed within an access ISP's
    >>         network can be considered as a single controlled environment, 
    >> but any
    >>         onward networks served by the access network, including all the
    >>         attached customer networks, would be unlikely to fall under 
    >> the same
    >>         degree of coordinated control.  Monitoring is expressed as a 
    >> 'MUST'
    >>         for these uncontrolled segments of paths (e.g.  beyond the 
    >> access ISP
    >>         in a home network), because there is a possibility that there 
    >> might
    >>         be a shared queue Classic ECN AQM in that segment. 
    >> Nonetheless, the
    >>         intent is to only require occasional monitoring of these 
    >> uncontrolled
    >>         regions, and not to burden CDN operators if monitoring never 
    >> uncovers
    >>         any potential problems, given it is anyway in the CDN's own 
    >> interests
    >>         not to degrade the service of its own customers.
    >>
    >>      In summary I think your suggestion of conditioning on the type 
    >> of queue is likely to be infeasible and therefore prone to being 
    >> ignored.
    >>      This is not easy but, on balance, I don't think I've seen 
    >> anything here that is tighter than the existing wording.
    >>
    >>
    >>
    >>
    >>
    >>      4. Although l4s-arch claims that l4s-id satisfies the RFC 4774
    >>      requirements, it's hard to tell whether it does so. Specifically:
    >>
    >>      4.a. From section 7 of RFC 4774:
    >>         Specifications of alternate ECN semantics must clearly state 
    >> how they
    >>         address the issues raised in this document, particularly the 
    >> issues
    >>         discussed in Section 2.
    >>
    >>      I don't see how issues 2 and 3 from section 2 are covered in 
    >> l4s-id.
    >>      >From section 4 of RFC 4774:
    >>         (2) How does the possible presence of old routers affect the
    >>             performance of the alternate-ECN connections?
    >>
    >>         (3) How does the possible presence of old routers affect the
    >>             coexistence of the alternate-ECN traffic with competing 
    >> traffic
    >>             on the path?
    >>
    >>         When alternate semantics are defined for the ECN field, it is
    >>         necessary to ensure that there are no problems caused by old 
    >> routers
    >>         along the path that don't understand the alternate ECN 
    >> semantics.
    >>
    >>      4.b. Section 4 goes on to describe 3 options for how alternate ECN
    >>      semantics should be treated.  I don't see a claim in the L4S docs
    >>      specifying which of the 3 options the L4S spec for alternate ECN 
    >> semantics
    >>      matches, but it implicitly appears to be trying to say it's 
    >> option 3
    >>      (unsafe) and asserting that the detection and adaptive response 
    >> satisfies
    >>      the requirement for isolation on option 3, I think?
    >>
    >>      Maybe there are sections in l4s-id that intend to cover these 
    >> points,
    >>      and there just needs to be text listing what they are, but I 
    >> don't think
    >>      the link is obvious enough to satisfy the "clearly state" 
    >> requirement
    >>      from RFC 4774.  So it would be very helpful to add a list of 
    >> references
    >>      to sections that are intended to address these RFC 4774 
    >> requirements.
    >>
    >>      [BB] After guidance from the chairs, the co-authors have been 
    >> working offlist on a fairly lengthy new subsection in ecn-l4s-id 
    >> about where the RFC4774 requirements are and are not satisfied, and 
    >> how that is to be dealt with. Rather than pasting it all here (it's 
    >> long) you should see it later today once the secretariat allow the 
    >> draft through (or otherwise when the servers re-open in the morning). 
    >> And I'm sure the chairs will give everyone time to read it over, and 
    >> review it.
    >>
    >>
    >>
    >>
    >>
    >>
    >>      Nits:
    >>      - the list in section 7.1 has a weird formatting problem for the 
    >> sub-
    >>        list:
    >>
    >>         o  Did use of L4S over the Internet result in improvements to 
    >> the
    >>            following metrics:
    >>
    >>         o
    >>
    >>            *  queue delay (mean and 99th percentile) under various 
    >> loads;
    >>
    >>      [BB] Thx - (had already noticed this one myself as well).
    >>
    >>      Continued...
    >>
    >>
    >>
    >>
    >>      ----
    >>
    >>      draft-ietf-tsvwg-l4s-arch-10:
    >>      Summary: Almost ready
    >>
    >>      +1 to Gorry's comments here, especially regarding the use of 
    >> "all traffic":
    >> https://protect2.fireeye.com/v1/url?k=be40b88e-e1db81ef-be40f815-86d8a30ca42b-dd7f03a662adb7a4&q=1&e=ece40b18-e6b1-45e4-b56c-a064507e4aaf&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftsvwg%2FvMMsQpXs65lk1E7NpV5RlmpyqdI%2F__%3B%21%21GjvTz_vk%21Hnqqz6_j8SIdAfFyCkZ-d1cMB2kGbO96HKTk-QSU1VUYsO2YkIK23b-ul4tJbII%24
    >>
    >>      [BB] Accepted - see response to Gorry/Alex.
    >>
    >>
    >>
    >>
    >>      Minor:
    >>      1. l4s-arch section 1:
    >>         It has been demonstrated that, once access network bit rates 
    >> reach
    >>         levels now common in the developed world, increasing capacity 
    >> offers
    >>         diminishing returns if latency (delay) is not addressed.
    >>      - This needs a reference.
    >>
    >>      [BB] I've added:
    >>        [Dukkipati15]
    >>                    Dukkipati, N. and N. McKeown, "Why Flow-Completion 
    >> Time is
    >>                    the Right Metric for Congestion Control", ACM CCR
    >>                    36(1):59--62, January 2006,
    >> https://protect2.fireeye.com/v1/url?k=fc8ad747-a311ee26-fc8a97dc-86d8a30ca42b-a533c17baf3c8b08&q=1&e=ece40b18-e6b1-45e4-b56c-a064507e4aaf&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdl.acm.org%2Fdoi%2F10.1145%2F1111322.1111336__%3B%21%21GjvTz_vk%21Hnqqz6_j8SIdAfFyCkZ-d1cMB2kGbO96HKTk-QSU1VUYsO2YkIK23b-un5qa5gw%24.
    >>        [Rajiullah15]
    >>                    Rajiullah, M., "Towards a Low Latency Internet:
    >>                    Understanding and Solutions", Masters Thesis; 
    >> Karlstad
    >>                    Uni, Dept of Maths & CS 2015:41, 2015, 
    >> https://protect2.fireeye.com/v1/url?k=101b88f1-4f80b190-101bc86a-86d8a30ca42b-ce03fb0dd8daec7c&q=1&e=ece40b18-e6b1-45e4-b56c-a064507e4aaf&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.diva-portal.org%2Fsmash%2Fget%2Fdiva2%3A846109%2FFULLTEXT01.pdf__%3B%21%21GjvTz_vk%21Hnqqz6_j8SIdAfFyCkZ-d1cMB2kGbO96HKTk-QSU1VUYsO2YkIK23b-ud1apytw%24.
    >>
    >>
    >>
    >>      Editorial:
    >>      1. l4s-arch 4.2 section a:
    >>      - This is a confusing wall of text.  I think it would be better to
    >>        give a much briefer summary here with a reference. Exposition
    >>        like "the obvious part" and "the less obvious part" are a minus
    >>        here--I don't think the obviousness claims made here generalize
    >>        well.
    >>
    >>      [BB] When it only referenced the DualQ draft and only gave a 
    >> short summary, we were asked to summarize more fully how the DualQ 
    >> works here (sigh!).
    >>
    >>      So we've kept the explanation here, but de-confused and 
    >> de-walled it a bit:
    >>      * Removed the 'obvious/non-obvious' wording.
    >>      * Within the largest block: Introduced sub-bullets for the two 
    >> parts of the semi-permeable membrane, each starting "Latency 
    >> isolation:" and "Bandwidth pooling:". Then continued the part about 
    >> the scheduler with 2 further bullets, again starting each with "for 
    >> latency isolation" and "for bandwidth pooling".
    >>      * Cut out some redundancy.
    >>      * I considered shifting out the last para of the DualQ bullet, 
    >> which is about the DualQ document, but I decided there was no better 
    >> place for it.
    >>
    >>      It's not brilliant, but I think it's better.
    >>
    >>
    >>
    >>
    >>      2. All the uses of underlining for emphasis are a minus. The
    >>        places where it seems necessary or useful are a good hint that
    >>        the text on its own is not adequately capturing the intended
    >>        meaning.
    >>        Leaning on this kind of toned emphasis makes assumptions about
    >>        connotations that don't hold very well even for native English
    >>        speakers and break down entirely for non-native speakers, so they
    >>        are generally out of place in a technical document that will need
    >>        to be correctly interpreted by an international audience with 
    >> many
    >>        non-native speakers, IMO.
    >>
    >>      [BB] I agree, use of emphasis is excessive. I've taken out 
    >> /some/ but not /all/ ;)
    >>
    >>      The ones left are:
    >>      * "on /average/" (because the comparison with the other P99 is 3 
    >> lines of dense numbers away)
    >>      * "without the /need/ for per-flow operations" (to help the 
    >> reader not to just run over the word without thinking)
    >>      * "without /requiring/ inspection" (---ditto---)
    >>
    >>      Hopefully, this is now down to a non-irritating level for those 
    >> who don't like it, and now conforms to the guidance from the only 
    >> source I could quickly find on international technical writing style:
    >>      "Do not use italics for
    >>      • mere emphasis. (Italics are acceptable if emphasis might 
    >> otherwise be lost; in general, however, use syntax to provide 
    >> emphasis.)"
    >>      American Psychological Association (APA, 2009, pp. 104-106)
    >>      via 
    >> https://protect2.fireeye.com/v1/url?k=260dfd17-7996c476-260dbd8c-86d8a30ca42b-3095d8d339ccbe6a&q=1&e=ece40b18-e6b1-45e4-b56c-a064507e4aaf&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwriting.stackexchange.com%2Fquestions%2F10750%2Fwhen-should-i-use-italics-in-scientific-writing__%3B%21%21GjvTz_vk%21Hnqqz6_j8SIdAfFyCkZ-d1cMB2kGbO96HKTk-QSU1VUYsO2YkIK23b-uHTBTecE%24
    >>
    >>      (BTW, underscores in ASCII can mean either italics or 
    >> underlining. In the HTML rendering, these words come out in italics - 
    >> which was the intention)
    >>
    >>
    >>
    >>
    >>      ----
    >>
    >>      I'm going to be too pressed for time to do a more detailed review,
    >>      but I wanted to get the above comments in.
    >>
    >>      As a final aside, I'd like to see this happen.  The only goal I'm
    >>      pursuing at this point wrt this work is avoiding preventable harm
    >>      from pushing this out in a way that's likely to cause confusion
    >>      when and if problems are encountered in production.  (In 
    >> particular,
    >>      I have given up on efforts to improve the signaling design, since
    >>      the authors have rejected all such suggestions and this work needs
    >>      to get moved out of the wg one way or another.)
    >>
    >>      [BB] On signalling design, I'd like to point out that it's not 
    >> just the authors - the chairs have judged that the WG wants to go 
    >> this way.
    >>
    >>      Whatever, thank you - for your reviews, and for your continuing 
    >> perseverance and diligence.
    >>
    >>      Cheers
    >>
    >>      Bob
    >>
    >>
    >>
    >>
    >>      Best,
    >>      Jake
    >>
    >>
    >>      On 07-29, 9:18 AM, "Wesley Eddy" mailto:[e-mail] wrote:
    >>
    >>      This message is starting a combined working group last call on 3 
    >> of the
    >>      L4S drafts:
    >>
    >>      - Architecture: 
    >> https://protect2.fireeye.com/v1/url?k=3063a6c7-6ff89fa6-3063e65c-86d8a30ca42b-319e9c6b471639ac&q=1&e=ece40b18-e6b1-45e4-b56c-a064507e4aaf&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tsvwg-l4s-arch%2F__%3B%21%21GjvTz_vk%21Hnqqz6_j8SIdAfFyCkZ-d1cMB2kGbO96HKTk-QSU1VUYsO2YkIK23b-u3NnimRI%24
    >>
    >>      - DualQ:
    >> https://protect2.fireeye.com/v1/url?k=ab12b9ad-f48980cc-ab12f936-86d8a30ca42b-c10cc0b05d165a11&q=1&e=ece40b18-e6b1-45e4-b56c-a064507e4aaf&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tsvwg-aqm-dualq-coupled%2F__%3B%21%21GjvTz_vk%21Hnqqz6_j8SIdAfFyCkZ-d1cMB2kGbO96HKTk-QSU1VUYsO2YkIK23b-uscUhkHw%24
    >>
    >>      - ECN ID: 
    >> https://protect2.fireeye.com/v1/url?k=f903ac8e-a69895ef-f903ec15-86d8a30ca42b-f06e5013138576bf&q=1&e=ece40b18-e6b1-45e4-b56c-a064507e4aaf&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tsvwg-ecn-l4s-id%2F__%3B%21%21GjvTz_vk%21Hnqqz6_j8SIdAfFyCkZ-d1cMB2kGbO96HKTk-QSU1VUYsO2YkIK23b-usmeCGjo%24
    >>
    >>      The WGLC will last through 4 weeks from today, and then we'll 
    >> see what
    >>      to do next.  Please submit any comments you have on these to the 
    >> TSVWG
    >>      list in that timeframe.
    >>
    >>      The chairs are considering a possible virtual interim following the
    >>      close in order to work through feedback received.
    >>
    >>      The work on the L4S operational guidance draft is continuing in
    >>      parallel, but that draft is not being last called yet.
    >>
    >>
    >>
    >>
    >>
    >>      --
    >> ________________________________________________________________
    >>      Bob Briscoe 
    >> https://protect2.fireeye.com/v1/url?k=4a7b07a9-15e03ec8-4a7b4732-86d8a30ca42b-a9e8cb7bfcd026df&q=1&e=ece40b18-e6b1-45e4-b56c-a064507e4aaf&u=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2Fbobbriscoe.net%2F__%3B%21%21GjvTz_vk%21Hnqqz6_j8SIdAfFyCkZ-d1cMB2kGbO96HKTk-QSU1VUYsO2YkIK23b-ucdq-oCs%24
    >>
    >>
    >

    -- 
    ________________________________________________________________
    Bob Briscoe                               https://protect2.fireeye.com/v1/url?k=360a053d-69913c5c-360a45a6-86d8a30ca42b-f145f589d5df5449&q=1&e=569ef2be-2313-4399-a122-b60f8b4253cf&u=http%3A%2F%2Fbobbriscoe.net%2F