Re: [tsvwg] start of WGLC on L4S drafts

[Pete Heist <[e-mail]>]

Hi Bob, two more responses...

On Thu, 2021-11-11 at 11:52 +0000, Bob Briscoe wrote:
> Pete,
> 
> On 11/11/2021 08:34, Pete Heist wrote:
> 
> > 
> > Hi Bob,
> > 
> > I read the responses. To keep things short, I'll just reply to a
> > couple points for clarification...
> > 
> > On Tue, 2021-10-26 at 00:12 +0100, Bob Briscoe wrote:
> > 
> > > Pete,
> > > 
> > > Replying to your points inline [BB] on each draft one at a time,
> > > starting with dualq-coupled-16...
> > > 
> > > On 24/08/2021 21:27, Pete Heist wrote:
> > > 
> > > 
> > > > # Comments on dualq-coupled-16
> > > > 
> > > > 
> > > > > dualq-coupled Abstract:
> > > > > Analytical study and implementation testing of the coupled aqm have
> > > > > shown that scalable and classic flows competing under similar
> > > > > conditions run at roughly the same rate.
> > > > Testing DualPI2 with the defaults showed about a 2x advantage in
> > > > throughput for L4S flows vs non-L4S flows, at the same RTT (see #2
> > > > above). "Roughly the same rate" isn't quantified, but the results seem
> > > > different from that.
> > > 
> > > [BB] I've changed it to "roughly equivalent", which I think is
> > > the briefest way of summarizing loads of results for words in an
> > > abstract.
> > > 
> > > 2:1 cannot cause a significantly negative impact [RFC5033] and is
> > > well within the "order of magnitude" required in the most recent
> > > RFC on this subject [RFC8085] (altho' that was about bulk UDP
> > > transfers, I can't see how fairness would depend on which
> > > transport protocol is in use).
> > > 
> > > 
> > > 
> > > > 
> > > > 
> > > > > dualq-coupled Abstract:
> > > > > When tested in a residential broadband setting, DCTCP also achieves
> > > > > sub-millisecond average queuing delay and zero congestion loss under
> > > > > a wide range of mixes of DCTCP and `Classic' broadband Internet
> > > > > traffic, without compromising the performance of the Classic traffic.
> > > > > The solution has low complexity and requires no configuration for the
> > > > > public Internet.
> > > > Bursty traffic or link layers can raise the limits on low queueing
> > > > delay:
> > > > https://github.com/heistp/l4s-tests/#between-flow-induced-delay
> > > 
> > > [BB] Gorry asked me to cut down the abstract, so I've removed all
> > > the stuff about testing in a residential broadband setting
> > > anyway. 
> > > See the mail I just sent him for the new wording. However, I can
> > > see now that changing it is probably going to lead to further
> > > haggling over different wording...
> > > 
> > > Nonetheless, let's move from wording to your technical point
> > > itself. Before I was hired by CableLabs to work on Low Latency
> > > DOCSIS I wrote a tech report about why bursty effects like this
> > > might happen and how to deal with it if they were a problem
> > > [SigQ-Dyn]. It's about how sojourn time doesn't measure a burst
> > > even once the whole burst is queued. You'll find this is already
> > > referenced from the dualq draft. We implemented the alternative
> > > metric ('scaled sojourn time'), but didn't use it in the end
> > > because we couldn't find a good reason for it being necessary.
> > > Since that time, I've thought of a simpler way of implementing an
> > > improved variant of the metric, which I wrote into the next rev
> > > of the draft recently.
> > > 
> > > But before considering replacing sojourn time we need to bear in
> > > mind that there's only one run of one experiment that looks odd.
> > > So we need to set ourselves up with a lot more solid evidence. If
> > > there is a performance degradation in more typical scenarios, we
> > > need to know whether it's big enough to worry about. If it is,
> > > the modified metric should improve the performance again.
> > > 
> > > [SigQ-Dyn] Briscoe, B., "Rapid Signalling of Queue Dynamics",
> > > Technical Report TR-BB-2017-001 arXiv:1904.07044 [cs.NI],
> > > September 2017, <https://arxiv.org/abs/1904.07044>. 
> > > 
> > > 
> > > 
> > > > 
> > > > 
> > > > > dualq-coupled Section 1.1:
> > > > > In contrast, dualq coupled aqms addresses the root cause of the
> > > > > latency problem --- they are an enabler for the smooth low latency
> > > > > scalable behaviour of scalable congestion controls, so that every
> > > > > packet in every flow can enjoy very low latency, then there is no
> > > > > need to isolate each flow into a separate queue.
> > > > I would like to be sure that this is true, not just with bursty traffic
> > > > and link layers, but also cross-flow traffic (tests needed on the
> > > > latter).
> > > 
> > > [BB] Which part do you mean by 'this'? "...every flow can
> > > enjoy..."? or "No need to isolate..."? 
> > > 
> > > I've edited the former to "...can potentially enjoy...".
> > 
> > What was meant was primarily "that every packet in every flow can
> > enjoy very low latency". The addition of "potentially" should cover
> > the cases where applications, link layers or any unforeseen factors
> > don't cooperate to achieve very low latency.
> 
> [BB2] OK. But I'm afraid I can read your 'should' here in two
> opposite ways. You could be meaning either of:
> * I'm now happy that... 'the addition of "potentially" should cover
> the cases...'
> * 'The addition of "potentially" should cover the cases...' but it
> doesn't, at least not to my satisfaction.

Right, in this case it was the first option, but the results will
ultimately be more important than the words.

> 
> 
> > 
> > 
> > > 
> > > 
> > > 
> > > > 
> > > > 
> > > > > dualq-coupled Section 1.4:
> > > > > Thousands of tests have been conducted in a typical fixed residential
> > > > > broadband setting.  experiments used a range of base round trip
> > > > > delays up to 100ms and link rates up to 200 mb/s between the data
> > > > > centre and home network, with varying amounts of background traffic
> > > > > in both queues.
> > > > It sounds like these tests were performed on a certain type of link
> > > > (residential cable?), in a certain RTT range (below 100ms). 
> > > 
> > > [BB] The draft says "below 100ms". And it gives the ref to the
> > > paper with the spec of the tests - it says they were over DSL,
> > > then emulated with an ethernet testbed for higher speeds than the
> > > DSL could achieve, after comparing the validity of the emulation.
> > > 
> > > 
> > > 
> > > > Bursty
> > > > links and higher RTTs should also be tested if L4S is to be used for
> > > > general purpose congestion control (see #3 above). We should end up
> > > > with a system that works well under most all conditions, otherwise it's
> > > > not clear how users and admins will know to change CCAs from one
> > > > activity to the next.
> > > 
> > > See my posting on the list to Sebastian on 31 Aug 21:
> > > "[tsvwg] tests of Prague utilization with bursty competition in L
> > > and C [more burst sources]"
> > > https://mailarchive.ietf.org/arch/msg/tsvwg/LfcOHNupIusPHyjVV4vFWFwS8bI/
> > > 
> > > There's a lot in that conversation, and you'll see some results
> > > of it appear in the ecn-l4s-id draft shortly. 
> > > At the risk of over-simplifying, two key sentences are:
> > > * "Updated link designs are not going to appear any time soon. In
> > > the mean time, the parameters of any flaky links and the L4S
> > > target Q delay can be set to levels that trade off between
> > > utilization and delay."
> > > * "Whichever technology enables reduced queuing delay
> > > variability, the world would want to change to reduce burst
> > > delays as well. "
> > > 
> > > 
> > > 
> > > 
> > > > 
> > > > 
> > > > > dualq-coupled Section 4.1.3:
> > > > > Experiments with the DualPI2 AQM (Appendix A) have shown that
> > > > > introducing 'drop on saturation' at 100% L4S marking addresses this
> > > > > problem with unresponsive ECN as well as addressing the saturation
> > > > > problem.  It leaves only a small range of congestion levels where
> > > > > unresponsive traffic gains any advantage from using the ECN
> > > > > capability, and the advantage is hardly detectable [DualQ-Test].
> > > > I might be misunderstanding the text, but two-flow tests of traffic
> > > > that is unresponsive to CE show that, as with RFC3168 ECN, there is an
> > > > advantage to setting ECT(0) or ECT(1), then not responding to CE,
> > > > that's easy to detect:
> > > 
> > > [BB] That section is about unresponsive traffic gaining advantage
> > > from using the ECN capability.
> > > I think you're talking about gaining advantage from being
> > > unresponsive, which is not in doubt.
> > > 
> > > To be clearer, I'll add "... unresponsive traffic gains any
> > > advantage from using the ECN capability (relative to being
> > > unresponsive without ECN)"
> > 
> > I did misunderstand this to mean that drop on saturation would
> > address the problem of flows that are unresponsive to ECN signals,
> > which is where the straightforward result I posted earlier came
> > from. That can be ignored in this context so I'll remove the link
> > to avoid confusion.
> > 
> > There's one more result related to gaining an advantage by marking
> > ECT(1) it doesn't look like we posted before. I need to find and
> > verify that, and I'll post it in a separate thread if I think it's
> > relevant.
> 
> [BB2] OK. Please confirm to the list if you don't think it's relevant
> as well.

I found we've already covered this elsewhere, so there's no need to re-
post it.

Thanks,
Pete

> 
> 
> Bob
> 
> 
> 
> > 
> > Regards,
> > Pete
> > 
> > 
> > > [BB] Whatever, thank you v much for your continued testing,
> > > reviewing and comments.
> > > 
> > > Cheers
> > > 
> > > 
> > > Bob
> > > 
> > 
>