Re: [tsvwg] L4S and the RACK requirement

"Black, David" <David.Black@dell.com> Wed, 13 February 2019 03:34 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 80FC3130F80 for <tsvwg@ietfa.amsl.com>; Tue, 12 Feb 2019 19:34:39 -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=nKci+iD4; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=NOXXNjIc
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 h7CKKdfcnpX3 for <tsvwg@ietfa.amsl.com>; Tue, 12 Feb 2019 19:34:37 -0800 (PST)
Received: from esa6.dell-outbound.iphmx.com (esa6.dell-outbound.iphmx.com [68.232.149.229]) (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 CEF84129C6A for <tsvwg@ietf.org>; Tue, 12 Feb 2019 19:34:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1550028876; x=1581564876; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2gp99KKAca3RuLoGD7znxlMA8lm34w3ge9uV6QiACMw=; b=nKci+iD4gI7Z2q5no0+W0yaT2S/GqQOmYcVND0eInXVh3gE0K/tyznD0 IsP3KnETRtyITPi87KK2Q4NpNTTxeSdX8npjVtbNUYtydFab41LR82UGP W6EUKM2L12tmiD3ViRZsuwBDQ2rDeXVi4vkZiioi/+inQ0N103NlXVOHE k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EdAADrj2NchyeV50NjGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZYExgSkRgQMnCoN6iHmLEYINmCeBKzwLAQElCYQ+AheDLyI?= =?us-ascii?q?4EgEDAQECAQECAQECEAEBAQoLCQgpIwyCOiIcTS8JMwEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBARcCQwESAhgBAQEDARIREQwfCBIBBAcEAgEIEQQBAQECAgYdAwICAjA?= =?us-ascii?q?UAQgIAgQBEggagwIBgXkIAQ6dWD0CbYEBiQcBAQFvgS+Cf4EwAQMCAoVvAwW?= =?us-ascii?q?BC4ocgRyBWD6BEUaCTIMeAQEDgSsBEgEhgwcxgiajIQMEAgKHNoNsh0WSYIo?= =?us-ascii?q?zhT+MIwIEAgQFAhSBXYEHcXCDPII2g1SFFIU/QTGNZ4EfgR8BAQ?=
X-IPAS-Result: =?us-ascii?q?A2EdAADrj2NchyeV50NjGgEBAQEBAgEBAQEHAgEBAQGBZ?= =?us-ascii?q?YExgSkRgQMnCoN6iHmLEYINmCeBKzwLAQElCYQ+AheDLyI4EgEDAQECAQECA?= =?us-ascii?q?QECEAEBAQoLCQgpIwyCOiIcTS8JMwEBAQEBAQEBAQEBAQEBAQEBARcCQwESA?= =?us-ascii?q?hgBAQEDARIREQwfCBIBBAcEAgEIEQQBAQECAgYdAwICAjAUAQgIAgQBEggag?= =?us-ascii?q?wIBgXkIAQ6dWD0CbYEBiQcBAQFvgS+Cf4EwAQMCAoVvAwWBC4ocgRyBWD6BE?= =?us-ascii?q?UaCTIMeAQEDgSsBEgEhgwcxgiajIQMEAgKHNoNsh0WSYIozhT+MIwIEAgQFA?= =?us-ascii?q?hSBXYEHcXCDPII2g1SFFIU/QTGNZ4EfgR8BAQ?=
Received: from mx0a-00154901.pphosted.com ([67.231.149.39]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/AES256-SHA256; 12 Feb 2019 21:34:34 -0600
Received: from pps.filterd (m0142693.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1D3RcAw097976 for <tsvwg@ietf.org>; Tue, 12 Feb 2019 22:34:34 -0500
Received: from esa1.dell-outbound2.iphmx.com (esa1.dell-outbound2.iphmx.com [68.232.153.201]) by mx0a-00154901.pphosted.com with ESMTP id 2qmau285du-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <tsvwg@ietf.org>; Tue, 12 Feb 2019 22:34:34 -0500
From: "Black, David" <David.Black@dell.com>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>, "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; 13 Feb 2019 09:34:33 +0600
Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x1D3YUFe019938 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Feb 2019 22:34:32 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com x1D3YUFe019938
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1550028872; bh=GkA7dBeDL6NtNhVTfzJ9OeN418M=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=NOXXNjIccNb+pgQb4+2PmDbfEsbsgSR1v4vOzQZYMG3RDIIwwHSt8euO8zAUmt/R/ 6dqIO0nwF4aIL84e6MokQ+dd8xjmYaobPR7hYzZgdjNmlGgklqJ4sUR5XtXaKUGaN5 8GGU+ad3q+c6Jb5Qk9LE2qERuAHZS5GBgDCejj/c=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com x1D3YUFe019938
Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd56.lss.emc.com (RSA Interceptor); Tue, 12 Feb 2019 22:34:16 -0500
Received: from MXHUB315.corp.emc.com (MXHUB315.corp.emc.com [10.146.3.93]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x1D3YGtG018471 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 12 Feb 2019 22:34:16 -0500
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB315.corp.emc.com ([10.146.3.93]) with mapi id 14.03.0399.000; Tue, 12 Feb 2019 22:34:15 -0500
To: Yuchung Cheng <ycheng=40google.com@dmarc.ietf.org>, Wesley Eddy <wes@mti-systems.com>
Thread-Topic: [tsvwg] L4S and the RACK requirement
Thread-Index: AQHUwv0HdgsuFR8vfki9gnhRmOZbCaXdM5UA///eOIA=
Date: Wed, 13 Feb 2019 03:34:15 +0000
Message-ID: <CE03DB3D7B45C245BCA0D2432779493630439583@MX307CL04.corp.emc.com>
References: <fb6d2979-a6a4-b122-a90e-4a0732ee89fa@mti-systems.com> <CAK6E8=chZjxNd6RFx-dfPU1jbbjmsW0DcDeGSTpLkWo3f=9k2Q@mail.gmail.com>
In-Reply-To: <CAK6E8=chZjxNd6RFx-dfPU1jbbjmsW0DcDeGSTpLkWo3f=9k2Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.252.38.169]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-13_02:, , 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-1902130022
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/gWdh0aA71Elb5ANaiLdU1nMfJ7g>
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: Wed, 13 Feb 2019 03:34:39 -0000

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