[Ecn-sane] 2019-12-31 docsis strict priority dual queue patent granted

[Ecn-sane] 2019-12-31 docsis strict priority dual queue patent granted

[Dave Taht]

I don't normally read patents, but, this one is pretty cable modem
specific and reads better than the related internet drafts.The
interaction with maps scheduling is well described.

https://patents.google.com/patent/US10523577B2/en

Of particular irony is the misspelt  "fear/flow cueing"  and I had
suggested a bloom fillter in all innocence when some of these ideas
were first discussed.

There are a few other patents cited of interest.

-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729

Re: [Ecn-sane] 2019-12-31 docsis strict priority dual queue patent granted

[Luca Muscariello]

[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]

A Bloom filter based classifier for Bottlenecked vs non bottlenecked flows
was done in here in 2005.

https://team.inria.fr/rap/files/2013/12/KMOR05a.pdf

And associated patent granted since 2011

https://patents.google.com/patent/US7933204B2/en?oq=US7933204B2+United+States++

Luca

On Thu, Jan 23, 2020 at 3:29 AM Dave Taht <dave.taht@gmail.com> wrote:

> I don't normally read patents, but, this one is pretty cable modem
> specific and reads better than the related internet drafts.The
> interaction with maps scheduling is well described.
>
> https://patents.google.com/patent/US10523577B2/en
>
> Of particular irony is the misspelt  "fear/flow cueing"  and I had
> suggested a bloom fillter in all innocence when some of these ideas
> were first discussed.
>
> There are a few other patents cited of interest.
>
> --
> Make Music, Not War
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-435-0729
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane
>

[-- Attachment #2: Type: text/html, Size: 2845 bytes --]

Re: [Ecn-sane] 2019-12-31 docsis strict priority dual queue patent granted

[Dave Taht]

On Thu, Jan 23, 2020 at 12:21 AM Luca Muscariello <muscariello@ieee.org> wrote:
>
> A Bloom filter based classifier for Bottlenecked vs non bottlenecked flows
> was done in here in 2005.
>
> https://team.inria.fr/rap/files/2013/12/KMOR05a.pdf
>
> And associated patent granted since 2011
>
> https://patents.google.com/patent/US7933204B2/en?oq=US7933204B2+United+States++

I guess they've licensed the related patents here.

You missed the "strict priority queue" part... there's nothing in here
that explicitly gives "classic" traffic
a means to not starve.... one part thereof, of many.

"Otherwise, this exemplary embodiment enables system configuration to
discard the low-priority packet tail, and transmit the high-priority
packet instead, without waiting."


> Luca
>
> On Thu, Jan 23, 2020 at 3:29 AM Dave Taht <dave.taht@gmail.com> wrote:
>>
>> I don't normally read patents, but, this one is pretty cable modem
>> specific and reads better than the related internet drafts.The
>> interaction with maps scheduling is well described.
>>
>> https://patents.google.com/patent/US10523577B2/en
>>
>> Of particular irony is the misspelt  "fear/flow cueing"  and I had
>> suggested a bloom fillter in all innocence when some of these ideas
>> were first discussed.
>>
>> There are a few other patents cited of interest.
>>
>> --
>> Make Music, Not War
>>
>> Dave Täht
>> CTO, TekLibre, LLC
>> http://www.teklibre.com
>> Tel: 1-831-435-0729
>> _______________________________________________
>> Ecn-sane mailing list
>> Ecn-sane@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/ecn-sane



-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729

Re: [Ecn-sane] 2019-12-31 docsis strict priority dual queue patent granted

[Jonathan Morton]

> On 24 Jan, 2020, at 7:37 am, Dave Taht <dave.taht@gmail.com> wrote:
> 
> "Otherwise, this exemplary embodiment enables system configuration to
> discard the low-priority packet tail, and transmit the high-priority
> packet instead, without waiting."

So this really *is* a "fast lane" enabling technology.  Just as we suspected.

 - Jonathan Morton

Re: [Ecn-sane] 2019-12-31 docsis strict priority dual queue patent granted

[Sebastian Moeller]

Hi Jonathan,


> On Jan 24, 2020, at 08:44, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
>> On 24 Jan, 2020, at 7:37 am, Dave Taht <dave.taht@gmail.com> wrote:
>> 
>> "Otherwise, this exemplary embodiment enables system configuration to
>> discard the low-priority packet tail, and transmit the high-priority
>> packet instead, without waiting."
> 
> So this really *is* a "fast lane" enabling technology.  Just as we suspected.

	They seem to be setting their customers up for a head-on collision with the European Union's net neutrality rules, according to which "special services/fast lanes" are permissible under the condition thay they are realized with completely dedicated addition bandwidth. Just looking at their patent diagram there is one common input path to the classifier. So either that fast lane is not going to be a paid for fast lane, or the ISPs rolling this out will be in hot water with the respective national regulators (at least in the EU). The one chance would be to give the end-user control over the classification engine, or if the strict priority path is only used for ISP originated VoIP traffic (I seem to recall there are weasel words in the EU rules that would allow that and ISPs are doing something like that already, and I agree that it is nice to be able to field an emergency call independent of access link load).

Best Regards
	Sebastian


> 
> - Jonathan Morton
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane

Re: [Ecn-sane] 2019-12-31 docsis strict priority dual queue patent granted

[Dave Taht]

Jeeze, you guys are up early. I read this stuff on the plane home from
australia, and am still a bit under the weather.

On Fri, Jan 24, 2020 at 12:01 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>
> Hi Jonathan,
>
>
> > On Jan 24, 2020, at 08:44, Jonathan Morton <chromatix99@gmail.com> wrote:
> >
> >> On 24 Jan, 2020, at 7:37 am, Dave Taht <dave.taht@gmail.com> wrote:
> >>
> >> "Otherwise, this exemplary embodiment enables system configuration to
> >> discard the low-priority packet tail, and transmit the high-priority
> >> packet instead, without waiting."
> >
> > So this really *is* a "fast lane" enabling technology.  Just as we suspected.

Well, there are weasel words elsewhere in the patent, and the dualq
code for linux merely cleared a lane for L4S traffic and hardcoded the
ect(1) as an identifier. It would be good to have more data on
rtt-fairness, and on CE reordering of rfc3168 ecn packets.

I spent time dreaming up also all the ways "queue protection" could be
used against the user. Given the rigor of the l4s spec required, and
how one misbehaving application can screw it all up,  I could see
queue protection of unknown sources that can be squelched on demand
being a desirable "feature". This can be used to stop "unauthorized"
mac addresses from participating in this design as one example.

I like the idea of queue protection - there is a lot of malicious
traffic worth throttling - but without a reporting scheme to the user,
nor a means for the user to set it up, and the mechanism under the
sole control of the ISP - not so much.

My other in-flight entertainment was cory doctorow's latest piece,
which was so good I submitted it to slashdot. (
https://arstechnica.com/gaming/2020/01/unauthorized-bread-a-near-future-tale-of-refugees-and-sinister-iot-appliances/
)


>         They seem to be setting their customers up for a head-on collision with the European Union's net neutrality rules, according to which "special services/fast lanes" are permissible under the condition thay they are realized with completely dedicated addition bandwidth. Just looking at their patent diagram there is one common input path to the classifier. So either that fast lane is not going to be a paid for fast lane, or the ISPs rolling this out will be in hot water with the respective national regulators (at least in the EU). The one chance would be to give the end-user control over the classification engine, or if the strict priority path is only used for ISP originated VoIP traffic (I seem to recall there are weasel words in the EU rules that would allow that and ISPs are doing something like that already, and I agree that it is nice to be able to field an emergency call independent of access link load).

Well, one country at a time. NN is currently quite dead in the USA,
and only a change in regime might change that, and it's unclear if any
of the candiates understand the issues. Certainly with twin subsidies
being aimed at 5G and broadband deployment in pending legislation, I
have no idea what will happen here next. I view 5G with fear, watching
frontier file for bankruptcy, also... I really wish all the fiber
being run for 5G was being run into the home instead.


>
> Best Regards
>         Sebastian
>
>
> >
> > - Jonathan Morton
> > _______________________________________________
> > Ecn-sane mailing list
> > Ecn-sane@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/ecn-sane
>
--
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729

Re: [Ecn-sane] 2019-12-31 docsis strict priority dual queue patent granted

[Dave Taht]

To be deliberately contrarian - (I do try to only pay attention to
this a few days a month) - after also re-reading
https://www.cablelabs.com/technologies/low-latency-docsis and the
associated white papers (yes, 24 hours on a plane can do this to you)

1) I've never been able to figure out where the 99 percentile latency
figure so often cited came from. on the upstream which typically runs
well below 20Mbit, a single IW10 burst at 10Mbit is 1.3ms, so I've
generally figured it was either a long term figure, or calculated from
a much higher (100mbit? 1gbit?) downstream rate against some load
that's never been documented. (that I know of, please note that I
don't
read much of the traffic about this stuff)

2) There is a lot of valuable looking stuff in the lower level aspects
of the docsis LL standard. I'd noted it when I first read it, but
achieving .9ms baseline a/g latency finally does make it competitive
with fiber with whatever the heck "pgm" is. So far as I knew, the
overlapping grant request and estimator functions documented in the
patent are already present in most cablemodems already, and not really
tied to the ll spec... but that data would be interesting to get out
of the modem itself, somehow. The histogram is made available via a
MIB to the operator. It would be nice if those MIBs were also visible
to the user somehow.

3)

In the docsis-ll white paper and spec it lays out cmts requirements
also. With the cmtses currently exhibiting 500+ms of latency at
100Mbit loaded,  from a mere "solving bufferbloat" perspective -
getting just pie there to work would be *marvelous* - it would be
superior to any of the fiber deployments I know of. dualpi, even if
not configured for l4s ecn support, would be a godsend. The ECO for
cablemodems at least, went out over a year ago.

some aqm tech becoming common on these head ends would also spur
deployment of aqm (or fq + aqm) tech on fiber also. But I've seen no
info as to what's going into cmtses today. Haven't seen any
announcements...

I still have no idea what is going to happen on 5G.

My initial experiments with the intel ax200 wifi card have been dismal.

On Fri, Jan 24, 2020 at 12:24 AM Dave Taht <dave.taht@gmail.com> wrote:
>
> Jeeze, you guys are up early. I read this stuff on the plane home from
> australia, and am still a bit under the weather.
>
> On Fri, Jan 24, 2020 at 12:01 AM Sebastian Moeller <moeller0@gmx.de> wrote:
> >
> > Hi Jonathan,
> >
> >
> > > On Jan 24, 2020, at 08:44, Jonathan Morton <chromatix99@gmail.com> wrote:
> > >
> > >> On 24 Jan, 2020, at 7:37 am, Dave Taht <dave.taht@gmail.com> wrote:
> > >>
> > >> "Otherwise, this exemplary embodiment enables system configuration to
> > >> discard the low-priority packet tail, and transmit the high-priority
> > >> packet instead, without waiting."
> > >
> > > So this really *is* a "fast lane" enabling technology.  Just as we suspected.
>
> Well, there are weasel words elsewhere in the patent, and the dualq
> code for linux merely cleared a lane for L4S traffic and hardcoded the
> ect(1) as an identifier. It would be good to have more data on
> rtt-fairness, and on CE reordering of rfc3168 ecn packets.
>
> I spent time dreaming up also all the ways "queue protection" could be
> used against the user. Given the rigor of the l4s spec required, and
> how one misbehaving application can screw it all up,  I could see
> queue protection of unknown sources that can be squelched on demand
> being a desirable "feature". This can be used to stop "unauthorized"
> mac addresses from participating in this design as one example.
>
> I like the idea of queue protection - there is a lot of malicious
> traffic worth throttling - but without a reporting scheme to the user,
> nor a means for the user to set it up, and the mechanism under the
> sole control of the ISP - not so much.
>
> My other in-flight entertainment was cory doctorow's latest piece,
> which was so good I submitted it to slashdot. (
> https://arstechnica.com/gaming/2020/01/unauthorized-bread-a-near-future-tale-of-refugees-and-sinister-iot-appliances/
> )
>
>
> >         They seem to be setting their customers up for a head-on collision with the European Union's net neutrality rules, according to which "special services/fast lanes" are permissible under the condition thay they are realized with completely dedicated addition bandwidth. Just looking at their patent diagram there is one common input path to the classifier. So either that fast lane is not going to be a paid for fast lane, or the ISPs rolling this out will be in hot water with the respective national regulators (at least in the EU). The one chance would be to give the end-user control over the classification engine, or if the strict priority path is only used for ISP originated VoIP traffic (I seem to recall there are weasel words in the EU rules that would allow that and ISPs are doing something like that already, and I agree that it is nice to be able to field an emergency call independent of access link load).
>
> Well, one country at a time. NN is currently quite dead in the USA,
> and only a change in regime might change that, and it's unclear if any
> of the candiates understand the issues. Certainly with twin subsidies
> being aimed at 5G and broadband deployment in pending legislation, I
> have no idea what will happen here next. I view 5G with fear, watching
> frontier file for bankruptcy, also... I really wish all the fiber
> being run for 5G was being run into the home instead.
>
>
> >
> > Best Regards
> >         Sebastian
> >
> >
> > >
> > > - Jonathan Morton
> > > _______________________________________________
> > > Ecn-sane mailing list
> > > Ecn-sane@lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/ecn-sane
> >
> --
> Make Music, Not War
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-435-0729



-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729

Re: [Ecn-sane] 2019-12-31 docsis strict priority dual queue patent granted

[Toke Høiland-Jørgensen]

Dave Taht <dave.taht@gmail.com> writes:

> To be deliberately contrarian - (I do try to only pay attention to
> this a few days a month) - after also re-reading
> https://www.cablelabs.com/technologies/low-latency-docsis and the
> associated white papers (yes, 24 hours on a plane can do this to you)
>
> 1) I've never been able to figure out where the 99 percentile latency
> figure so often cited came from. on the upstream which typically runs
> well below 20Mbit, a single IW10 burst at 10Mbit is 1.3ms, so I've
> generally figured it was either a long term figure, or calculated from
> a much higher (100mbit? 1gbit?) downstream rate against some load
> that's never been documented. (that I know of, please note that I
> don't
> read much of the traffic about this stuff)
>
> 2) There is a lot of valuable looking stuff in the lower level aspects
> of the docsis LL standard. I'd noted it when I first read it, but
> achieving .9ms baseline a/g latency finally does make it competitive
> with fiber with whatever the heck "pgm" is. So far as I knew, the
> overlapping grant request and estimator functions documented in the
> patent are already present in most cablemodems already, and not really
> tied to the ll spec... but that data would be interesting to get out
> of the modem itself, somehow. The histogram is made available via a
> MIB to the operator. It would be nice if those MIBs were also visible
> to the user somehow.
>
> 3)
>
> In the docsis-ll white paper and spec it lays out cmts requirements
> also. With the cmtses currently exhibiting 500+ms of latency at
> 100Mbit loaded,  from a mere "solving bufferbloat" perspective -
> getting just pie there to work would be *marvelous* - it would be
> superior to any of the fiber deployments I know of. dualpi, even if
> not configured for l4s ecn support, would be a godsend. The ECO for
> cablemodems at least, went out over a year ago.
>
> some aqm tech becoming common on these head ends would also spur
> deployment of aqm (or fq + aqm) tech on fiber also. But I've seen no
> info as to what's going into cmtses today. Haven't seen any
> announcements...
>
> I still have no idea what is going to happen on 5G.

I have heard about 5G vendors implementing CoDel on their modems. Maybe
what will end up happening is that all the promises of "low-latency
networking" on 5G will end up being true simply because the vendors
finally fix their bloat? ;)

-Toke

Re: [Ecn-sane] [Bloat] 2019-12-31 docsis strict priority dual queue patent granted

[Dave Taht]

Toke Høiland-Jørgensen <toke@toke.dk> writes:

> Dave Taht <dave.taht@gmail.com> writes:
>
>> To be deliberately contrarian - (I do try to only pay attention to
>> this a few days a month) - after also re-reading
>> https://www.cablelabs.com/technologies/low-latency-docsis and the
>> associated white papers (yes, 24 hours on a plane can do this to
>> you)
>>
>> 1) I've never been able to figure out where the 99 percentile
>> latency
>> figure so often cited came from. on the upstream which typically
>> runs
>> well below 20Mbit, a single IW10 burst at 10Mbit is 1.3ms, so I've
>> generally figured it was either a long term figure, or calculated
>> from
>> a much higher (100mbit? 1gbit?) downstream rate against some load
>> that's never been documented. (that I know of, please note that I
>> don't
>> read much of the traffic about this stuff)
>>
>> 2) There is a lot of valuable looking stuff in the lower level
>> aspects
>> of the docsis LL standard. I'd noted it when I first read it, but
>> achieving .9ms baseline a/g latency finally does make it competitive
>> with fiber with whatever the heck "pgm" is. So far as I knew, the
>> overlapping grant request and estimator functions documented in the
>> patent are already present in most cablemodems already, and not
>> really
>> tied to the ll spec... but that data would be interesting to get out
>> of the modem itself, somehow. The histogram is made available via a
>> MIB to the operator. It would be nice if those MIBs were also
>> visible
>> to the user somehow.
>>
>> 3)
>>
>> In the docsis-ll white paper and spec it lays out cmts requirements
>> also. With the cmtses currently exhibiting 500+ms of latency at
>> 100Mbit loaded, from a mere "solving bufferbloat" perspective -
>> getting just pie there to work would be *marvelous* - it would be
>> superior to any of the fiber deployments I know of. dualpi, even if
>> not configured for l4s ecn support, would be a godsend. The ECO for
>> cablemodems at least, went out over a year ago.
>>
>> some aqm tech becoming common on these head ends would also spur
>> deployment of aqm (or fq + aqm) tech on fiber also. But I've seen no
>> info as to what's going into cmtses today. Haven't seen any
>> announcements...
>>
>> I still have no idea what is going to happen on 5G.
>
> I have heard about 5G vendors implementing CoDel on their
> modems.

That's the best news I've heard all year.

> Maybe
> what will end up happening is that all the promises of "low-latency
> networking" on 5G will end up being true simply because the vendors
> finally fix their bloat? ;)

One can hope. I must admit that I still think fiber to the home is a
way better idea than fiber to the pole, and I'd really like delegated
/60 at the very least, regularly available, over (X)G. I tether a lot
these days and don't have ipv6 on my tether at all...

>
> -Toke
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Ecn-sane] 2019-12-31 docsis strict priority dual queue patent granted

[Sebastian Moeller]

Hi Dave,


> On Jan 24, 2020, at 09:59, Dave Taht <dave.taht@gmail.com> wrote:
> 
> To be deliberately contrarian - (I do try to only pay attention to
> this a few days a month) - after also re-reading
> https://www.cablelabs.com/technologies/low-latency-docsis and the
> associated white papers (yes, 24 hours on a plane can do this to you)
> 
> 1) I've never been able to figure out where the 99 percentile latency
> figure so often cited came from. on the upstream which typically runs
> well below 20Mbit, a single IW10 burst at 10Mbit is 1.3ms, so I've
> generally figured it was either a long term figure, or calculated from
> a much higher (100mbit? 1gbit?) downstream rate against some load
> that's never been documented. (that I know of, please note that I
> don't
> read much of the traffic about this stuff)

	Thinn air and/or tests with DCTCP, probably (or paced fixed-rate flows)?


> 
> 2) There is a lot of valuable looking stuff in the lower level aspects
> of the docsis LL standard.

	I agree, they propose a nice mid-life MAC do-over, but I am not sure whether ISPs/Manufacturers will follow as IIRC some of that stuff is either not mandatory to implement and/or to activate.


> I'd noted it when I first read it, but
> achieving .9ms baseline a/g latency finally does make it competitive
> with fiber with whatever the heck "pgm" is. So far as I knew, the
> overlapping grant request and estimator functions

	I initially thought that is going to be tricky, but realistically if there is traffic on a link (immediate) history probably is a decent predictor of (immediate) future traffic need, so a bit of temporal prediction can go a long way there to lessen the impact of the grant request cycle on average latency (one could even think about not only tracking past traffic speed but also acceleration). 


> documented in the
> patent are already present in most cablemodems already, and not really
> tied to the ll spec... but that data would be interesting to get out
> of the modem itself, somehow. The histogram is made available via a
> MIB to the operator. It would be nice if those MIBs were also visible
> to the user somehow.
> 
> 3)
> 
> In the docsis-ll white paper and spec it lays out cmts requirements
> also. With the cmtses currently exhibiting 500+ms of latency at
> 100Mbit loaded,  from a mere "solving bufferbloat" perspective -
> getting just pie there to work would be *marvelous* - it would be
> superior to any of the fiber deployments I know of. dualpi, even if
> not configured for l4s ecn support,

	Well, especially if not configured for l4s ECN, as dualpi is misdesigned in giving the L4S queue dominance over the non-L4S queue... Ironic giving all the prose about dualpi not being a priority based AQM (and driven by the IMHO faulty assumption that rate and delay are fully orthogonal). And that failure to do the one job it was designed for has been documented (or shall I say buried) in the L4S measurement papers since early on, and yet no-one bothered to actually go fix this. 
	But to your point, sure, if used as a single queue AQM it will give us a PIE variant with a reference delay of 15ms (which according to theory should be good up to a RTT of ~300ms) at the head-end, a significant improvement on the status quo, albeit only for docsis users..


> would be a godsend. The ECO for
> cablemodems at least, went out over a year ago.
> 
> some aqm tech becoming common on these head ends would also spur
> deployment of aqm (or fq + aqm) tech on fiber also. But I've seen no
> info as to what's going into cmtses today. Haven't seen any
> announcements...
> 
> I still have no idea what is going to happen on 5G.
> 
> My initial experiments with the intel ax200 wifi card have been dismal.
> 
> On Fri, Jan 24, 2020 at 12:24 AM Dave Taht <dave.taht@gmail.com> wrote:
>> 
>> Jeeze, you guys are up early. I read this stuff on the plane home from
>> australia, and am still a bit under the weather.
>> 
>> On Fri, Jan 24, 2020 at 12:01 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>>> 
>>> Hi Jonathan,
>>> 
>>> 
>>>> On Jan 24, 2020, at 08:44, Jonathan Morton <chromatix99@gmail.com> wrote:
>>>> 
>>>>> On 24 Jan, 2020, at 7:37 am, Dave Taht <dave.taht@gmail.com> wrote:
>>>>> 
>>>>> "Otherwise, this exemplary embodiment enables system configuration to
>>>>> discard the low-priority packet tail, and transmit the high-priority
>>>>> packet instead, without waiting."
>>>> 
>>>> So this really *is* a "fast lane" enabling technology.  Just as we suspected.
>> 
>> Well, there are weasel words elsewhere in the patent, and the dualq
>> code for linux merely cleared a lane for L4S traffic and hardcoded the
>> ect(1) as an identifier. It would be good to have more data on
>> rtt-fairness, and on CE reordering of rfc3168 ecn packets.
>> 
>> I spent time dreaming up also all the ways "queue protection" could be
>> used against the user. Given the rigor of the l4s spec required, and
>> how one misbehaving application can screw it all up,  I could see
>> queue protection of unknown sources that can be squelched on demand
>> being a desirable "feature". This can be used to stop "unauthorized"
>> mac addresses from participating in this design as one example.
>> 
>> I like the idea of queue protection - there is a lot of malicious
>> traffic worth throttling - but without a reporting scheme to the user,
>> nor a means for the user to set it up, and the mechanism under the
>> sole control of the ISP - not so much.
>> 
>> My other in-flight entertainment was cory doctorow's latest piece,
>> which was so good I submitted it to slashdot. (
>> https://arstechnica.com/gaming/2020/01/unauthorized-bread-a-near-future-tale-of-refugees-and-sinister-iot-appliances/
>> )
>> 
>> 
>>>        They seem to be setting their customers up for a head-on collision with the European Union's net neutrality rules, according to which "special services/fast lanes" are permissible under the condition thay they are realized with completely dedicated addition bandwidth. Just looking at their patent diagram there is one common input path to the classifier. So either that fast lane is not going to be a paid for fast lane, or the ISPs rolling this out will be in hot water with the respective national regulators (at least in the EU). The one chance would be to give the end-user control over the classification engine, or if the strict priority path is only used for ISP originated VoIP traffic (I seem to recall there are weasel words in the EU rules that would allow that and ISPs are doing something like that already, and I agree that it is nice to be able to field an emergency call independent of access link load).
>> 
>> Well, one country at a time. NN is currently quite dead in the USA,
>> and only a change in regime might change that, and it's unclear if any
>> of the candiates understand the issues. Certainly with twin subsidies
>> being aimed at 5G and broadband deployment in pending legislation, I
>> have no idea what will happen here next. I view 5G with fear, watching
>> frontier file for bankruptcy, also... I really wish all the fiber
>> being run for 5G was being run into the home instead.
>> 
>> 
>>> 
>>> Best Regards
>>>        Sebastian
>>> 
>>> 
>>>> 
>>>> - Jonathan Morton
>>>> _______________________________________________
>>>> Ecn-sane mailing list
>>>> Ecn-sane@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/ecn-sane
>>> 
>> --
>> Make Music, Not War
>> 
>> Dave Täht
>> CTO, TekLibre, LLC
>> http://www.teklibre.com
>> Tel: 1-831-435-0729
> 
> 
> 
> -- 
> Make Music, Not War
> 
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-435-0729

Re: [Ecn-sane] [Bloat] 2019-12-31 docsis strict priority dual queue patent granted

[Dave Taht]

Sebastian Moeller <moeller0@gmx.de> writes:

> Hi Dave,
>
>
>> On Jan 24, 2020, at 09:59, Dave Taht <dave.taht@gmail.com> wrote:
>> 
>> To be deliberately contrarian - (I do try to only pay attention to
>> this a few days a month) - after also re-reading
>> https://www.cablelabs.com/technologies/low-latency-docsis and the
>> associated white papers (yes, 24 hours on a plane can do this to
>> you)
>> 
>> 1) I've never been able to figure out where the 99 percentile
>> latency
>> figure so often cited came from. on the upstream which typically
>> runs
>> well below 20Mbit, a single IW10 burst at 10Mbit is 1.3ms, so I've
>> generally figured it was either a long term figure, or calculated
>> from
>> a much higher (100mbit? 1gbit?) downstream rate against some load
>> that's never been documented. (that I know of, please note that I
>> don't
>> read much of the traffic about this stuff)
>
> 	Thinn air and/or tests with DCTCP, probably (or paced
> fixed-rate flows)?

Well, I really would like a repeatable benchmark to address this
particular claim.

>
>
>> 
>> 2) There is a lot of valuable looking stuff in the lower level
>> aspects
>> of the docsis LL standard.
>
> 	I agree, they propose a nice mid-life MAC do-over, but I am
> not sure whether ISPs/Manufacturers will follow as IIRC some of that
> stuff is either not mandatory to implement and/or to activate.

In markets where docsis is competing with fiber, I would suspect folk
might try.

>
>> I'd noted it when I first read it, but
>> achieving .9ms baseline a/g latency finally does make it competitive
>> with fiber with whatever the heck "pgm" is. So far as I knew, the
>> overlapping grant request and estimator functions
>
> 	I initially thought that is going to be tricky, but
> realistically if there is traffic on a link (immediate) history
> probably is a decent predictor of (immediate) future traffic need, so
> a bit of temporal prediction can go a long way there to lessen the
> impact of the grant request cycle on average latency (one could even
> think about not only tracking past traffic speed but also
> acceleration).

Sure. The part that I don't really get is how often actual contention
for grants happens in docsis today. It's one thing to request a grant,
even one that is speculative, but as in wifi - actually getting one
strikes me as increasingly hard. Asking for a grant when you end up
needing it not, hmm.

>
>
>> documented in the
>> patent are already present in most cablemodems already, and not
>> really
>> tied to the ll spec... but that data would be interesting to get out
>> of the modem itself, somehow. The histogram is made available via a
>> MIB to the operator. It would be nice if those MIBs were also
>> visible
>> to the user somehow.
>> 
>> 3)
>> 
>> In the docsis-ll white paper and spec it lays out cmts requirements
>> also. With the cmtses currently exhibiting 500+ms of latency at
>> 100Mbit loaded, from a mere "solving bufferbloat" perspective -
>> getting just pie there to work would be *marvelous* - it would be
>> superior to any of the fiber deployments I know of. dualpi, even if
>> not configured for l4s ecn support,
>
> 	Well, especially if not configured for l4s ECN, as dualpi is
> misdesigned in giving the L4S queue dominance over the non-L4S
> queue... Ironic giving all the prose about dualpi not being a priority
> based AQM (and driven by the IMHO faulty assumption that rate and
> delay are fully orthogonal). And that failure to do the one job it was
> designed for has been documented (or shall I say buried) in the L4S
> measurement papers since early on, and yet no-one bothered to actually
> go fix this.

RTT unfairness seems to be a highly desirable feature for the
vertically oriented ISP. Convincing anybody else using the internet
for real traffic to multiple destinations that this is a "good thing"
seems to be an increasingly difficult uphill slog thanks to your work
and the work of others appearing. 

> 	But to your point, sure, if used as a single queue AQM it will
> give us a PIE variant with a reference delay of 15ms (which according
> to theory should be good up to a RTT of ~300ms) at the head-end, a
> significant improvement on the status quo, albeit only for docsis
> users..


I'm happy to see postive movement on the uploads. I have a slide from
2017 somewhere that I should probably animate into this plot. (anybody
else have screenshots of this over time?)

http://www.dslreports.com/speedtest/results/bufferbloat?up=1

There used to be a group of docsis 3.0 modems that is now nearly gone from the
statistics now here.

While the dslreports dataset is polluted by folk actively fixing their
bufferbloat, the tremendous improvement in docsis upstream latency
observed since 2017 probably comes down to 4 factors - doubling or more
the upstream bandwidth while holding buffersizes constant, ISPs also
cutting the buffersizes down, and the docsis-pie deployment, and sqm. As
to which of those factors was the greatest... not a clue!

There's been very little movement in the dsl world, in comparison, and
seeing a range of fiber nodes at 100mbit on the wrong side of the black
line is worrisome.

I have less screen caps of this.

http://www.dslreports.com/speedtest/results/bufferbloat

>
>
>> would be a godsend. The ECO for
>> cablemodems at least, went out over a year ago.
>> 
>> some aqm tech becoming common on these head ends would also spur
>> deployment of aqm (or fq + aqm) tech on fiber also. But I've seen no
>> info as to what's going into cmtses today. Haven't seen any
>> announcements...
>> 
>> I still have no idea what is going to happen on 5G.
>> 
>> My initial experiments with the intel ax200 wifi card have been
>> dismal.
>> 
>> On Fri, Jan 24, 2020 at 12:24 AM Dave Taht <dave.taht@gmail.com>
>> wrote:
>>> 
>>> Jeeze, you guys are up early. I read this stuff on the plane home
>>> from
>>> australia, and am still a bit under the weather.
>>> 
>>> On Fri, Jan 24, 2020 at 12:01 AM Sebastian Moeller
>>> <moeller0@gmx.de> wrote:
>>>> 
>>>> Hi Jonathan,
>>>> 
>>>> 
>>>>> On Jan 24, 2020, at 08:44, Jonathan Morton
>>>>> <chromatix99@gmail.com> wrote:
>>>>> 
>>>>>> On 24 Jan, 2020, at 7:37 am, Dave Taht <dave.taht@gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>> "Otherwise, this exemplary embodiment enables system
>>>>>> configuration to
>>>>>> discard the low-priority packet tail, and transmit the
>>>>>> high-priority
>>>>>> packet instead, without waiting."
>>>>> 
>>>>> So this really *is* a "fast lane" enabling technology.  Just as
>>>>> we suspected.
>>> 
>>> Well, there are weasel words elsewhere in the patent, and the dualq
>>> code for linux merely cleared a lane for L4S traffic and hardcoded
>>> the
>>> ect(1) as an identifier. It would be good to have more data on
>>> rtt-fairness, and on CE reordering of rfc3168 ecn packets.
>>> 
>>> I spent time dreaming up also all the ways "queue protection" could
>>> be
>>> used against the user. Given the rigor of the l4s spec required,
>>> and
>>> how one misbehaving application can screw it all up, I could see
>>> queue protection of unknown sources that can be squelched on demand
>>> being a desirable "feature". This can be used to stop
>>> "unauthorized"
>>> mac addresses from participating in this design as one example.
>>> 
>>> I like the idea of queue protection - there is a lot of malicious
>>> traffic worth throttling - but without a reporting scheme to the
>>> user,
>>> nor a means for the user to set it up, and the mechanism under the
>>> sole control of the ISP - not so much.
>>> 
>>> My other in-flight entertainment was cory doctorow's latest piece,
>>> which was so good I submitted it to slashdot. (
>>> https://arstechnica.com/gaming/2020/01/unauthorized-bread-a-near-future-tale-of-refugees-and-sinister-iot-appliances/
>>> )
>>> 
>>> 
>>>>        They seem to be setting their customers up for a head-on
>>>> collision with the European Union's net neutrality rules,
>>>> according to which "special services/fast lanes" are permissible
>>>> under the condition thay they are realized with completely
>>>> dedicated addition bandwidth. Just looking at their patent diagram
>>>> there is one common input path to the classifier. So either that
>>>> fast lane is not going to be a paid for fast lane, or the ISPs
>>>> rolling this out will be in hot water with the respective national
>>>> regulators (at least in the EU). The one chance would be to give
>>>> the end-user control over the classification engine, or if the
>>>> strict priority path is only used for ISP originated VoIP traffic
>>>> (I seem to recall there are weasel words in the EU rules that
>>>> would allow that and ISPs are doing something like that already,
>>>> and I agree that it is nice to be able to field an emergency call
>>>> independent of access link load).
>>> 
>>> Well, one country at a time. NN is currently quite dead in the USA,
>>> and only a change in regime might change that, and it's unclear if
>>> any
>>> of the candiates understand the issues. Certainly with twin
>>> subsidies
>>> being aimed at 5G and broadband deployment in pending legislation,
>>> I
>>> have no idea what will happen here next. I view 5G with fear,
>>> watching
>>> frontier file for bankruptcy, also... I really wish all the fiber
>>> being run for 5G was being run into the home instead.
>>> 
>>> 
>>>> 
>>>> Best Regards
>>>>        Sebastian
>>>> 
>>>> 
>>>>> 
>>>>> - Jonathan Morton
>>>>> _______________________________________________
>>>>> Ecn-sane mailing list
>>>>> Ecn-sane@lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/ecn-sane
>>>> 
>>> --
>>> Make Music, Not War
>>> 
>>> Dave Täht
>>> CTO, TekLibre, LLC
>>> http://www.teklibre.com
>>> Tel: 1-831-435-0729
>> 
>> 
>> 
>> -- 
>> Make Music, Not War
>> 
>> Dave Täht
>> CTO, TekLibre, LLC
>> http://www.teklibre.com
>> Tel: 1-831-435-0729
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat