IETF Logo Mail Archive

[tcpPrague] Treatment of ECT(1) pre L4S

Dave Dolson <ddolson@sandvine.com> Fri, 22 July 2016 11:01 UTC

Return-Path: <ddolson@sandvine.com>
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E98712DC66 for <tcpprague@ietfa.amsl.com>; Fri, 22 Jul 2016 04:01:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.207
X-Spam-Level:
X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
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 uL2TdspjU7Ez for <tcpprague@ietfa.amsl.com>; Fri, 22 Jul 2016 04:01:10 -0700 (PDT)
Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE0712DB0C for <tcpPrague@ietf.org>; Fri, 22 Jul 2016 04:01:08 -0700 (PDT)
Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.294.0; Fri, 22 Jul 2016 07:01:07 -0400
Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0294.000; Fri, 22 Jul 2016 07:01:07 -0400
From: Dave Dolson <ddolson@sandvine.com>
To: TCP Prague List <tcpPrague@ietf.org>
Thread-Topic: Treatment of ECT(1) pre L4S
Thread-Index: AdHkCFgirgx3HT3iRm+SY64tLECkYQ==
Date: Fri, 22 Jul 2016 11:01:06 +0000
Message-ID: <20160722110102.5697618.36413.99476@sandvine.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794
Content-Type: text/plain; charset="utf-8"
Content-ID: <6B3BE420BFDE294B956B3720A8B750E4@sandvine.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/QqBuF9dR__84rIndwBcmVHVfzKE>
Subject: [tcpPrague] Treatment of ECT(1) pre L4S
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." <tcpprague.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpprague/>
List-Post: <mailto:tcpprague@ietf.org>
List-Help: <mailto:tcpprague-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jul 2016 11:01:12 -0000

If an operator were to deploy ECN today, pre L4S, what should be the treatment of ECT(1)?

I believe, from a discussion with Koen, that the safest approach is for a pre-L4S implementation to signal congestion to ECT(1) by dropping. If ECT(1) were treated the same as ECT(0) then new experimental TCP-Prague flows would out-compete any ECT(0) traffic.

Is this agreed? If so, should it be recommended somewhere?

Note that I got mixed answers on this from other IETF folks, so I think it is worth sorting out.


-Dave

v2.23.0 | Report a Bug | By Email