Re: [tsvwg] L4S and the RACK requirement

"Black, David" <David.Black@dell.com> Thu, 14 February 2019 20:18 UTC

Return-Path: <David.Black@dell.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 3298C12867A for <tsvwg@ietfa.amsl.com>; Thu, 14 Feb 2019 12:18:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=jCO1iwEC; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=iV3CXMLC
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 J1rgLxcRme4Z for <tsvwg@ietfa.amsl.com>; Thu, 14 Feb 2019 12:18:43 -0800 (PST)
Received: from esa1.dell-outbound.iphmx.com (esa1.dell-outbound.iphmx.com [68.232.153.90]) (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 09AA7128D52 for <tsvwg@ietf.org>; Thu, 14 Feb 2019 12:18:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1550175490; x=1581711490; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Rw+JeL0m3UxkB6jsWyHBRtRKod/g+eluwuqXSztqpk8=; b=jCO1iwECM95cwIaWBsLaV3U8Z025IPoj61AtaKIYnkHLPSpIC70bXex0 lxU+m0/iPgaUGgtldrdavQAEpREQoJa1N0BNweSXj6Gwmt2EeyRNF99jN GE/qdE2uMbT0fLLIKJBUQW5drEBodLQCRS4+aiG2ik4YgMzNIiEPvYmcp w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EVAADAzGVchiWd50NkHAEBAQQBAQc?= =?us-ascii?q?EAQGBUwUBAQsBgTCBKBGBAycKg3yIeYsRgg2YExSBKzwLAQElCYQ+AheDTSI?= =?us-ascii?q?2Bw0BAwEBAgEBAgEBAhABAQEKCQsIKSMMgjopARRNLwkzAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBFwJDARICGAEBAQMBEhERDB8IEgEEBwQCAQgOAwQBAQECAgYdAwI?= =?us-ascii?q?CAjAUAQgIAgQOBQgagn4BgWoIAQ6eZz0CbYEBiQcBAQFvgS+Cf4EwAQMCAoV?= =?us-ascii?q?3AwWBC4odgRyBWD6BEUaCTIMeAQEDgSsBEgEhBTOCTzGCJqMwAwQCAoc4g26?= =?us-ascii?q?HRZJzj32MLgIEAgQFAhSBTQJlMHFwgzyCNoJNgQeFFIU/QTGOHoEfgR8BAQ?=
X-IPAS-Result: =?us-ascii?q?A2EVAADAzGVchiWd50NkHAEBAQQBAQcEAQGBUwUBAQsBg?= =?us-ascii?q?TCBKBGBAycKg3yIeYsRgg2YExSBKzwLAQElCYQ+AheDTSI2Bw0BAwEBAgEBA?= =?us-ascii?q?gEBAhABAQEKCQsIKSMMgjopARRNLwkzAQEBAQEBAQEBAQEBAQEBAQEBFwJDA?= =?us-ascii?q?RICGAEBAQMBEhERDB8IEgEEBwQCAQgOAwQBAQECAgYdAwICAjAUAQgIAgQOB?= =?us-ascii?q?Qgagn4BgWoIAQ6eZz0CbYEBiQcBAQFvgS+Cf4EwAQMCAoV3AwWBC4odgRyBW?= =?us-ascii?q?D6BEUaCTIMeAQEDgSsBEgEhBTOCTzGCJqMwAwQCAoc4g26HRZJzj32MLgIEA?= =?us-ascii?q?gQFAhSBTQJlMHFwgzyCNoJNgQeFFIU/QTGOHoEfgR8BAQ?=
Received: from mx0b-00154901.pphosted.com ([67.231.157.37]) by esa1.dell-outbound.iphmx.com with ESMTP/TLS/AES256-SHA256; 14 Feb 2019 14:18:09 -0600
Received: from pps.filterd (m0144104.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1EKCwgM065400 for <tsvwg@ietf.org>; Thu, 14 Feb 2019 15:18:41 -0500
Received: from esa1.dell-outbound2.iphmx.com (esa1.dell-outbound2.iphmx.com [68.232.153.201]) by mx0b-00154901.pphosted.com with ESMTP id 2qnd8b0m7b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <tsvwg@ietf.org>; Thu, 14 Feb 2019 15:18:40 -0500
From: "Black, David" <David.Black@dell.com>
Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa1.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-SHA256; 15 Feb 2019 02:18:39 +0600
Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x1EKIZAp031081 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Feb 2019 15:18:37 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com x1EKIZAp031081
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1550175518; bh=CLZoruQeXNLVQMYumI0sPOa5800=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=iV3CXMLC6e+a9aV0C6WCFLxRFLamGayV8A+ok3/pBA7wMzbgvFNx/ZV8z3aKRXY1g ctpWzE+k77gU7+F1gshdhAAhpqXcizvbvRL0xQEtzPEKOPwLrvAI+ZxxcLQEl4vuLr naDhvcY68Br7ws7lcFK/2NlaWjWJAOA8t7otULjo=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com x1EKIZAp031081
Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd51.lss.emc.com (RSA Interceptor); Thu, 14 Feb 2019 15:18:19 -0500
Received: from MXHUB307.corp.emc.com (MXHUB307.corp.emc.com [10.146.3.33]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x1EKILhS022262 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Thu, 14 Feb 2019 15:18:21 -0500
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB307.corp.emc.com ([10.146.3.33]) with mapi id 14.03.0399.000; Thu, 14 Feb 2019 15:18:21 -0500
To: Yuchung Cheng <ycheng@google.com>
CC: Wesley Eddy <wes@mti-systems.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] L4S and the RACK requirement
Thread-Index: AQHUwv0HdgsuFR8vfki9gnhRmOZbCaXdM5UA///eOICAAu9ygP//vXEQ
Date: Thu, 14 Feb 2019 20:18:20 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949363043EF3B@MX307CL04.corp.emc.com>
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>
In-Reply-To: <CAK6E8=cdDmFmTB8-BjFeHvVL9JeDAW9TJyhaKBJmpZMy4ff-YQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.21.131]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-14_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902140134
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/valhDHOpzyjGvj7Na3mit3Afhys>
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: Thu, 14 Feb 2019 20:18:46 -0000

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