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

From: Tom Henderson <[email-masked]>
Date: Sun, 10 Nov 2019 19:02:49 -0800

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 <[email-masked]> <[email-masked]>
To: Dave Taht <[email-masked]> <[email-masked]>
CC: Rodney W. Grimes <[email-masked]> <[email-masked]>,
[email-masked], tsvwg IETF list <[email-masked]> <[email-masked]>

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