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

[Sebastian Moeller <[e-mail]>]

 

 

 

Gesendet: Montag, 19. Oktober 2020 um 21:37 Uhr
Von: "Greg White" <[e-mail]>
An: "Sebastian Moeller" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Betreff: Re: [tsvwg] FW: New Version Notification for draft-white-tsvwg-l4sops-00.txt

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?

[SM] Fair enough, that is certainly a fair point, that CN feedback on the receiver covers this.
I guess my bigger issue is that neither sender nor receiver are in a position to actually evaluate fairness. Potential for unfairness is inherent in the current L4S design & implementation, but the endpoints will only be able to assess that at all if they would always also establish non-L4S sentinel flows parallel to the L4S flows which is IMHO completely unrealistic. Unless we are talking about rfc3168 detection here, but that then should be more explicit.

 

 

"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.

 

[SM] That is correct, but not exactly what is understand from the cited text. The "possibility/probability of RFC3168 FIFO bottlenecks being present" if one does not know the state of all nodes is IMHO always greater than zero. But sure english is not my native language so I might simply misunderstand the text.

   "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).  

[SM] In the context of L4S being an targeted as experiment I would appreiciate rather more caution. The IETF, IMHO, should not encourage operators to knowingly violate an inforce standards track RFC for the sake of an experimental track RFC that is not fully vetted/tested, but I digress.


[GW cont.] 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. 

[SM] Fair enough, I was underthe impression, that "L4S becoming widely deployed" is contigent of the L4S experiment actually being successful first. There is still the option of failure (albeit slim, as this WG seems to be oposed to formulate actual criteria to assess the experiment's success/failure). But even if the IETF would agree to sun-set RFC3168 it would still be somewhat unfriendly to simply start ignoring existing deployed instances.

[GW cont.]  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.  

 [SM] That can easily leaf to a situation where L4S is shown to not actually delivery its promises of typical internet conditions, but still seeing enough incondsiderate deployment to hobble existing rfc3168 AQMs. 

         "+  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).  

[SM] Sorry. We are not talking a remote possibility that the L4S draft authors could not have forseen, but a rather something that team L4S seems to actively encourage (I believe I remember that team BBR was encouraged to incorporate L4S style ECN siggnaling, without also enforcing the rest of the TCP Prague requirements). 

   "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). 

 

[SM] +1.

      "*  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.  

 

[SM] At the CDN experts in this group, is that something you already do, endpoint/prefix specific negotiation of per-connection options?

"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.

 

[SM] That makes two of us. @Bob, Koen, any updates on this 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.

 

[SM] See above, is that something that CDNs are already doing, if so, I agree that that seems feasible, but otherwise...

 

 

 

   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. 

[SM] Sorry, if a BLOCK list seems feasible to you, than an ALLOW list certainly will also be acceptabble for the experiment, given that the number od known L4S paths7hosts will be small initially.

[GW cont.] 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). 

[SM] Yes, that is the crux of designing a system that on purpose is not back-ward compatible. But BLOCK and ALLOW lists certainly can be combined. IMHO it is considerably safer to start the experiment only with consciously participating end-nodes, and that opt-in maps well onto an explicit ALLOW list. I really destest the idea of recriuiting end-users into this experiment without their explicit consent.

 

Best Regards

       Sebastian

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" target="_blank" rel="nofollow">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/" target="_blank" rel="nofollow">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" target="_blank" rel="nofollow">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" target="_blank" rel="nofollow">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

> 

> 

>