[tsvwg] Fwd: Re: [tcpm] sce vs l4s comparison plots?

Tom Henderson <tomhend@uw.edu> Mon, 11 November 2019 03:04 UTC

Return-Path: <tomhend@uw.edu>
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 6941C1200D6 for <tsvwg@ietfa.amsl.com>; Sun, 10 Nov 2019 19:04:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 DwIBSUNyt9SL for <tsvwg@ietfa.amsl.com>; Sun, 10 Nov 2019 19:04:08 -0800 (PST)
Received: from mxout26.s.uw.edu (mxout26.s.uw.edu [140.142.234.176]) (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 4AC831200C3 for <tsvwg@ietf.org>; Sun, 10 Nov 2019 19:04:08 -0800 (PST)
Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by mxout26.s.uw.edu (8.14.4+UW14.03/8.14.4+UW19.10) with ESMTP id xAB331Wf005229 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=OK) for <tsvwg@ietf.org>; Sun, 10 Nov 2019 19:03:02 -0800
Received: by mail-wm1-f69.google.com with SMTP id f21so3200042wmh.5 for <tsvwg@ietf.org>; Sun, 10 Nov 2019 19:03:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=TyyJfKNZ64FEgfRcXcojcI62lA80wMmSr7ddRnghqHE=; b=AUWWxSXo3SQ9IQHXsv1pMCqIgFd8TbwiVyzAhUuklEpyTDHAZQcXxtYYMCsC2tD6wh 8eqqMkFWhW6RhPlqEgEAOMoRW87tNE1gQJqCbANL0jCPnFWuG93NhuQntgaBvG9BluSu 74V2zaSxI4dt1+czadPywZTt2Sd6mwCM9orRfseGeqY3XKV8Ul6enSCLlVQCS20sj7rs wmYrz5g7vp5MyerJONyTfC8RkFz2Pna5Qp6CFs/UC8fuq41RpA3JAPQ/uoIIiDq2PPbj iloWAeWabctlXcl68FLb0R0AxseyEySW+tMNy7+ZynZ8CkOoHOMKuV/dJHC+k/M0nsVs w6Gg==
X-Gm-Message-State: APjAAAUeYrtIkDwWyu30m6N/9EppIlvfGO5Z5PHJG/v6uukMmkFXERPu 9opH+EGtiTTVCMi8U8jJasxaFsLg68ufIPoCGzfEZdQlQ7Zl0H+5ztR7pcGRUd85Lz/JQVFjo5j NWQVi+t4skbAJGUJeGtd+GozHwGi+iUNUfTbLiyl1uA6E2og=
X-Received: by 2002:a1c:6309:: with SMTP id x9mr17291243wmb.108.1573441381013; Sun, 10 Nov 2019 19:03:01 -0800 (PST)
X-Google-Smtp-Source: APXvYqwyLT6SUKHtkpahZ5uIwiBad0bHpsPgMM4gU+tL6lUsOSdBcZqI6iXCQPvkdn7/K/eHQlwgsCuV+hcb62a8NiQ=
X-Received: by 2002:a1c:6309:: with SMTP id x9mr17291238wmb.108.1573441380793; Sun, 10 Nov 2019 19:03:00 -0800 (PST)
MIME-Version: 1.0
References: <108765ad-c545-4ce8-0fbb-faaa814c2239@tomh.org> <983d90c3-1551-fa36-dfd4-53002954192c@tomh.org>
In-Reply-To: <983d90c3-1551-fa36-dfd4-53002954192c@tomh.org>
From: Tom Henderson <tomhend@uw.edu>
Date: Sun, 10 Nov 2019 19:02:49 -0800
Message-ID: <CAC2TnRwC-BO_Xk0r3uxT4yhH++iOUagDOhmwnNsLvguTJZmZkw@mail.gmail.com>
To: tsvwg@ietf.org
Content-Type: multipart/alternative; boundary="00000000000093c9a80597095eaa"
X-PMX-Version: 6.4.8.2820816, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.11.11.25417, AntiVirus-Engine: 5.65.0, AntiVirus-Data: 2019.9.11.5650001
X-PMX-Server: mxout26.s.uw.edu
X-Sophos-SenderHistory: ip=209.85.128.69, fs=1447210, da=49891253, mc=13538, sc=1, hc=13537, sp=0, fso=36582389, re=8, sd=0, hd=30
X-Uwash-Spam: Gauge=X, Probability=10%, Report= TO_IN_SUBJECT 0.5, HTML_NO_HTTP 0.1, BODYTEXTH_SIZE_10000_LESS 0, BODYTEXTH_SIZE_3000_MORE 0, BODY_SIZE_10000_PLUS 0, DATE_TZ_NA 0, DQ_S_H 0, FROM_EDU_TLD 0, HREF_LABEL_TEXT_NO_URI 0, HREF_LABEL_TEXT_ONLY 0, HTML_BAD_EXTRAS 0, IN_REP_TO 0, KNOWN_MTA_TFX 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, NO_URI_HTTPS 0, REFERENCES 0, SPF_PASS 0, SXL_IP_TFX_WM 0, WEBMAIL_SOURCE 0, __ANY_URI 0, __BODY_TEXT_X4 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __COURIER_PHRASE 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __DQ_IP_FSO_LARGE 0, __DQ_NEG_HEUR 0, __DQ_NEG_IP 0, __DQ_S_HIST_1 0, __DQ_S_HIST_2 0, __DQ_S_IP_MC_100_P 0, __DQ_S_IP_MC_10_P 0, __DQ_S_IP_MC_1K_P 0, __DQ_S_IP_MC_5_P 0, __DQ_S_IP_SC_1_P 0, __FUR_RDNS_GMAIL 0, __HAS_FROM 0, __HAS_HTML 0, __HAS_MSGID 0, __HAS_REFERENCES 0, __HELO_GMAIL 0, __HEX28_LC_BOUNDARY 0, __HREF_LABEL_TEXT 0, __HTML_AHREF_TAG 0, __HTML_BAD_END 0, __HTML_BAD_START 0, __HTML_TAG_DIV 0, __HTML_TAG_TABLE 0, __IN_REP_TO 0, __MIME_HTML 0, __MIME_TEXT_H 0, __MIME_TEXT_H1 0, __MIME_TEXT_H2 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_TEXT_P2 0, __MIME_VERSION 0, __MSGID_DOMAIN_NOT_IN_HDRS 0, __RDNS_WEBMAIL 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __SUBJ_FORWARD 0, __TO_IN_SUBJECT2 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_WWW 0, __URI_NS , __X_GOOGLE_DKIM_SIGNATURE 0, __YOUTUBE_RCVD 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/DoaufpPHaqVGjGW58zvW59QtpUc>
Subject: [tsvwg] Fwd: Re: [tcpm] sce vs l4s comparison plots?
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: Mon, 11 Nov 2019 03:04:10 -0000

I am resending this, and another earlier message, from a different account
because it did not reach the mailing list from my personal email.

-------- Forwarded Message --------
Subject: Re: [tsvwg] [tcpm] sce vs l4s comparison plots?
Date: Sun, 10 Nov 2019 11:01:58 -0800
From: Tom Henderson <tomh@tomh.org> <tomh@tomh.org>
To: Dave Taht <dave@taht.net> <dave@taht.net>
CC: Rodney W. Grimes <4bone@gndrsh.dnsmgr.net> <4bone@gndrsh.dnsmgr.net>et>,
tcpm@ietf.org, tsvwg IETF list <tsvwg@ietf.org> <tsvwg@ietf.org>

Dave,
Thanks for the feedback; some replies inline below on the ns-3 parts.  You
asked in the first message whether the simulations used IW4 or IW10; the
answer is IW10.

I also have completely forgotten at this point, to what extent the
ns3 model of fq_codel matches the deployed reality. It was such a long
time ago.... as best as I recall ns3 didn't even have ecn support then!

I looked over the ns3 fq_codel implementation, and (by mark one eyeball)
it appears largely correct - nowadays we increase the codel count in the
bulk dropper, but unless there's a specific flooding test (?) in the
suite, we're not going to hit that. Might be able to fix that once I get
used to writing OOP again.

Noted; will add this to our tracker to look into.

More important to verify is the actual endpoint setup in the experiment
to make sure a real 5 tuple is in use....

The ns3 codel code matches the linux implementation, also.

I'd still have to spin up the test suite to actually trust it, and
I was (2012) pretty sure the cubic implementation differed
significantly from linuxes.


The native ns-3 Cubic model has some differences with respect to the Linux
model, because the former is based more on the RFC description.  However, I
have also run these tests using Direct Code Execution mode (which uses
Linux kernel code in the endpoints) using kernel 4.4 TCP code (the latest
available in DCE) and the results are similar with respect to the L4S
issues 16 and 17.

I haven't posted the DCE equivalent program yet in that repository but
probably will do so in the future.  DCE requires a more involved install
process.

I did have to patch the mainline ns-3 to get the ECN part working, however,
as you and Rodney noticed (both the CoDel and FQ-CoDel models, and the TCP
models) and there is a bit more work to do in ns-3 on aligning the endpoint
response to ECE with what is done in Linux.


And apparently is still missing some ECN (RFC3168) support as your
following link contains some patches:
6. cd back one level to the top-level ns-3 directory,
and patch the ns-3.30.1 release with a patch provided
in the l4s-evaluation/patches/ directory. This patch
adds support for ECE handling and DCTCP in the base
TCP code, and adds ECN handling to CoDel and FqCoDel models.

Well, I am *happy* to see it was the current release of ns3 + a little
bit. That's a relief.


My hope is that this patch will be mainlined for the next release, so that
we can remove this patch.  The AQM pieces are already being reviewed on our
GitLab.com issue tracker, and I am working with a few other contributors on
finalizing the DCTCP and Cubic models before we propose to merge to
mainline.


That said - oy - um, er - this being the first ever use of ECN in
ns3 requires quite a bit of validation. From a quick look at this patch,
simply off the top of my head - it doesn't follow rfc3168's
recommendation in section

6.1.5. Retransmitted TCP packets

"This document specifies ECN-capable TCP implementations MUST NOT set
either ECT codepoint (ECT(0) or ECT(1)) in the IP header for
retransmitted data packets, and that the TCP data receiver SHOULD
ignore the ECN field on arriving data packets that are outside of the
receiver's current window. "...

I think (need to look harder)

.... as much as some folk here would like to obsolete that, linux does
actually follow this portion of the spec (I don't know about other OSes)
, and it has long been one of my concerns regarding l4s (and cake's)
interactions with loss and flipping between queues in general.


Noted; will add this to our tracker.

- Tom