Re: [tsvwg] L4S and the RACK requirement

Yuchung Cheng <ycheng@google.com> Fri, 22 February 2019 18:16 UTC

Return-Path: <ycheng@google.com>
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 54BB512F1AC for <tsvwg@ietfa.amsl.com>; Fri, 22 Feb 2019 10:16:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.502
X-Spam-Level:
X-Spam-Status: No, score=-17.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 HCA3rrgt5Akv for <tsvwg@ietfa.amsl.com>; Fri, 22 Feb 2019 10:16:18 -0800 (PST)
Received: from mail-it1-x141.google.com (mail-it1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792F9130F3E for <tsvwg@ietf.org>; Fri, 22 Feb 2019 10:16:17 -0800 (PST)
Received: by mail-it1-x141.google.com with SMTP id w18so2961881itj.4 for <tsvwg@ietf.org>; Fri, 22 Feb 2019 10:16:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Enp+ORr6j3NVOp4pT1/CJoWx7lncF0qFw16taqsrdrM=; b=kZnX6+pE37gf/wuSDCUz7p5ePHp8rQge6GStZKnwBbvH7sPuXFQL4atnm0XtTlrhHT ZvDhFrnpHGz7dJlZ79UxbyhawRe03Ot83gBZIPiH2z7u6ntzT8oBBzpcRqOnO+iHnmsx YfOV0lhDqOOtqb1YF0zjWPqFa5etpVmOTgUOJcOvafbvcgZ1jc79nV8Apk0rNdm75fV9 04A6znFKsutfQ+ezaMnA46ubOyVWOe61hQG4VdEkjxDRqXAiVSrQy+mb2S2HWAhn8oUJ 5OF2nwaxpDqmMDB359CINNQ3/bI5edF4n4PTUtyNcMn9uRBvtWh3U2wa9a5gjMOQxyR4 Sjtg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Enp+ORr6j3NVOp4pT1/CJoWx7lncF0qFw16taqsrdrM=; b=oMmAwIWZrH9UAgUW+wV6bbm/usmeWtAckeUoPYJ88e4Rf96wS+NXu4yi8DARTwosX6 xsddK+u5RcZkzy8ObYky9pNl97mmX32nTo7pp4FQq8IthcTi0FMMs/7m/C9NuSaYtEw9 63VNuou04QhAGYduGJEyBW1Jk/H9VM+488SiW4u8nWK3neEfgRYsPchUP7Rp62E43HhB 8CmOou2BxnvZYqUPVGu0QfPiJTK0yXQWYLqrpgpBBtbyZNKRNA7reybg88pV2DaF12m1 9mo+v30fWLly9r7eHwb+uPler/uKWhnK5k3NJJn0TMNo5h0O4izPiZCiYHI8gIFsx224 L+vQ==
X-Gm-Message-State: AHQUAuaFU/7AKV54fJJdFeG79ZEGavT1UAHwo2aZYoLWpcuPhF7c6VBt 6p6seFfyfgASQf7kDdGaSUMCV9WCus4aTq0L7cOvdQ==
X-Google-Smtp-Source: AHgI3IYzpmpMAFMKD4GcNXuP1ZdNq3Xn7jgkWHsYfhYCeQgwOEzSy+h/dTR2Hc7XUtNoTzFXvO5nrsbnQW5He/wcrtw=
X-Received: by 2002:a02:55c6:: with SMTP id e189mr2783211jab.99.1550859375725; Fri, 22 Feb 2019 10:16:15 -0800 (PST)
MIME-Version: 1.0
References: <fb6d2979-a6a4-b122-a90e-4a0732ee89fa@mti-systems.com> <CAK6E8=chZjxNd6RFx-dfPU1jbbjmsW0DcDeGSTpLkWo3f=9k2Q@mail.gmail.com> <CE03DB3D7B45C245BCA0D2432779493630439583@MX307CL04.corp.emc.com> <CAK6E8=cdDmFmTB8-BjFeHvVL9JeDAW9TJyhaKBJmpZMy4ff-YQ@mail.gmail.com> <CE03DB3D7B45C245BCA0D243277949363043EF3B@MX307CL04.corp.emc.com> <50e27fa2-750b-5602-ceab-c48274c854e0@gmx.at> <fc617ea4-000a-805d-9453-57f0d5c930a3@bobbriscoe.net>
In-Reply-To: <fc617ea4-000a-805d-9453-57f0d5c930a3@bobbriscoe.net>
From: Yuchung Cheng <ycheng@google.com>
Date: Fri, 22 Feb 2019 10:15:38 -0800
Message-ID: <CAK6E8=fLFufEH07x+zFXDkSHPSosC6T5XuMbrsUZ8hta=gW0rg@mail.gmail.com>
To: Bob Briscoe <ietf@bobbriscoe.net>
Cc: "Scheffenegger, Richard" <rs.ietf@gmx.at>, "Black, David" <David.Black@dell.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com>, Neal Cardwell <ncardwell@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/abVbyge3t3f_l8pA9bFTNucQo9Q>
Subject: Re: [tsvwg] L4S and the RACK requirement
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, 22 Feb 2019 18:16:23 -0000

On Thu, Feb 21, 2019 at 2:16 AM Bob Briscoe <ietf@bobbriscoe.net> wrote:
>
> David, Richard, Yuchung, all,
>
> 1/ Let me explain why I would still argue for MUST, even tho it strictly rules out existing DCTCP (cos of its initial use of 3DupACK).
>
> Existing DCTCP does not comply with other requirements in the draft either. The requirements started life as a list of things to change in DCTCP. DCTCP has always been put forward as an interim solution that is sufficiently close to the requirements that it can be used for initial testing / demonstration.
>
> The draft is experimental track. It states how the code of all L4S senders has to behave if you want to get meaningful results from an experiment. For an experimental draft, I would argue against saying "You SHOULD do X", if actually you MUST do X before you can expect to get the results claimed by the draft.
>
> 2/ To coexist safely with other Internet traffic?
>
> Nonetheless, this discussion has helped me see a deeper problem with this list of L4S congestion control requirements. I think this is the root cause of David's concern.
>
> The time-units requirement is about inter-operability with any links that do not maintain strict ordering. It is not about safe co-existence with other traffic. That's true for some of the other requirements too. So I propose that we split up the list into:
>
> those requirements that really are about safe coexistence with other traffic
> those requirements that are about interoperability with other parts of the L4S experiment (where safety is too strong a word)
>
> Then code that does not meet any safety requirement cannot be used safely on the public Internet. Whereas code that doesn't interoperate with the rest of the L4S experiment can still be used on the Internet, it just won't necessarily give meaningful results in an L4S experiment.
>
> For instance "MUST react to packet loss in a way that will coexist safely with a TCP Reno" is a safety requirement. So a DCTCP that does not satisfy this requirement cannot safely be used on the Internet For instance, Windows DCTCP is safe on the public Internet, but current mainline Linux DCTCP is not because there's bug where it intends to fall back to Reno - here's Koen's patch from 2yrs ago.
how so? I believe Linux DCTCP correctly implements
https://tools.ietf.org/html/rfc8257#section-3.5

AFAIK Koen's patch makes DCTCP reduces cwnd by 75% (instead of 50%)
when a loss happens w/o any prior CE marks (in a round trip).

Could you identify which case you're referring to
1) DCTCP RFC has a design issue
2) Linux implementation of DCTCP RFC has a bug


>
>
>
> Additional responses (to Richard) tagged [BB] inline...
>
>
>
> On 15/02/2019 16:20, Scheffenegger, Richard wrote:
>
>
> OTOH, for non-RACK (time-based) stacks, mechanisms like this
> https://tools.ietf.org/html/draft-zimmermann-tcpm-reordering-detection-02
>
> should also adjust to the reordering extent - the current wording of L4S seems to preclude any enhancement along those lines to qualify for use of L4S, even thoug a dynamic measurement of the reordering extent would implicitly have some time component as measured, correct?
>
> [BB] If an approach implicitly uses time, surely that satisfies a requirement to use units of time?
>
>
>
> Also, for the proposed RTT/8, what would be a default starting value for RACK? 1 sec / 8 = 125 ms?
>
> [BB] No, I suggest:
>
> (initial RTT from the 3WHS) / 8
>
> Depending on the implementation, the RTT smoothing algo sometimes bootstraps using prior info as well, such as per-destination cache or TFO cookie.
>
> Cheers
>
>
> Bob
>
>
>
> Best regards,
>   Richard
>
> Am 14.02.2019 um 21:18 schrieb Black, David:
>
> Perhaps Bob can shed more lights on how TCP L4S would break badly w/o
> RACK?
>
>
> Start by looking at the rest of that slide deck:
>
> https://datatracker.ietf.org/meeting/103/materials/slides-103-tcpm-sessa-l4s-rack-00
>
>
> Thanks, --David
>
> -----Original Message-----
> From: Yuchung Cheng [mailto:ycheng@google.com]
> Sent: Thursday, February 14, 2019 2:16 PM
> To: Black, David
> Cc: Wesley Eddy; tsvwg@ietf.org
> Subject: Re: [tsvwg] L4S and the RACK requirement
>
>
> [EXTERNAL EMAIL]
>
> On Tue, Feb 12, 2019 at 7:34 PM Black, David <David.Black@dell.com> wrote:
>
>
> I am missing something: how does DCTCP depend a specific loss
> detection mechanism (e.g. DupACK based, RACK, etc)? DCTCP is only
> mandated to react to packet losses.
>
> Linux DCTCP uses RACK by default. There's no inherent dependency of
> the two either.
>
>
> See slide 8 from Bob's Bangkok presentation to TCPM (and the rest of that
> presentation) - the requirement in the ecn-l4s-id draft is more restrictive
> than RACK as currently implemented - current DCTCP with RACK doesn't
> meet that requirement.
>
> https://datatracker.ietf.org/meeting/103/materials/slides-103-tcpm-sessa-
>
> l4s-rack-00
>
>
> We (TSVWG chairs) are looking for "running code" ... as we're having
>
> difficulty
>
> figuring out how the L4S experiment (the L4S drafts are intended to
>
> become
>
>   experimental RFCs) would be carried out without any transport protocol
>
> code.
> Thanks for the pointer. I too think RACK seems a recommended
> component, not a necessity based on the slides.
>
> Perhaps Bob can shed more lights on how TCP L4S would break badly w/o
> RACK?
>
>
> Thanks, --David
>
> -----Original Message-----
> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Yuchung
>
> Cheng
>
> Sent: Tuesday, February 12, 2019 7:27 PM
> To: Wesley Eddy
> Cc: tsvwg@ietf.org
> Subject: Re: [tsvwg] L4S and the RACK requirement
>
>
> [EXTERNAL EMAIL]
>
> On Tue, Feb 12, 2019 at 10:01 AM Wesley Eddy <wes@mti-systems.com>
> wrote:
>
>
> In discussion among the TSVWG chairs, we are concerned about lack of
> consensus on the requirement currently in L4S ID draft (
> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05 ) regarding
> the need for RACK-like behavior in a transport that uses the L4S queue.
>
> The statement in the draft is:
>
>       A scalable congestion control MUST detect loss by counting in units
> of time, which is scalable, and MUST NOT count in units of packets (as
> in the 3 DupACK rule of traditional TCP), which is not scalable (see
> Appendix A.1.7 for rationale).
>
> By saying this, it seems to rule out DCTCP and some other existing code
> that might be used with L4S (and DCTCP discussed in the draft as an
> example scalable transport, even though it violates this rule (?)).
>
> I am missing something: how does DCTCP depend a specific loss
> detection mechanism (e.g. DupACK based, RACK, etc)? DCTCP is only
> mandated to react to packet losses.
>
> Linux DCTCP uses RACK by default. There's no inherent dependency of
> the two either.
>
> This seems like a bit of a problem for making L4S usable.  I guess maybe
> TCP Prague code fixes this, but isn't as widely available yet?
>
> The discussion in the appendix is good at explaining what I think the
> real goal is here, which is to enable major reduction in latency from
> link-layer (or other underlying transport network) re-ordering buffers.
> We want that in order to meet the low latency goals, which makes total
> sense.
>
> So, my question is whether the "MUST" is really more appropriately
> turned into a "SHOULD" guidance?  Given that we expect reordering to
>
> be
>
> possible (and maybe normal) over hops supporting L4S, then the
> congestion control algorithm SHOULD have mechanisms that allow it to
> perform robustly.  If it doesn't, it only hurts itself, not any other
> traffic, so there seems to be no real reason to say "MUST" (someone
> violating it doesn't break the Internet or cause interop issues, etc).
> As I understand it, this would allow the examples like DCTCP to be
> relevant for use with L4S as well.
>
> Does Bob or anyone else have thoughts on this?
>
>
>
>
>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/