Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L4S vs SCE (Evolvability))

[Ingemar Johansson S <[e-mail]>]

Hi
Please see inline

/Ingemar

> -----Original Message-----
> From: Sebastian Moeller <[e-mail]>
> Sent: den 4 januari 2020 16:30
> To: Ingemar Johansson S <[e-mail]>
> Cc: Ingemar Johansson S
> <ingemar.s.johansson=[e-mail]>; [e-mail]
> Subject: Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L4S vs SCE
> (Evolvability))
> 
> Hi Ingemar,
> 
> more below in-line.
> 
> 
> > On Jan 4, 2020, at 15:41, Ingemar Johansson S
> <[e-mail]> wrote:
> >
> > Hi
> > See inline
> > /Ingemar
> >
> >> -----Original Message-----
> >> From: Sebastian Moeller <[e-mail]>
> >> Sent: den 3 januari 2020 17:37
> >> To: Ingemar Johansson S <[e-mail]>
> >> Cc: Ingemar Johansson S
> >> <ingemar.s.johansson=[e-mail]>; Black, David
> >> <[e-mail]>; Bob Briscoe <[e-mail]>; Roland
> >> Bless <[e-mail]>; [e-mail]; [e-mail]
> >> Subject: Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L4S vs SCE
> >> (Evolvability))
> >>
> >>
> >> Hi Ingemar,
> >>
> >> more below in-line.
> >>
> >>> On Jan 3, 2020, at 12:18, Ingemar Johansson S
> >> <[e-mail]> wrote:
> >>>
> >>> Hi
> >>> Please see inline
> >>> /Ingemar
> >>>
> >>>> -----Original Message-----
> >>>> From: Sebastian Moeller <[e-mail]>
> >>>> Sent: den 3 januari 2020 10:28
> >>>> To: Ingemar Johansson S
> >>>> <ingemar.s.johansson=[e-mail]>; Black, David
> >>>> <[e-mail]>; Bob Briscoe <[e-mail]>; Roland
> >>>> Bless <[e-mail]>
> >>>> Cc: Ingemar Johansson S <[e-mail]>;
> tsvwg-
> >>>> [e-mail]; [e-mail]
> >>>> Subject: Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L4S vs SCE
> >>>> (Evolvability))
> >>>>
> >>>> Hi Ingmar,
> >>>>
> >>>> On January 3, 2020 10:10:31 AM GMT+01:00, Ingemar Johansson S
> >>>> <ingemar.s.johansson=[e-mail]> wrote:
> >>>>> Hi
> >>>>> Yes I am aware that SCE works with RFC6040 tunnels, it does
> >>>>> however seem to work well with RFC4301 ditto.
> >>>>> Now I have no idea as regards to how large extent RFC4301 is
> >>>>> deployed on the internet and whether this is a large problem for
> >>>>> SCE or not. I notice however that RFC4301 is no problem for L4S.
> >>>>
> >>>>       [SM] I beg to differ, L4S will not play nice with either a
> >>>> rfc3168 or SCE- capable AQM on a tunneled segment, as it will
> >>>> completely misinterpret the received CE marks and will not respond
> >>>> appropriately with a sufficiently large reduction of the congestion
> >>>> window*. The currently still preferred solution to this issue, if I
> >>>> understand Bob correctly, is still to reason that such ECN-enabled
> >>>> AQMs along tunneled path segments (which I understand to be always
> >>>> inside the core of an AS as towards the edges packets get
> >>>> decapsulated) are rare enough to allow completely ignoring them.
> >>>
> >>> [IJ] This is more of a concern with traditional loss/ECN based
> >>> congestion control algorithms like Reno, Cubic (and DCTCP).
> >>
> >> 	[SM] How so? As far as I can tell the failure mode is, that L4S
> > flows will
> >> not yield to the rfc3168 AQMs CE marks in the way that the AQM
> >> expects/is designed for, thereby crowding out the 1/sqrt(p) flows and
> >> securing
> > themselves
> >> the lion's share of the bandwidth (assuming the hop does not need to
> >> dip
> > deep
> >> into dropping-instead-of-marking territory)). BBR, might bully over
> >> the
> > AQM's
> >> signals, but I am not sure whether that actually is an improvement
> >> over
> > the
> >> status quo (unless purely viewed from BBR's perspective), but that is
> >> a
> > different
> >> kettle of fish.
> >>
> >>> If one look more into the
> >>> future (and actually present) I see algorithms like BBRv2 that
> >>> strive one BDP queue and will therefore not strive to bloat the
> >>> queues as much as the forementioned CC algos.  It seems to me like
> >>> there is incentive to go towards more of these. And as you point out
> >>> below there is work ongoing work by Bob and others to add RFC3168
> > compatibility to
> >> TCP Prague.
> >>
> >> 	[SM] Which albeit quite belated is a welcome development. I am
> > looking
> >> forward to the data demonstrating that approach working as intended
> >> and as required (I am especially interested to see how long this is
> >> going to take
> > and
> >> whether it introduces a "latency-bolus" in the queue). But that still
> > leaves all
> >> other transports the L4S folks envision classifying into the
> >> L4S-queue to
> > worry
> >> about. Doing that for TCP Prague is only a first mile-stone, sure
> >> being
> > proof of
> >> principle it might be an important mile stone, but if coexistence
> >> with the
> > existing
> >> internet is of serious concern (which it should) it is only the
> > beginning...
> >> 	I consider this to be a side-effect/consequence of redefining what a
> > CE-
> >> mark means, as the SCE proposal demonstrates that is not the only
> >> option
> > to
> >> implement 1/p style signaling.
> >>
> >>
> >>> Speaking of the SCE capable AQMs, how much does it take to make
> them
> >>> L4S capable instead, an update of RFC8290 ?
> >>
> >> 	[SM] Note that RFC8290 is not really SCE capable to begin with (how
> >> could it, it predates the SCE drafts considerably). Be that as it
> >> may,
> > IMHO it
> >> would take a) as a precondition a robust and reliable indicator of
> >> how a
> > flow will
> >> respond to congestion signaling, 1/p or 1/sqrt(p), unfortunately
> >> ECT(1) is
> > neither
> >> robust nor reliable*, and b) a consensus that overloading the ECN
> > CE-codepoint
> >> with two semantic different meanings is reliable, robust (and safe
> >> for the
> > rest of
> >> the network).
> >> 	The more relevant question for me is what it would take to remedy
> >> these two obvious issues in the L4S design... and what would it take
> >> in
> > addition
> >> to start tackling the failure of the dual queue coupled AQM to do the
> >> one
> > thing is
> >> was intended/designed for reliably and robustly.
> >
> > [IJ] I understand that
> >  a) delves into the flow rate fairness that has been discussed at
> > length in other mail treads.
> 
> 	[SM] I am puzzled, a) above is about how it mark/differentiate
> between flows that should be treated to 1/p versus those that should be
> treated to 1/sqrt(p) congestion signaling. IMHO this has exactly zero to
do
> with flow rate fairness and all with how to make the two types of
congestion
> responses coexist peacefully in the existing internet. But please
elaborate
> what you referred to above with "flow rate fairness".
> 	Really, the constant attacks against FQ solution are a RED HERRING
in
> the context whether L4S is ready to reach experimental stage. My issue is
> not that L4S might not be the theoretically best solution for the
challenge it
> was designed to solve, my issue is that practically the current
> implementations ARE NO SOLUTION at all, as they do not work reliably and
> robustly, period.
> 
> 
> >     I don't see the possible rate unfairness that DualQ gives as
> > unsafe
> 
> 	[SM] Try the shoe on the other foot then, if the IETF would command
> to change the dual queue coupled AQM so that it gives the same
> priority/bandwidth advantage to non-L$S flows instead, would you still be
> okay with that? If your answer is yes, you can predict which changes to
dual
> queue coupled AQM I will propose next... I take it that you also consider
15
> ms the ideal ref-delay for the non-L4S's queue PI2 instance without being
> able to tell what makes 15 so magically wonderful in that context?
> 
> 
> > and
> > it is quite clear to me that
> >     this is something that relates more to how endpoint congestion
> > control algorithms are deigned
> >     than on the specific design of DualQ.
> 
> 	[SM] Again I disagree, the dual queue coupled AQM's sole reason to
> exists is to equitably share between the two traffic classes the L4S
approach
> categorizes the world into. Failure to do so reliably and robustly is NOT
a
> function of the endpoints  but of your isolation mechanism (as an isolator
> that can be easily gamed by the endpoints does not even deserve that
> name).
> 	I realize that this is an inconvenient truth and that both Bob and
Koen
> always try to change this into an unrelated discussions about say RTT-
> independence, but that is simply a distraction strategy as I have alluded
to
> multiple times, not least because so far the L4S team has utterly failed
to
> present data demonstrating that they managed to make TCP Prague, their
> demonstration transport, RTT-independent enough to paper over the dual
> queue coupled AQM's design mistakes. But to be explicit, even if you
> manage to fix this for TCP Prague, unless you only admit TCP Prague flow
the
> the L4S queue you have won very little. If it apprears that I repeat
myself,
> then simply because part of my audience does not seem to be listening or
> engaging with my arguments at all.
> 
> 
> > I understand that we disagree on
> > this and therefore it
> >     is best to ask a wider group to comment this.
> >  b) Means that a RCF3168 ECN capable flow whose packets have been CE
> > marked upstreams are put
> >    in the L4S queue in the DualQ downstreams and therefore causing
> > packet reordering for the RFC3168 flow.
> 
> 	[SM] Exactly, by mis-classifying CE packets into the L4S queue one
> risks out-of-order delivery for non-L4S flows, as a direct consequence of
> abusing a single codepoint as binary classifier. If this single codepoint
would
> be the only option this might be worth discussing/accepting, but since
there
> are quite a number of different classifier schemes ECT(1) really should be
> taken off the table IMHO.
> 	Except, that for the reordering to happen, you do not even need
> packets in both directions, even in one direction reordering can be
inflicted
> upon non-L4S flows, if a CE-marked packet hits the dual queue coupled AQM
> it will traverse the L4S queue and will be given priority over packets of
the
> same flow in the non-L4S queue, so as long as the non-L4S queue is not
> empty reordering can happen. That is a side-effect most easily dealt with
by
> employing a full independent bit for proper classification, or by
defaulting all
> CE-marked packets to the non-L4S queues (that way reordering is restricted
> to the new L4S flows and there s a real incentive to carefully look again
at the
> unfortunate choice of 15ms ref_delay for the non-L4S queue, a win-win
> situation form the perspective of non-L4S traffic).
> 
> 
> >    The severity of this reordering assumes a scenario where
> >     i) congestion occurs simultaneously both on the upstreams and
> > downstreams,
> 
> 	[SM] I am not sure that you need simultaneous congestion in both
> directions, and secondly, I believe this situation to be more
probable/likely
> than you seem to assume (this is partly a consequence of the often highly
> asymmetric links to end-users).
> 
> >        I have so far seen this as quite unlikely
> >     ii) congestion occurs upstreams and the uncongested DualQ
> > downstreams deliberately builds a large queue,
> >        I have not see that DualQ does this.
> >    I have possibly missed something, please clarify
> 
> 	As above for packet reordering you do not need simultaneous bi-
> directional congestion. My point however is that this again is one of the
> situations where the L4S team opted to make the non-L4S traffic pay all
the
> cost of the "impedance mismatch" between the current network and the
> "brave new world" that L4S promises.

[IJ] I believe that you misunderstood the scenario. It is not about
bidirectional congestion (or additional congestion in the reverse ACK path).
It is only about the congestion in the forward path. 
Consider a path between a sender and a receiver with two intermediate nodes
A and B, where node A is upstreams i.e closer to the sender. Both nodes
implement AQMs that can CE mark ECT packets. Node B implements a DualQ AQM
in which ECT(1) and CE marked packets are directed to the L4S queue. This
correctly means that CE marked packets for an RFC3168 flow will also go into
the L4S queue, which can cause packet reordering for the RFC3168 flow. 
For this to actually happen you need any of (repeat of my last email)
     i) congestion occurs simultaneously both on node A and B
          at least it should happen within the same RTT 
           I have so far seen this as quite unlikely 
     ii) congestion occurs in node A and the 
         uncongested DualQ in node B builds a (large) queue 
         I have not seen that DualQ does this.
How likely is it that any of these scenario happens ?


> 
> Best Regards
> 	Sebastian
> 
> 
> 
> >
> >
> >>
> >> Best Regards
> >> 	Sebastian
> >>
> >>
> >>
> >> *) Which flow does a CE-marked packet belong to a L4S-capable or an
> > rfc3168-
> >> compatible one?
> >>
> >>
> >>>
> >>>
> >>>> Best Regards
> >>>>        Sebastian
> >>>>
> >>>> *) I realize that there is finally some on-going research work on
> >>>> rfc3168- compatibility in TCP Prague, but I have seen no data yet
> >>>> indicating that the proposed scheme triggers fast enough (or even
> >>>> at all). I reserve judgement until I see the data.
> >>>>
> >>>>>
> >>>>> /Ingemar
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Black, David <[e-mail]>
> >>>>>> Sent: den 2 januari 2020 17:26
> >>>>>> To: Ingemar Johansson S <[e-mail]>;
> Bob
> >>>>> Briscoe
> >>>>>> <[e-mail]>; Roland Bless <[e-mail]>
> >>>>>> Cc: De Schepper, Koen (Nokia - BE/Antwerp)
> >>>>> <koen.de_schepper@nokia-bell-
> >>>>>> labs.com>; Kyle Rose <[e-mail]>; [e-mail]; tsvwg-
> >>>>>> [e-mail]; Black, David <[e-mail]>
> >>>>>> Subject: RE: RFC 4301 on ECN codepoints (was RE: [tsvwg] L4S vs
> >>>>>> SCE
> >>>>>> (Evolvability))
> >>>>>>
> >>>>>> See RFC 6040, which updates this area of RFC 4301.
> >>>>>>
> >>>>>> In addition, see  draft-ietf-tsvwg-rfc6040update-shim and
> >>>>>> draft-ietf-tsvwg-ecn-
> >>>>>> encap-guidelines, both of which apply RFC 6040 to additional
> >>>>>> encapsulations/tunnels ... and both of which are on Bob Briscoe's
> >>>>> "round
> >>>>>> tuit"
> >>>>>> list to write better fragmentation text (what's currently in both
> >>>>> drafts
> >>>>>> does not
> >>>>>> comply with RFC 3168's fragmentation provisions, hence has to be
> >>>>> changed).
> >>>>>>
> >>>>>> Thanks, --David
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Ingemar Johansson S <[e-mail]>
> >>>>>>> Sent: Thursday, January 2, 2020 5:13 AM
> >>>>>>> To: Black, David; Bob Briscoe; Roland Bless
> >>>>>>> Cc: De Schepper, Koen (Nokia - BE/Antwerp); Kyle Rose;
> >>>>> [e-mail];
> >>>>>>> [e-mail]; Ingemar Johansson S
> >>>>>>> Subject: RFC 4301 on ECN codepoints (was RE: [tsvwg] L4S vs SCE
> >>>>>>> (Evolvability))
> >>>>>>>
> >>>>>>> Hi
> >>>>>>>
> >>>>>>> I put my question in a separate thread to avoid messing up the
> >>>>>>> original thread.
> >>>>>>>
> >>>>>>> I read in https://tools.ietf.org/html/rfc4301#section-5.1.2.1
> >>>>>>> the following
> >>>>>>>
> >>>>>>>     (6) If the ECN field in the inner header is set to ECT(0) or
> >>>>>>>         ECT(1), where ECT is ECN-Capable Transport (ECT), and if
> >>>>> the
> >>>>>>>         ECN field in the outer header is set to Congestion
> >>>>> Experienced
> >>>>>>>         (CE), then set the ECN field in the inner header to CE;
> >>>>>>>         otherwise, make no change to the ECN field in the inner
> >>>>>>>         header.  (The IPv4 checksum changes when the ECN
> >>>>> changes.)
> >>>>>>>
> >>>>>>> So, if we have an SCE flow that is tunneled:
> >>>>>>> 1) At the tunnel ingress, the ECN bits are copied to the outer
> >>>>> header.
> >>>>>>> 2) Somewhere along the tunneled path an SCE compatible AQM
> >>>>>>> remarks from ECT '10' to SCE '01'.
> >>>>>>> 3) At tunnel egress, given rule #6 above, I understand that the
> >>>>> inner
> >>>>>>> header will still be ECT '10'.
> >>>>>>>
> >>>>>>> In order words, the SCE congestion marks along the tunneled
> >>>>> interface
> >>>>>>> become ignored and the queue will grow until packets are either
> >>>>>>> CE marked, or dropped.
> >>>>>>>
> >>>>>>> Is this a correct interpretation ?
> >>>>>>>
> >>>>>>> /Ingemar
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Black, David <[e-mail]>
> >>>>>>>> Sent: den 2 januari 2020 00:32
> >>>>>>>> To: Bob Briscoe <[e-mail]>; Roland Bless
> >>>>>>> <[e-mail]>
> >>>>>>>> Cc: De Schepper, Koen (Nokia - BE/Antwerp)
> >>>>> <koen.de_schepper@nokia-
> >>>>>>> bell-
> >>>>>>>> labs.com>; Ingemar Johansson S
> >>>>> <[e-mail]>;
> >>>>>>> Kyle
> >>>>>>>> Rose <[e-mail]>; [e-mail]; [e-mail];
> >>>>>>>> Black,
> >>>>>>> David
> >>>>>>>> <[e-mail]>
> >>>>>>>> Subject: RE: [tsvwg] L4S vs SCE (Evolvability)
> >>>>>>>>
> >>>>>>>> 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
> >>>>>>>>>>>>> <https://protect2.fireeye.com/v1/url?k=10e7b9ba-
> 4c6d6cbf-
> >>>>>>> 10e7f921
> >>>>>>>>>>>>> -861010bc36ff-2b3c729b7d8a378e&q=1&e=35be9991-3367-
> >> 47d3-
> >>>>>>> b023-
> >>>>>>>> ed85
> >>>>>>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>
> 01dddd52&u=http%3A%2F%2Fbobbriscoe.net%2Fprojects%2Flatency%2Fpe
> >>>>>>> r
> >>>>>>>>>>>>> -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#s
> >>>>>>>>>>>>> ection-
> >>>>>>> 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
> >>>>>>>>> Briscoehttps://protect2.fireeye.com/v1/url?k=9834ac6d-
> c4be7968
> >>>>>>>>> -
> >>>>>>> 9834ecf
> >>>>>>>>> 6-861010bc36ff-d256b2de1d12a128&q=1&e=35be9991-3367-
> 47d3-
> >>>> b023-
> >>>>>>>> ed8501dd
> >>>>>>>>> dd52&u=http%3A%2F%2Fbobbriscoe.net%2F
> >>>>
> >>>> --
> >>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> >