Re: [tsvwg] L4S vs SCE (Evolvability)

["Black, David" <[e-mail]>]

Bob,
(posting as an individual)

The assertion that SCE traffic will "starve" is just plain wrong in the following ...

> > The SCE markings can be used independently whether you have multiple
> > queues or just a single queue.
> [BB] This seems to be the opposite of reality. Perhaps you've used the
> word 'can' because you think it might be possible. But there's good
> reason to doubt that. As follows...
> 
> Packets from non-SCE and from SCE senders are indistinguishable by just
> looking at them. So, if there's a single queue, they have to be mixed
> together in it {Note 1}. But a single queue can only have one length.
> Any transports that don't understand SCE drive the single queue to a
> deeper operating point (defined by CE or drop).

The reasoning appears to be sound up to this point, but the next sentence does not follow from the above:

> This overruns the SCE
> operating point, and causes SCE marking to approach 100% {Note 2}. Then
> those transports that do understand SCE will starve.

Actually, it causes both SCE and non-SCE senders to operate at that "deeper operating point (defined by CE or drop)" because SCE traffic has an RFC-3168-like response to CE marks, and the usual reaction to drops.  The result is a deeper queue than would have resulted in the absence of non-SCE traffic, but the result is definitely *not* starvation.

Thanks, --David

> -----Original Message-----
> From: Bob Briscoe <[e-mail]>
> Sent: Tuesday, December 31, 2019 6:11 PM
> To: Roland Bless
> Cc: De Schepper, Koen (Nokia - BE/Antwerp); Ingemar Johansson S; Kyle
> Rose; [e-mail]; [e-mail]
> Subject: Re: [tsvwg] L4S vs SCE (Evolvability)
> 
> 
> [EXTERNAL EMAIL]
> 
> Roland,
> 
> As I just said, I noticed that Koen's useful response snipped some of
> your responses about evolvability that I ought to have addressed.
> Sorry, you'll need to reload state from November...
> 
> On 22/11/2019 02:32, Roland Bless wrote:
> > Hi Bob,
> >
> > see inline.
> >
> > On 21.11.19 at 15:44 Bob Briscoe wrote:
> >> Roland,
> >>
> >> I'm not getting it....
> >>
> >> On 21/11/2019 09:32, Roland Bless wrote:
> >>> Hi Bob,
> >>>
> >>> see inline.
> >>>
> >>> On 21.11.19 at 19:34 Bob Briscoe wrote:
> >>>> On 20/11/2019 21:22, Roland Bless wrote:
> >>>>> Yes, but as I also expressed my concerns w.r.t. the L4S codepoint
> >>>>> earlier, at the cost of binding this to a quite fixed set of L4S
> >>>>> behaviors and "burning" the last ECT codepoint. Personally, I like
> >>>>> concepts with a little bit more potential to be useful for future
> >>>>> development (evolvability) of congestion controls, e.g., BBRv2 and
> >>>>> LoLa could also benefit from an SCE-like marking...
> >>>>>
> [BB] BBRv2 has not used SCE, but it has used L4S marking. And the
> authors of the LoLa draft have not used SCE but they have merged with
> the NQB draft, so that they can work with L4S as well. So perhaps your
> belief that SCE is "more evolvable" is just that - a belief.
> 
> 
> >> This last sentence... please really spell it out what you could possibly
> >> be meaning here. What has made you suddenly think this particular
> >> marking scheme has got magical properties that bestow evolvability? I'm
> >> serious, if you can't explain why you've said a sentence like this, it
> >> implies you are under the spell of some cult or fad.
> > Not sure what you are trying to indicate by your last sentence, but
> > sure, I can elaborate a bit on my last sentence.
> > I find it architecturally cleaner to have an additional ECN codepoint
> > used for indicating "SCE" rather than (ab)using it as classifier for the
> > dualQ AQM.
> [BB] I just forked another thread 'ECN as a classifier' to address that
> assertion.
> > The SCE markings can be used independently whether you have multiple
> > queues or just a single queue.
> [BB] This seems to be the opposite of reality. Perhaps you've used the
> word 'can' because you think it might be possible. But there's good
> reason to doubt that. As follows...
> 
> Packets from non-SCE and from SCE senders are indistinguishable by just
> looking at them. So, if there's a single queue, they have to be mixed
> together in it {Note 1}. But a single queue can only have one length.
> Any transports that don't understand SCE drive the single queue to a
> deeper operating point (defined by CE or drop). This overruns the SCE
> operating point, and causes SCE marking to approach 100% {Note 2}. Then
> those transports that do understand SCE will starve.
> 
> In contrast, L4S works in dual queues or multiple queues (where 'works'
> means it gives very low latency without losing utilization).
> 
> Also, there is considerable scope for evolvability with both:
> * the dualQ is a framework that is intended to encompass different AQMs
> in future.
> * and there is considerable scope for developing the ways FQ uses L4S.
> 
> {Note 1}: Unless L4 identifiers are used to separate out microflows, and
> identify low latency flows by their behaviour. But then it's not really
> a single queue, unless you make it look like a single queue, but still
> treat it like multiple queues, as in LFQ. However, schemes like LFQ are
> "single-queue" in name only. They still have all the downsides of
> multiple queues.
> 
> {Note 2}: Unless the SCE operating point is hardly any shallower than
> that for CE, in which case SCE gives hardly any improvement.
> 
> > If one leaves the coupling aside the
> > algorithm for marking will probably not differ so much from what is
> > proposed in L4S.
> [BB] You still haven't explained (rather than asserted a belief) why the
> choice between SCE and L4S has anything to do with evolvability.
> 
> >>>> My whole purpose in solving the problem of deploying scalable CCs
> over
> >>>> the Internet was to re-juvenate evolution (to widen the range of
> >>>> applications that could be supported by different transport behaviours,
> >>>> particularly for real-time with low latency and high throughput at the
> >>>> same time). One of the main things that has stopped CCs evolving so
> far
> >>>> is the need for friendliness with the Reno behaviour that was not
> >>>> scaling over the years.
> >>> FWIW, our delay-based approach has deployment problems at the
> >>> other end of the spectrum: it gets suppressed by loss-based CCs...
> >>> (and we don't want to sacrifice our low delay goal).
> >>>
> >>>> If SCE is primarily supported in FQ AQMs, that will constrain flows to
> >>>> be capped at the rate that FQ gives them. How is that doing anything
> >>> I was solely referring to the marking behavior of SCE, not a particular
> >>> implementation based on FQ-AQMs.
> >> This implies you believe all that silliness about a shallower SCE
> >> threshold not starving an SCE flow in a single queue, because it makes
> >> SCE flows not want to use the queue.
> > I do not understand what you are saying here.
> [BB] I've now explained this above (after "But there's good reason to
> doubt that...").
> 
> The silliness I'm referring to is the statement by Jonathan M in his
> tsvwg talk at IETF-106 that CNQ is backward compatible with RFC3168
> traffic, because its performance for SCE traffic when mixed with 3168 is
> bad enough that it discourages use of SCE alongside 3168.
> 
> >>>> other than massively constraining future evolution of CCs, especially
> >>>> real-time ones? See Per-Flow Scheduling and the End-to-End
> Argument
> >>>> <http://bobbriscoe.net/projects/latency/per-flow_tr.pdf>. I don't
> need
> >>>> to tell you that the e2e argument is all about giving end systems the
> >>>> power to innovate without permission.
> >>>> Anyway, what are you imagining would stop CCs evolving alongside
> other
> >>>> scalable CCs? In much the same way CCs have always evolved. With L4S
> you
> >>>> have a clean slate that seems just like a FIFO with a shallow ECN-only
> >>>> immediate AQM. And other flows are causing you hardly any delay and
> very
> >>>> rarely any loss. Think of all the things you can do with that. Go
> >>>> evolve, Roland!
> >>> I already said that the Dual Queue AQM is nice, but comes with the
> >>> problem due to its built-in dropping law. Other CCs may react differently
> >>> and BBR was one example of newer CCs that did not work in the L4S
> queue
> >>> without further adaptation.
> >> The built in dropping law is for the old traffic ('pre-evolved' if you
> >> like) that doesn't respond to anything else but loss. That's what
> >> drop-based AQMs were for - to fool Reno etc into thinking they had hit
> >> the buffers, so to speak.
> > Yes, I understand that. But what happens if the classic traffic
> > once vanishes and we only have low-delay congestion control and
> > want to re-use the "second" queue for other purposes, e.g., using
> > it for flows that do not use loss-based CC?
> [BB] Let me repeat back the question, 'cos it seems rather odd, so
> perhaps I've misunderstood.
> 
> You want me to assume that the classic behaviour of repeatedly seeking
> out more capacity until loss occurs doesn't exist on the Internet any
> more. There's only low-delay CC, by which I think you mean CC based on
> L4S ECN (but I'm not sure that's your meaning).
> 
> Then, it sounds like everything would be working well. So why do you
> want to re-use the "second" queue for other purposes? Nothing is wasted
> if you don't use it. It has no capacity associated with it. it's just
> some lines of code sitting there in case packets appear from a classic CC.
> 
> 
> >>>    > The key thing here is the wording of the Prague requirements
> >>>> <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-08#section-4>.
> >>>> We have a session in the 'Prague' side-meeting tomorrow to review
> them
> >>>> (and I encourage this on this list too).
> >>>>
> >>>> Later down the line, if the L4S experiment is successful, there will be
> >>>> an opportunity to review these requirements if a standards track doc
> >>>> replaces the experimental (it is easier to relax CC requirements than
> >>>> tighten them). So, for the expt track, the requirements are designed to
> >>>> protect competing flows from harm in a tighter way than you might find
> >>>> in RFC5033 or similar.
> >>>>
> >>>>
> >>>> Nonetheless, even the 1/p isn't tightly spec'd, quoting:
> >>>>
> >>>>      The inverse proportionality requirement above is worded
> >>>>      as a 'SHOULD' rather than a 'MUST' to allow reasonable flexibility
> >>>>      when defining these specifications.
> >>> Yes, but something has to be implemented (in hardware) and therefore
> it
> >>> is fixed for some time and it should be consistent along a path, so I
> >>> don't see a viable path for evolvement of this coupling law...
> >> Why does the coupling law need to evolve? It's a relationship between
> >> something invariant (scalable) and the past (which is over, by
> >> definition, so it's not going to change now).
> > See above, probably we want to put something into queue which is
> > using a non-loss-based congestion control and/or we need to change
> > the (1/p,1/p^2) marking.
> [BB] The queue doesn't induce loss, the CC does. The queue isn't 1/p or
> 1/p^2 or whatever, the different CCs are. So, if a CC is using the C
> queue without inducing any loss (e.g. a delay-based CC might be able to
> keep the queue under the AQM's target delay), then the coupling won't
> couple any marking across to the L queue.
> 
> But I can't imagine why a delay-based CC that can keep the queue below
> the target of the AQM would want to classify itself into a queue
> designed for CCs that need to induce a decent queue (in order to
> maintain full utilization), given such queue-inducing traffic might
> start up at any time.
> 
> >> If you want to evolve, you select what's best for you - probably the
> >> nice clean L4S ECN queue. I still don't get what sort of evolution you
> >> can't do? Evolvability isn't about a researcher being able to do what
> >> they'd like.
> > I also don't understand it in this way, but investigating
> > invariables and degrees of freedom prudently may enable or facilitate
> > deployment of new stuff. If that new stuff cannot be deployed
> > it never gets a chance of being weeded out later either.
> [BB] If you have something specific in mind, please say it. This is all
> getting rather abstract.
> 
> This does make me want to question your notion of evolvability. Usually,
> when we make sure the Internet supports evolvability, we mean
> evolvability of new applications. We don't mean the ability for
> researchers to come up with different ways to solve problems that are
> already solved. There seems to be a hint of a complaint in your emails
> that L4S doesn't leave room for researchers to solve the same problem
> differently. That sort of evolvability is rather a luxury isn't it? If
> one approach solves an enduring problem with the Internet, it would be
> rather churlish to say "No, we can't use this solution, because it might
> preclude some ideas that might lead to other solutions to the same
> problem in the future, but we're not sure."
> 
> Having said that, I hope I (and Koen) have shown that L4S still leaves
> scope for complementary delay-based CCs, not to mention scope for
> different AQMs and for different FQ-based solutions.
> 
> 
> Regards
> 
> 
> 
> Bob
> 
> 
> 
> >
> > Roland
> >
> 
> --
> __________________________________________________________
> ______
> Bob Briscoehttp://bobbriscoe.net/