Re: [tcpm] DCTCP and draft-black-tsvwg-ecn-experimentation ?

"Black, David" <David.Black@dell.com> Tue, 06 December 2016 16:40 UTC

Return-Path: <David.Black@dell.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440A6129A28; Tue, 6 Dec 2016 08:40:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level:
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=KHODv/6L; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=nqRB2z1U
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 BgGW6RomCdhE; Tue, 6 Dec 2016 08:40:21 -0800 (PST)
Received: from esa5.dell-outbound.iphmx.com (esa5.dell-outbound.iphmx.com [68.232.153.95]) (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 0964F129A5C; Tue, 6 Dec 2016 08:39:24 -0800 (PST)
DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=VzNTsqtQLTA/99F+cPc100Tmbobf9C5OG6Fgge8aYNtnc/a3d8mvDVvd nEQWt90+yUURJ60p9e/GJ1uxUkoNhyKLAl5os9SRGKxMRCcz/wnDmrNd6 E2v8ArElhLtG4yOvjsj94/wCYnCGxjfdejErcjV4Ujscre1L6K0P7lf2Q Q=;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1481042365; x=1512578365; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sBsNwIEw9aLozrAjqGLTi5Hoys514LFnyDOv7ox1ctA=; b=KHODv/6LKDnCn2lQF0uF8achfI95+YqgfhrudtxjOKEbfqUo0azWFU2U a528fmgdQ4hU9z6lChubJHp+7c+Yv6TzbkS4TsM7l/76j61fJYLFfm3Fw SOWaS06piQxLywa3HfVANzCcJtb+VX+jbBfxDuzgJNhKgHvjENRBS6JDR A=;
Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa5.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Dec 2016 10:39:23 -0600
From: "Black, David" <David.Black@dell.com>
Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Dec 2016 22:39:22 +0600
Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id uB6GdGJk016067 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Dec 2016 11:39:20 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com uB6GdGJk016067
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1481042361; bh=ePygJ55xssuDckrXYIkhFdg26D0=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=nqRB2z1UNt38ihpgV4859wW9oREvB8QoTY20Y41l66EPtrft0HI2wJTsziElRujvJ VKfGtNr7s5DyL2ZxtLzwvu580Hz+KUNa52IPnb9UqkW39wSrQTkMrHLEkUGRwhzN+A 5Sz0uGKd+vPuyCla275d1NCCFE3ARrhIuCmGCy8Y=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com uB6GdGJk016067
Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd53.lss.emc.com (RSA Interceptor); Tue, 6 Dec 2016 11:38:54 -0500
Received: from MXHUB317.corp.emc.com (MXHUB317.corp.emc.com [10.146.3.95]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id uB6Gd2oD004730 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 6 Dec 2016 11:39:03 -0500
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB317.corp.emc.com ([10.146.3.95]) with mapi id 14.03.0266.001; Tue, 6 Dec 2016 11:39:02 -0500
To: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "draft-black-tsvwg-ecn-experimentation@ietf.org" <draft-black-tsvwg-ecn-experimentation@ietf.org>
Thread-Topic: DCTCP and draft-black-tsvwg-ecn-experimentation ?
Thread-Index: AdJO1ioNLUmk0y5KTGaYO1zuvkZf8gBBdCMw
Date: Tue, 06 Dec 2016 16:39:02 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362F7818C2@MX307CL04.corp.emc.com>
References: <f7d9e0c8f47940f490d6e829cf983deb@mail.gmail.com>
In-Reply-To: <f7d9e0c8f47940f490d6e829cf983deb@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.44.140]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com
X-RSA-Classifications: public
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/ZH704wH-VQP4yn4wU7gKBZjy-4A>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, "Black, David" <David.Black@dell.com>
Subject: Re: [tcpm] DCTCP and draft-black-tsvwg-ecn-experimentation ?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Dec 2016 16:40:24 -0000

Hi Karen,

> Why is dctcp, https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-03, not mentioned in this draft ?

Shortage of "copious spare time" :-).

I'm happy add some mention of DCTCP in editing after we determine whether
the WG adopts the ECN Experimentation draft.  The mention could be that DCTCP
is another example of technology where experimentation is enabled (e.g., as the
TCPM DCTCP draft is intended to be Informational, and warns about  problems
in coexisting with conventional TCP congestion control - use of ECT(1) and separate
queues could be interesting).

> Something else entirely then are mechanisms like DCQCN, not specified by
> IETF, but relying generally on ECN markings in UDP transport,
> though not following neither the classical nor the l4s approach.
> Such mechanisms as is, whether they use ECT(0) or ECT(1), remain to be
> treated as aliens (or plainly as not compliant with standards) at this time
> in stage. Correct ?

 I think so.  To put this in other words, if the DCQCN proponents are interested
in an Experimental RFC, the ECN experimentation draft's proposed changes
are likely to help in that endeavor, but for now, they (like DCTCP) have
non-standard ECN usage.

Thanks, --David

> -----Original Message-----
> From: Karen Elisabeth Egede Nielsen [mailto:karen.nielsen@tieto.com]
> Sent: Monday, December 05, 2016 4:01 AM
> To: tsvwg@ietf.org; draft-black-tsvwg-ecn-experimentation@ietf.org; Black,
> David
> Cc: tcpm@ietf.org
> Subject: DCTCP and draft-black-tsvwg-ecn-experimentation ?
> 
> Hi,
> 
> This very likely has been discussed length and I just missed it (Sorry).
> 
> Why is dctcp, https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-03, not
> mentioned in this draft ?
> 
> Even if it does not fall within the 4ls experiments (not sure about the
> answer to this) then it might be useful to add a few lines explaining
> the status of DCTCP in this respect ?
> 
> Something else entirely then are mechanisms like DCQCN, not specified by
> IETF, but relying generally on ECN markings in UDP transport,
> though not following neither the classical nor the l4s approach.
> Such mechanisms as is, whether they use ECT(0) or ECT(1), remain to be
> treated as alians (or plainly as not compliant with standards) at this time
> in stage. Correct ?
> 
> 
> BR, Karen