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

Sebastian Moeller <moeller0@gmx.de> Fri, 31 July 2020 10:11 UTC

Return-Path: <moeller0@gmx.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0543A120B for <tsvwg@ietfa.amsl.com>; Fri, 31 Jul 2020 03:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUoGsMIC8KED for <tsvwg@ietfa.amsl.com>; Fri, 31 Jul 2020 03:11:08 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E23B83A120A for <tsvwg@ietf.org>; Fri, 31 Jul 2020 03:11:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1596190261; bh=cJd3OkkmcHWogk9jPKMhAX2FQ6/98xK+zgQilu6d0gs=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=E+KrQFBiKk1FIzjT+PK4neqpbe4jrwHKT19wFDCINOY+PecnGMOUeJ3VqvzRNbBLR oE5sblXJhJGyFRH4MD+qUG7m0VNC9pDHNGHrkX2A40zC2PrgMVnB+Npd3ee1AlEhdQ /q7h9PX/jomPpVNq3oNhU+dsbIbeQ0arpa/1Dql0=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.250.102] ([134.76.241.253]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N9dwd-1koRk00WMX-015WDY; Fri, 31 Jul 2020 12:11:01 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <EDC0072E-EE8F-4734-80AA-9C09867C4661@cablelabs.com>
Date: Fri, 31 Jul 2020 12:10:59 +0200
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B53646AB-D92F-4BF0-ABF9-991884A084DA@gmx.de>
References: <159610640877.23292.15712739866659063100@ietfa.amsl.com> <EDC0072E-EE8F-4734-80AA-9C09867C4661@cablelabs.com>
To: Greg White <g.white@CableLabs.com>
X-Mailer: Apple Mail (2.3445.104.15)
X-Provags-ID: V03:K1:u788gA9+W8rGzu8nNrIC5IOs6i2mprJITZzzqypmrgNkVEOhhxv 6fKlVZp5NwKd9LCHQ9aP9idBd4Y3hnjCO01b4+CLeWJvp19i06AfAxkri6ZKBA7KYXVBOUN rBrmEE4ycmnsFgvCQMjh8+gsCcybfIgYR3L5sQrrH5MAj/rafMbbT8lAUzQBrfXK6Fh19gz Uv2Mnvxi/y1eME2qsBruw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:gxxHxxrd2JE=:N2SNRXRVNaOtpbSnLfJ+T6 t6nzDO9wVNQebk8LIvJOZStsKFvX5smeGzCS10Bln0t4GbDZi6apSlzbYfMYLNVck80uBfOtM /K/gK1ZQEBZAn/WN8+7/FyZ1CKAoylHptiQZ3t0CZ65yKxHonBPNObbDa7cFdk3NmBYYsBapg ke2Gb/Ib6RtuVO2bRJczmTAkq8xvsBSy37M01waasagfyDVmKYjA+QEpJWNmk7lE+LsmOyVjL X94uPaEOgv4+Evzn358mpeLgYMJfJ2qh9jO9durlM5fKdrF/hRulMmuPtEQ6WLuhkq7RyquNR xxew7wrnA9ybYu6yogohXXdf23NzT+QnoWlhjcxqzrwkrrkPizf1WLpFRJxud06kJsw8oilyR b9LwGdfUzMqYm094V6FStbwcv2HZcn8iwn1JQyozcCAS1b0/XtOauu8D2JMdpQd783Fr+nMRo U8VIfXd+sp5j4IeYLvS5wxTjoSIgumbheuZ3D1mC8sNQiTfwXL7Q/WQZy04m0JQWpHtMNhO7J o/s+Nb1ODlIQhgUv3pRC/QaccAKpUMcYTYlZW11tu2p5zy6wgdXzeujpbbdsPv5yT9hReMqCE X5kehPRpf8VrLbvNx8PIfvXD//kroAag3NGffY0Xxi0Vyp/XhcwWSP0GgKQpRRYpuL9gzU/+l KaAzTUV5sBEMmCdFhXa39I6KPpVj5W5ileHBlayMPpMwiWsQfPBqsgUaAOAohlDJfTGiZRB9X Y6N19JT7WckTZ6FE9O6ZllsAmKynSUzmoGpxpb2m3sPdXiH1VbMfOiP33E64v2cTWy/aT2O49 dNP0fGIg6q++1JUffxbSDX/X1lmILcx4DlNwkRh0Nxb/kV1hx0OkwMvpq2V0xu2SBryFTStwi MSC7uveqXo2qmDA77JwLxR0wxJCbLeiO6KEYDNrjr0d4Tr/Qb4SgIWeJXQX0u1SmqTIEq/lZm zFKcB9NZTBtlsO7fQo+ZMDcF5lYJBE8TW4sp0+Vn+5cUlGHmGM37j1YqnM/xerm8pxUI0I4eO GPtfhpiAi00ra/b61Dp1yvXwfhVo9L4sXK1Yq64YzcNd3bQl6DryF6HXgjkIgdrpiPuL9kLVn yu94gKMeaMvEsTaqP8kyIyXMALNQhOJW6rVmbT/8NNPlc4MXJeEUxa1cdrfxWQs7unG0UMKgr VEhltSzhc0s/yZOdjxQNKCnhXQ5Wb0biMPpZJLdf4h3dVWjhWO4uXkx8wIRzcSOtDSGp539JF S4LwKzdIKXUo/LKLQ
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ObyeYMEYECpqoPtWiakcK8I22Wc>
Subject: Re: [tsvwg] FW: New Version Notification for draft-white-tsvwg-l4sops-00.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jul 2020 10:11:10 -0000

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?



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

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


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


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


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


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



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


     " *  Could cache result per-dst"

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


   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.


Best Regards
	Sebastian



> On Jul 30, 2020, at 13:05, Greg White <g.white@CableLabs.com> 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: "internet-drafts@ietf.org" <internet-drafts@ietf.org>
> Date: Thursday, July 30, 2020 at 4:53 AM
> To: Greg White <g.white@CableLabs.com>
> 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://www.ietf.org/internet-drafts/draft-white-tsvwg-l4sops-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-white-tsvwg-l4sops/
> Htmlized:       https://tools.ietf.org/html/draft-white-tsvwg-l4sops-00
> Htmlized:       https://datatracker.ietf.org/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
> 
> 
>