Re: [tsvwg] Switch testing at 25G with ECN --SCE Draft

<Ruediger.Geib@telekom.de> Tue, 13 August 2019 06:33 UTC

Return-Path: <Ruediger.Geib@telekom.de>
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 99F3D12008C for <tsvwg@ietfa.amsl.com>; Mon, 12 Aug 2019 23:33:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
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 yNGOTqgtjgTu for <tsvwg@ietfa.amsl.com>; Mon, 12 Aug 2019 23:33:09 -0700 (PDT)
Received: from mailout21.telekom.de (mailout21.telekom.de [194.25.225.215]) (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 B73E912008A for <tsvwg@ietf.org>; Mon, 12 Aug 2019 23:33:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1565677987; x=1597213987; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TH9JPGMZ02srTEizfnUoFW9UycCL3J3TCJnTqeivw70=; b=x5HB0yxjf014gIpDCKbrczJOV0oLAXblIRqRyxoFuhkjQmvmpzid1usQ FKxWyBabzPmsYGwVF23EoWRmAjLC3IFrGTJca5fjxeFd1KnrAiIm4S4+S VY4hRi1KqWIAV8mjhXki+GWLGAsa2rHLbYRKlqayTvgGv/+YVFtNtzDz5 6b2vWInpqP24PmcjwbMr12s4ZpzVj4EZddiyhRq1DpY+sH9iHqA8SP+RN NRZYzOr3R/2dHIDvBllcT5Ty3LB83E/LXBZCWVX2lEZYC+Gkb846nG4jL rOdNwf4StDUtn8wrHm/c9RGANtAtkb5+eknYOMJmbL+Zm5ltv7y9OsokE A==;
Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Aug 2019 08:33:03 +0200
X-IronPort-AV: E=Sophos;i="5.64,380,1559512800"; d="scan'208";a="600297317"
X-MGA-submission: =?us-ascii?q?MDH3Dc+EhcB3K04KgvpLzK6Iu1c14W4PYYNRuX?= =?us-ascii?q?mJJ/lQsnlAL8MBnw1H2PYwaY9qawOx4WulFArdnAgZGCQlRA6abUtd6r?= =?us-ascii?q?iJGfLDdzq40u2eU4U2d8kq56xiykffJpboOPkLGEx0vi2EVpCfCIYQAd?= =?us-ascii?q?rp8sGtLbeP+TnO/agL8UFbwA=3D=3D?=
Received: from he105711.emea1.cds.t-internal.com ([10.169.118.42]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 13 Aug 2019 08:33:04 +0200
Received: from HE105715.EMEA1.cds.t-internal.com (10.169.118.51) by HE105711.emea1.cds.t-internal.com (10.169.118.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 13 Aug 2019 08:33:04 +0200
Received: from HE104164.emea1.cds.t-internal.com (10.171.40.35) by HE105715.EMEA1.cds.t-internal.com (10.169.118.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 13 Aug 2019 08:33:04 +0200
Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.21) by O365mail06.telekom.de (172.30.0.233) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 13 Aug 2019 08:33:02 +0200
Received: from LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE (10.158.166.7) by LEXPR01MB0782.DEUPRD01.PROD.OUTLOOK.DE (10.158.168.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.20; Tue, 13 Aug 2019 06:33:03 +0000
Received: from LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE ([fe80::2d90:342b:b54e:462b]) by LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE ([fe80::2d90:342b:b54e:462b%6]) with mapi id 15.20.2157.022; Tue, 13 Aug 2019 06:33:03 +0000
From: <Ruediger.Geib@telekom.de>
To: <giuseppe.scaglione@hpe.com>
CC: <tsvwg@ietf.org>
Thread-Topic: [tsvwg] Switch testing at 25G with ECN --SCE Draft
Thread-Index: AQHVTjzVagH3r6fcc06dVlu/ZJB8+abx5uIAgAACfxCAAON5gIAAekXQgAAGzgD//6YAAIAAZZ2w//+fYwCAAGWu8IAFO8yw
Date: Tue, 13 Aug 2019 06:33:03 +0000
Message-ID: <LEXPR01MB046369D19891EBC059958D859CD20@LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE>
References: <A8E3F5E9-443D-4F5A-9336-9A0E2E72C278@cablelabs.com> <201908082333.x78NXS0T094756@gndrsh.dnsmgr.net> <AT5PR8401MB07070C672C9F519C05D2D3F599D60@AT5PR8401MB0707.NAMPRD84.PROD.OUTLOOK.COM> <81354E22-777C-4BDB-96E0-0B1F6C1DCCD2@cablelabs.com> <AT5PR8401MB070700703FBF2318808238CF99D60@AT5PR8401MB0707.NAMPRD84.PROD.OUTLOOK.COM> <C9E9A1C7-59CF-4414-82CE-14ABFE74ADB2@gmail.com> <ADCEE0A5-6A32-4106-8557-029C65B2D4C5@cablelabs.com> <AT5PR8401MB07074B665CF7612FAD66E13899D60@AT5PR8401MB0707.NAMPRD84.PROD.OUTLOOK.COM> <6D40C855-EE12-4148-9EE6-E67DE8ADC715@cablelabs.com> <AT5PR8401MB0707095986FAEB5F212F7B5199D30@AT5PR8401MB0707.NAMPRD84.PROD.OUTLOOK.COM>
In-Reply-To: <AT5PR8401MB0707095986FAEB5F212F7B5199D30@AT5PR8401MB0707.NAMPRD84.PROD.OUTLOOK.COM>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de;
x-originating-ip: [164.19.3.213]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c1e068dd-2ed4-4725-5587-08d71fb81829
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LEXPR01MB0782;
x-ms-traffictypediagnostic: LEXPR01MB0782:
x-microsoft-antispam-prvs: <LEXPR01MB0782B527A54534D6933987189CD20@LEXPR01MB0782.DEUPRD01.PROD.OUTLOOK.DE>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01283822F8
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(39860400002)(346002)(366004)(396003)(199004)(189003)(13464003)(81156014)(2906002)(5660300002)(81166006)(66556008)(66946007)(66446008)(64756008)(66476007)(478600001)(9686003)(55016002)(256004)(76116006)(14444005)(53936002)(8936002)(71190400001)(486006)(71200400001)(6116002)(6916009)(3846002)(7736002)(85202003)(66574012)(33656002)(76176011)(52396003)(296002)(316002)(86362001)(7696005)(305945005)(26005)(85182001)(11346002)(102836004)(66066001)(446003)(4326008)(14454004)(8676002)(186003)(53546011)(476003)(777600001); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB0782; H:LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: UFyuvXr79MpV0ZtAOLGAohAdBBokP5+QLT/EvjKa/9z2MzAWkFV1KODtDrFGmiu/FQy0kIROzM2zXYqXqDTZJ00kLNSIc5YYHDFyZ+1efGc3gFtWszreU5kB7D92kKop7K2NtAEn60stFnPW76PQjs8Fy/QxENbqT0Ox48vszABjXttrJUgmCqw9d7WDakQoa15iAxbjbXvX/7J2+71udLdDOJVDkpe7zsjd+HbYH0TTJLUSofrFfBVG699ucrsFaCBolUaou+nNsRDYRP7CgM7/D+5iYsSIc3JrCuJBsvkdfMdVxHvpKhsPB2YjTfo9sq1TpfxhLQ7JIhU/kBk+WOKVSH2MGNbYCdfF+hyp9o6YeKQtHw+WFuPK6mjujiFDsZuZ//iL1JI4c5PE2JsPGlUd3FuHK18ka/ri5O565mk=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c1e068dd-2ed4-4725-5587-08d71fb81829
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2019 06:33:03.5410 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rjKZsel59p8qoYF3XBO4oKCInzdfgySaUtXh8yv2FDILpNMaTP4IAvMxUmJLp5YG4wbeUW/P8fyVlnVnLxWoQF2z7BmNr4IcI9GSkD9n0fE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB0782
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/flcancTn6E0AOlABNUQvYEThtGY>
Subject: Re: [tsvwg] Switch testing at 25G with ECN --SCE Draft
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: Tue, 13 Aug 2019 06:33:11 -0000

Hi Giuseppe,

you are basically right. In your test, you were working with different set-ups. With one, marking started initially, with another, marking started after a settable queue threshold. Queues could be of different depths. One can imagine drop functions which aren't linear from 0 - 100%. That is to say, there are some variables whose configurations are likely unknown to an endpoint, which impact what is expressed by an x% packet mark of a bottleneck facing a queue build up.

You close with "makes the implementation of TCP more predictable", which I agree to. To me an interesting question is, to which extent the overall mechanism benefits from standardization. A simple standardized marking and queuing behavior resulting in a reliable and fairly good transport management for a range of RTTs and BDPs or queue depths - would be great. At least having an understanding which enhanced AQM functions and ranges of settings of the above variables make sense would be a fair standardization result too.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: tsvwg <tsvwg-bounces@ietf.org> Im Auftrag von Scaglione, Giuseppe
Gesendet: Montag, 12. August 2019 17:29
An: Greg White <g.white@CableLabs.com>om>; Jonathan Morton <chromatix99@gmail.com>
Cc: tsvwg@ietf.org
Betreff: Re: [tsvwg] Switch testing at 25G with ECN --SCE Draft

Hi Greg,

My humble opinion based on the testing presented is that with SCE remarking purely function of the queue depth, the TCP stack has a notion of congestion present in the TCP connection that is independent of the buffering capability of the switch queue. The TCP stack is seeing a "5%" of packet remarked for example, which means somewhere in the network some queue is seeing "some" oversubscription period. 

While with CE RFC3168 you know that remarking typically only starts after a X% of queue depth (user configured). And that X is function of the queue depth and memory available, and if the X is not 'tuned' you either get not optimal link utilization or packet drops. 

Basically, it seems like having an 'early warning' marking makes the SW implementation of the TCP algo easier and more predictable, instead of relying on a switch configuration of X.

Yes -- more testing is required.

Best Regards,
Giuseppe  

-----Original Message-----
From: Greg White [mailto:g.white@CableLabs.com] 
Sent: Friday, August 9, 2019 2:54 PM
To: Scaglione, Giuseppe <giuseppe.scaglione@hpe.com>om>; Jonathan Morton <chromatix99@gmail.com>
Cc: rgrimes@freebsd.org; tsvwg@ietf.org
Subject: Re: [tsvwg] Switch testing at 25G with ECN --SCE Draft

Agreed.  I would not expect any different result either, which begs the question why does SCE need two different signals (ECT(1) and CE) in a datacenter environment?

-Greg



On 8/9/19, 3:43 PM, "Scaglione, Giuseppe" <giuseppe.scaglione@hpe.com> wrote:

    Greg,
    
    We are working -- and in beta -- with having the switch natively set SCE bits instead of CE and removing the iptable configuration on the target server.  Yet, I do not expect any different result since the TCP-SCE stack would react the same.
    
    Regards,
    Giuseppe Scaglione
    
    
    -----Original Message-----
    From: Greg White [mailto:g.white@CableLabs.com] 
    Sent: Friday, August 9, 2019 2:36 PM
    To: Jonathan Morton <chromatix99@gmail.com>om>; Scaglione, Giuseppe <giuseppe.scaglione@hpe.com>
    Cc: rgrimes@freebsd.org; tsvwg@ietf.org
    Subject: Re: [tsvwg] Switch testing at 25G with ECN --SCE Draft
    
    Right.  Per the SCE method, the switch would mark ECT(1) using a ramp, and then when the ramp would exceed 100% marking, it would change to using CE.  
    
    The implementation discussed here marks CE using a ramp, and when the ramp would exceed 100% marking, it changes to packet drop.  This, as you said, is simply RFC3168 ECN marking, not SCE ECN marking.
    
    I was just trying to set the record straight.  There was a claim made that a switch vendor had implemented SCE-style packet marking in hardware at 25Gbps, which wasn't accurate.
    
    -Greg
    
    
    
    On 8/9/19, 2:58 PM, "Jonathan Morton" <chromatix99@gmail.com> wrote:
    
        > On 9 Aug, 2019, at 11:44 pm, Scaglione, Giuseppe <giuseppe.scaglione@hpe.com> wrote:
        > 
        >>> Just to be super clear, this isn't a hardware implementation of SCE running at 25Gbps.
        > 
        > I am not sure I follow. The Test setup section of the paper clearly describes the hardware used -- severs, switch, cables. 
        > What I cannot disclose at this point is the exact model and characteristics of the HPE Aruba Switch used. Yet, it is a "real" Ethernet Switch, providing 25Gbps connectivity, configured to do bridging across the four ports and implementing RFC3168 with the ECN remarking configuration described in my previous email and on the paper.
        
        I think the issue is with the way the switch itself marks with CE, not ECT(1).  It's a limitation I think is worth acknowledging and, hopefully, finding a way to remove.
        
         - Jonathan Morton