Re: [tsvwg] Call for comments on the suggested publication timeline for draft-white-tsvwg-l4sops, what to do

[Bob Briscoe <[e-mail]>]

Sebastian,


On 27/03/2022 11:19, Sebastian Moeller wrote:
> Dear list,
>
>
> if we agree that the L4S OPs draft is supposed to be published only well after the main drafts' ratification and L4S deployment, I believe that the main drafts should at least carry appendices describing how initial experiments should be made safe within the existing internet. This can well be caveated with something  like "For the initial experimental deployment the following recommendations are given which can/will be superseded by a planned RFC giving L4S operational guidance" to make sure these recommendations do not appear to be set in stone in all perpetuity.

[BB] Given the plan all along was to publish l4sops later, this is how 
ecn-l4s-id has already been written. Appendix A.1.5 gives an outline of 
all the types of test and details of the simplest off-line test. For 
in-band testing it refers off to the tech report, which is as much as 
l4sops does - so nothing more would be written on that topic.

The main info in l4sops that is not in the appendix of ecn-l4s-id (but 
referred to from it) is:
a) the outline of all the measurement studies trying to get a handle on 
the prevalence of the problem.
b) all the potential techniques for modifying Classic ECN AQMs

Omitting both these was deliberate:
* The measurement studies have been useful, but there have been multiple 
opinions on what they imply
* There have been questions about whether the AQM mod's are feasible on 
existing hardware

So, I appreciate you're trying to help, but in summary, there isn't 
really anything to write into ecn-l4s-id that hasn't already been 
considered.

> Again, I would very much prefer if we would run well-guarded experiments first before RFC'ing the main drafts to gain sufficient operational experience to allow us to give decent guidance (and assure that the safety and functionality assumptions the drafts seem built upon actually hold in reality). That would seem the prudent and inherently safer path forward (and with L4S ideas/drafts being kicking around for almost a decade, adding say two more years for safe internet-scale experiments would not cost all that much in time)

We will gain experience by doing now.
Kicking it around has been offering diminishing returns for about the 
last 12 months. The codepoint needs to be assigned now, so that Internet 
experimentation can commence.

Cheers


Bob

>
> Regards
> 	Sebastian
>
>
>> On Mar 25, 2022, at 10:14, Ingemar Johansson S <ingemar.s.johansson=[e-mail]> wrote:
>>
>> +1
>>
>> I think it makes much sense to wait with he publication for draft-white-tsvwg-l4sops until we have more data from the experiments.
>>
>> /Ingemar
>>
>>> -----Original Message-----
>>> From: tsvwg <[e-mail]> On Behalf Of
>>> [e-mail]
>>> Sent: Thursday, 24 March 2022 15:10
>>> To: [e-mail]
>>> Cc: [e-mail]
>>> Subject: Re: [tsvwg] Call for comments on the suggested publication timeline
>>> for draft-white-tsvwg-l4sops
>>>
>>> Gorry,
>>>
>>> I agree to Bob's proposal to wait with publication until some experimental
>>> experience has been reached.
>>>
>>> Regards,
>>>
>>> Ruediger
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: tsvwg <[e-mail]> Im Auftrag von Bob Briscoe
>>> Gesendet: Donnerstag, 24. März 2022 14:35
>>> An: Gorry Fairhurst <[e-mail]>
>>> Cc: [e-mail]
>>> Betreff: Re: [tsvwg] Call for comments on the suggested publication timeline
>>> for draft-white-tsvwg-l4sops
>>>
>>> Gorry,
>>>
>>> I can see the two sides of this.
>>> * Sebastian's point that publication could improve visibility for network and
>>> server operators is a good one.
>>> * But if I were on the IESG and asked to approve publication of operational
>>> guidance before there was any operational experience, I would be
>>> concerned.
>>>
>>> Similarly, because some of the points in the draft do not have much real
>>> experience to back them up, they might have to be removed in order to get
>>> it approved for publication. For instance, we have been arguing about:
>>> * likely traffic patterns;
>>> * likelihood of shared queue Classic ECN being deployed;
>>> * likelihood of hash collisions
>>> * likelihood that good classic ECN bottleneck detection can be implemented;
>>> * likelihood that network equipment can be configured in certain ways; etc.
>>> etc.
>>> Without some real-world experience on these matters, I'm not sure what
>>> the value of this document as an RFC would be.
>>>
>>> I think Sebastian's point might be slightly reworded to say this draft needs
>>> 'visible status'. Visibility comes from Internet discussion forums, blogs and
>>> articles. Not yet being published as an RFC doesn't really change visibility (e.g.
>>> anyone interested in the implications of QUIC would have read a draft
>>> without waiting for RFC publication).
>>> Rather, publication changes the status of the guidance once it is visible.
>>>
>>> How about this compromise:
>>> * We agree now that this draft is intended to give guidance based on 'early'
>>> or 'initial' operational experience (e.g. 1 year), and aim to publish once there
>>> is some experience, but not wait until experience is exhaustive.
>>> * Where l4sops is cited in ecn-l4s-id (from the requirement on coexistence in
>>> Classic ECN AQMs), we edit to say explicitly that l4sops is being kept open as
>>> a living document for a short while to capture initial operational experience.
>>>
>>> Then, if ecn-l4s-id is published as an RFC, the visible status of the coexistence
>>> issue ought to be no less than if two RFCs are published about it.
>>> And this extra explanation of the draftiness of the citation should make it
>>> more likely that people who need to read l4sops will understand its status
>>> and not dismiss it as "not worth reading yet".
>>>
>>> HTH
>>>
>>>
>>>
>>> Bob
>>>
>>> On 21/03/2022 17:53, Greg White wrote:
>>>> Hi Gorry,
>>>>
>>>> A few points of clarification.
>>>>
>>>> The draft in question is actually https://datatracker.ietf.org/doc/draft-ietf-
>>> tsvwg-l4sops/
>>>> Also, there remains one "ToDo" in the document that I briefly mentioned
>>> today, and for which I'm hoping to get input from the WG.  Aside from that
>>> one item, I'm not aware of any other areas where it is considered
>>> incomplete.
>>>> Is the deadline for responses to your question possibly *April* 8?
>>>>
>>>> -Greg
>>>>
>>>>
>>>>
>>>> On 3/21/22, 8:28 AM, "tsvwg on behalf of Gorry Fairhurst" <tsvwg-
>>> [e-mail] on behalf of [e-mail]> wrote:
>>>>      The presentation in TSVWG on Monday 21st March 2022 indicated that
>>> the
>>>>      authors thought the document was complete and ready for review. The
>>>>      chairs previously indicated that publication could be delayed to wait
>>>>      for initial experience.  The chairs would appreciate feedback, to help
>>>>      decide.
>>>>
>>>>      So, does the WG have a  preference regarding when to publish the L4S
>>> Ops
>>>>      draft:
>>>>
>>>>      (1)  If the work is thought complete, there could be value in having a
>>>>      frozen draft while experience is gained, this could be updated with
>>>>      initial experience, before requesting publication as an RFC.
>>>>
>>>>      (2) The WG would not intentionally delay the request for the IESG to
>>>>      publish: If the work is thought complete, then we can finish this draft
>>>>      and publish in the short-term. The WG retains the option to decide to
>>>>      subsequently publish an updated RFC in the future.
>>>>
>>>>      Please could send an email to tsvwg, or to the tsvwg chairs by 8th March
>>>>      2022.
>>>>
>>>>      Before any publication, the ID will be subject to normal review and WGLC
>>>>      comments.
>>>>
>>>>      Best wishes,
>>>>
>>>>      Gorry Fairhurst
>>>>      (tsvwg co-chair)
>>>>
>>>>
>>> --
>>> __________________________________________________________
>>> ______
>>> Bob Briscoe                               https://protect2.fireeye.com/v1/url?k=31323334-
>>> 501d5122-313273af-454445555731-b0108c2709550a3a&q=1&e=c5e952cd-
>>> dfdb-4fee-babd-2c04232e13cd&u=http%3A%2F%2Fbobbriscoe.net%2F

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/