Re: [tsvwg] FW: New Version Notification for draft-white-tsvwg-l4sops-00.txt

[Greg White <[e-mail]>]

Responses below.

From: Sebastian Moeller <[e-mail]>
Date: Friday, July 31, 2020 at 4:11 AM
To: Greg White <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [tsvwg] FW: New Version Notification for draft-white-tsvwg-l4sops-00.txt


Hi Greg,



comments for section 3:



"3.  Operator of an L4S host



   Support for L4S involves both endpoints: ECT1 marking & L4S-

   compatible congestion control on the sender, and ECN feedback on the

   receiver.  Between these two entities, it is incumbent upon the

   sender to evaluate the potential for unfairness and make decisions

   whether or not to use L4S congestion control.  The receiver is not

   expected to perform any testing or monitoring for unfairness, and is

   also not expected to invoke any active response in the case that

   unfairness occurs."



[SM] Maybe worth noting that the receiver will need to play a role in that it is only information send back from the receiver to the sender that will allow the sender to make appropriate decisions. In other words the reciever is still passively involved, which is compatible with your text, but maybe make this explicit?



[GW]  I don’t object, but to me it already seems explicit in the first sentence, which includes “… and ECN feedback on the receiver”.   If you think more is needed, would you mind making a suggestion of what wording would make this clear?





"3.1.  CDN Servers



   Some hosts (such as CDN leaf nodes and servers internal to an ISP)

   are deployed in environments in which they serve content to a

   constrained set of networks or clients.  The operator of such hosts

   may be able to determine whether there is the possibility of RFC3168

   FIFO bottlenecks being present, and utilize this information to make

   decisions on selectively deploying L4S."





[SM] Mmmh, in reality the ISP needs full control over all the end-hosts in that set, otherwise we are back at the concern that an ISP might make unfortunate choices for the connected machines in its customers leaf networks, no?



[GW] If an ISP is known to have implemented single-queue RFC3168 ECN bottlenecks, a server deployed to serve that network probably should not attempt L4S until those bottlenecks are upgraded. In this case it is irrelevant whether end users have also implemented RFC3168 FIFOs.





   "o  Prior to deploying L4S on servers:



      *  Consult with network operators on presence of RFC3168 FIFO

         bottlenecks"



[SM] As above, these bottlenecks can be actually located at end-hosts, so it might be required to check with all operators of networks and end-hosts. That said, checking with the network operators should be done, independent of the fact that it will not give a full picture, since a positive answer from net ops will already have consequences.



[GW] Agreed.  I will add some text to provide some more detail here.





     " *  Perform downstream tests per access network



         +  Tests (TBD) to detect absence of RFC 3168"



[SM] That will require perpetual vigilance though, as it is simply hard to prove a negative, as an AQM might be instantiated not only on intermediary network hops but also on end-systems.





[GW] This bullet will need more text, that is for sure.  After a period of pre-launch testing, a CDN node could potentially move to using in-band detection mechanisms.  In the end, based on the guidance in this draft, each system operator will need to decide for themselves what level of assurance is appropriate to deploy L4S (or what level of evidence is appropriate to preclude deployment).  I’m also not sure I agree that perpetual vigilance would be needed, since once L4S becomes widely deployed, it may follow that the IETF would deprecate RFC3168.   Absent that, any new deployment of single-queue RFC3168 would likely be accompanied by some level of validation by the operator of that bottleneck that their newly enabled feature is providing a benefit and not the opposite.





         "+  Enable AccECN feedback, but enable/disable L4S per access

            network"



[SM] Sounds like decent way to try to asses whether L4S capable endpoints might exist in those networks. ASSUMING that all L4S transports will use AccECN, which I am just not certain of. I think we heard rumblings from Google employees that envision using DCTCP style ECN marking without using TCP-Prague and/or witout following all the principles declared required for using L4S style signaling.



[GW]  It is always possible that an end system or a middle box will implement something that doesn’t comply with RFCs.  I’m not sure there is a lot that can be done about that possibility (particularly in an RFC).



   "o  In-band RFC3168 detection and monitoring:



      *  Real-time response (fallback)



[SM] This is again having all the issues of being an imprecise heuristic... which is worth noting in some part of this document, no?



[GW] Yes, I agree.  I would appreciate contributions of text from those who have been working on those algorithms (including references to material that characterizes the imprecision).



      "*  Non-real-time response (disable for future connections)"



[SM] Mmmh, how realistic is it to assume that an operator will be willing to maintain that much state?



[GW] I definitely think this is realistic enough (at least in some contexts) to include in the guidance document.  Think about this in combination with some of the other approaches above. If a CDN node is deployed in a network in which all of the known single-queue bottlenecks are free of RFC3168, and pre-launch testing has not detected any unknown ones, then an in-band detection mechanism would not be expected to return very many hits.  In that case, it wouldn’t be too much state to build a black-list of end system IPs where a hit occurred.





"3.2.  Other hosts



   o  In-band RFC3168 detection (and possibly fallback)



   o  Per-dst path test:



      *  For a connection capable of L4S feedback



      *  If CE feedback, perform active test (TBD) for RFC3168 presence"



[SM] Remind me again, have we actually seen numbers for that active tests yet, especially regarding convergence time and false positive and false negative rates?



[GW] I don’t think I’ve seen any yet.



     " *  Could cache result per-dst"



[SM] This again will be quite a lot of state, no?



[GW] Not a lot of state per destination, and thus could fairly easily be used for subsequent connections assuming that the prevalence of RFC3168 is low.  I guess the question is how to manage this if it is found that the prevalence of RFC3168 is higher than it is currently believed to be.  For example, if RFC3168 is found to be prevalent in a certain subnet, mechanisms could be devised to generate a lower complexity rule for that subnet rather than per-dst entries in a cache.



   o  Query a TBD public whitelist of domains that are participating in

      L4S experiment"



[SM] +1; I very much hope that the initial experiment will be performed with an explicit allow list, that will also ALLOW end users to register/unregister explicitly.



[GW] While I included this suggestion in the initial draft, I don’t think an explicit allow list is realistic and would only serve to create an unnecessary roadblock to deployment.  Knowledge of a participating domain doesn’t imply lack of RFC3168 FIFOs on the path to that domain (or, as you’ve mentioned, in an end-user network).





Best Regards

  Sebastian







> On Jul 30, 2020, at 13:05, Greg White  wrote:

>

> TSVWG members-

>

> I've posted a rough draft of Operational Guidance for L4S deployment.  This is not much more than an outline at this point, and is almost certainly incomplete even at that, so please read it with that in mind.

>

> -Greg

>

>

> From: "[e-mail]"

> Date: Thursday, July 30, 2020 at 4:53 AM

> To: Greg White

> Subject: New Version Notification for draft-white-tsvwg-l4sops-00.txt

>

> A new version of I-D, draft-white-tsvwg-l4sops-00.txt

> has been successfully submitted by Greg White and posted to the

> IETF repository.

>

> Name:          draft-white-tsvwg-l4sops

> Revision:      00

> Title:         Operational Guidance for Deployment of L4S in the Internet

> Document date: 2020-07-30

> Group:         Individual Submission

> Pages:         7

> URL:            https://protection.greathorn.com/services/v2/lookupUrl/f7c346c8-8443-44e5-b71e-435217709fda/327/00c0c12b60d0de99234622c38cfe321b95178998?domain=www.ietf.org&path=/internet-drafts/draft-white-tsvwg-l4sops-00.txt

> Status:         https://protection.greathorn.com/services/v2/lookupUrl/e5e7af28-9419-4d0e-a559-650861096bf9/327/00c0c12b60d0de99234622c38cfe321b95178998?domain=datatracker.ietf.org&path=/doc/draft-white-tsvwg-l4sops/

> Htmlized:       https://protection.greathorn.com/services/v2/lookupUrl/3b91a498-7692-49a5-aeb2-601ef0ba245a/327/00c0c12b60d0de99234622c38cfe321b95178998?domain=tools.ietf.org&path=/html/draft-white-tsvwg-l4sops-00

> Htmlized:       https://protection.greathorn.com/services/v2/lookupUrl/813cf103-4e26-44a1-8c2f-a2648d5dacc0/327/00c0c12b60d0de99234622c38cfe321b95178998?domain=datatracker.ietf.org&path=/doc/html/draft-white-tsvwg-l4sops

>

>

> Abstract:

>   This is an early, work-in-progress draft - a start at getting some of

>   the ideas from the mailing list and email exchanges on paper.

>

>   This draft is intended to provide guidance to operators of end-

>   systems, operators of networks, and researchers in order to ensure

>   reasonable fairness between L4S and Classic flows sharing a single-

>   queue RFC3168 bottleneck link.  This draft identifies opportunites to

>   prevent and/or detect and resolve fairness problems in such networks.

>

>

>

>

> Please note that it may take a couple of minutes from the time of submission

> until the htmlized version and diff are available at tools.ietf.org.

>

> The IETF Secretariat

>

>

>