[Ecn-sane] l4s kernel submission

[Ecn-sane] l4s kernel submission

[Dave Taht]

https://lore.kernel.org/all/20211014175918.60188-3-eric.dumazet@gmail.com/

-- 
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw

Dave Täht CEO, TekLibre, LLC

Re: [Ecn-sane] [Cake] l4s kernel submission

[Sebastian Moeller]

Which does not change the inconvenient fact that L4S does not work over the open internet. But I bet that fq_codel with a shaper is going to be hands down the better L4S AQM compared to DualQ... (thanks to its fq nature it can forego the whole "coupling" heuristic mess and side-step the whole massive unfairness issues, and keeping the known working codel law for non-ECT(1) traffic also compared to dualq's burts intolerabt PIE variant also seems like a step in the right direction).
Then again it seems consequent given that the BBRv2 team seem to be on-board the L4S train; to put a somewhat positive spin (lipstick?) on this, I assume that the quality of the L4S engineering might improve... 

Regards
	Sebastian

P.S.: Witnessing the L4S drama in the IETF makes me appreciate how comparatively clean and elegant sausages are made...



> On Oct 14, 2021, at 22:06, Dave Taht <dave.taht@gmail.com> wrote:
> 
> https://lore.kernel.org/all/20211014175918.60188-3-eric.dumazet@gmail.com/
> 
> -- 
> Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw
> 
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Ecn-sane] [Cake] l4s kernel submission

[Dave Taht]

weirdly enough, my gmail account has not received anything from netdev
since oct 11.

yes, i think fq_codel will be better, and even the proposed
too-shallow threshold will make for less of a dent on the internet.

still... I do wish I'd seen this earlier.

On Thu, Oct 14, 2021 at 1:31 PM Sebastian Moeller <moeller0@gmx.de> wrote:
>
> Which does not change the inconvenient fact that L4S does not work over the open internet. But I bet that fq_codel with a shaper is going to be hands down the better L4S AQM compared to DualQ... (thanks to its fq nature it can forego the whole "coupling" heuristic mess and side-step the whole massive unfairness issues, and keeping the known working codel law for non-ECT(1) traffic also compared to dualq's burts intolerabt PIE variant also seems like a step in the right direction).
> Then again it seems consequent given that the BBRv2 team seem to be on-board the L4S train; to put a somewhat positive spin (lipstick?) on this, I assume that the quality of the L4S engineering might improve...
>
> Regards
>         Sebastian
>
> P.S.: Witnessing the L4S drama in the IETF makes me appreciate how comparatively clean and elegant sausages are made...
>
>
>
> > On Oct 14, 2021, at 22:06, Dave Taht <dave.taht@gmail.com> wrote:
> >
> > https://lore.kernel.org/all/20211014175918.60188-3-eric.dumazet@gmail.com/
> >
> > --
> > Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw
> >
> > Dave Täht CEO, TekLibre, LLC
> > _______________________________________________
> > Cake mailing list
> > Cake@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cake
>


-- 
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw

Dave Täht CEO, TekLibre, LLC

Re: [Ecn-sane] [Cake] l4s kernel submission

[Toke Høiland-Jørgensen]

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

> weirdly enough, my gmail account has not received anything from netdev
> since oct 11.

You're not alone in that:
https://lore.kernel.org/netdev/20211014112718.6aed7f47@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com/T/#t

> yes, i think fq_codel will be better, and even the proposed
> too-shallow threshold will make for less of a dent on the internet.
>
> still... I do wish I'd seen this earlier.

Earlier? You forwarded the patch hours after it was posted...

-Toke

Re: [Ecn-sane] [Cake] l4s kernel submission

[Dave Taht]

On Thu, Oct 14, 2021 at 2:44 PM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> Dave Taht <dave.taht@gmail.com> writes:
>
> > weirdly enough, my gmail account has not received anything from netdev
> > since oct 11.
>
> You're not alone in that:
> https://lore.kernel.org/netdev/20211014112718.6aed7f47@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com/T/#t

ok. One of these years I'll go back to running my own email server full time.

> > yes, i think fq_codel will be better, and even the proposed
> > too-shallow threshold will make for less of a dent on the internet.
> >
> > still... I do wish I'd seen this earlier.
>
> Earlier? You forwarded the patch hours after it was posted...

I have a daily search for fq_codel, bufferbloat, etc. I have noticed
lately that some mailing list traffic from us is being indexed again.
I wish I knew why our lists were not indexed by google.

Anyway, lacking being on that thread, it's currently impossible to
reply. I would certainly like more to be exploring HFCC - I do agree
that a shallow marking threshold is increasingly necessary at rates
beyond 10Gbit, and that more would read -
https://github.com/heistp/l4s-tests#key-findings before the internet
is split into a fast and slow lane.

That said, the l4s fq_codel patch is intrinsically fair, which is
vastly superior to the dualpi approach.

I think that the over-shallow proposed threshold of 50us - the lowest
I'd seen to date was 250us! won't work on anything other than bare
iron or from a self-local qdisc, and that will lead to the
implementation being naturally slow rate on virtualized hosts, but
lossless, which would be
a win, and for all I know interact well with the fast/slow queue concept.

I certainly think bbrv2 needs more testing, as it has always seemed to
be a more promising approach than prague.

My biggest feedback on the patch so far is I dislike the overload on
reporting where the CE came from, and would prefer that l4s_ce be
exposed to userspace. We have very little data on actual ce's in the
field as it is - conflating the two statistics won't help -

I also hate adding anything more to the hot path. And if we have to do
it, making sce available as an optional at the same time has the same
computational cost.

And it still bugs me, very much, that bbrv1 has no rfc3168-like response.

Perhaps with some time to work on a coherent reply to this patch and
figuring out how to get back on netdev,
I can say all that better. Or I can just go back to fixing up my boat.

>
> -Toke



-- 
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw

Dave Täht CEO, TekLibre, LLC

Re: [Ecn-sane] [Cake] l4s kernel submission

[Toke Høiland-Jørgensen]

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

> On Thu, Oct 14, 2021 at 2:44 PM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>
>> Dave Taht <dave.taht@gmail.com> writes:
>>
>> > weirdly enough, my gmail account has not received anything from netdev
>> > since oct 11.
>>
>> You're not alone in that:
>> https://lore.kernel.org/netdev/20211014112718.6aed7f47@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com/T/#t
>
> ok. One of these years I'll go back to running my own email server
> full time.

You can also subscribe to Linux lists by importing the mails from Lore,
as one of the replies in the thread above pointed out. Been meaning to
switch to that myself, but haven't gotten around to it yet...

>> > yes, i think fq_codel will be better, and even the proposed
>> > too-shallow threshold will make for less of a dent on the internet.
>> >
>> > still... I do wish I'd seen this earlier.
>>
>> Earlier? You forwarded the patch hours after it was posted...
>
> I have a daily search for fq_codel, bufferbloat, etc. I have noticed
> lately that some mailing list traffic from us is being indexed again.
> I wish I knew why our lists were not indexed by google.
>
> Anyway, lacking being on that thread, it's currently impossible to
> reply.

The Lore page contains instructions for various ways of replying even
without having the original email message in your mailbox. It's at the
bottom... 

> That said, the l4s fq_codel patch is intrinsically fair, which is
> vastly superior to the dualpi approach.

Yup, I agree it's better, but I don't like baking in the ECT(1)
semantics to UAPI. I suggested a filter-based approach which I'm
currently discussing with Eric on that thread as you might have noticed :)

-Toke

Re: [Ecn-sane] [Cake] l4s kernel submission

[Dave Taht]

On Thu, Oct 14, 2021 at 3:10 PM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> Dave Taht <dave.taht@gmail.com> writes:
>
> > On Thu, Oct 14, 2021 at 2:44 PM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> >>
> >> Dave Taht <dave.taht@gmail.com> writes:
> >>
> >> > weirdly enough, my gmail account has not received anything from netdev
> >> > since oct 11.
> >>
> >> You're not alone in that:
> >> https://lore.kernel.org/netdev/20211014112718.6aed7f47@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com/T/#t
> >
> > ok. One of these years I'll go back to running my own email server
> > full time.
>
> You can also subscribe to Linux lists by importing the mails from Lore,
> as one of the replies in the thread above pointed out. Been meaning to
> switch to that myself, but haven't gotten around to it yet...

I attempted to subscribe again, nothing happened.

figuring out lore... is too much work for today. I'd rather hammer
small things into oblivion on my boat.

please feel free to pass along my comments and the sce teams findings
into that thread.

>
> >> > yes, i think fq_codel will be better, and even the proposed
> >> > too-shallow threshold will make for less of a dent on the internet.
> >> >
> >> > still... I do wish I'd seen this earlier.
> >>
> >> Earlier? You forwarded the patch hours after it was posted...
> >
> > I have a daily search for fq_codel, bufferbloat, etc. I have noticed
> > lately that some mailing list traffic from us is being indexed again.
> > I wish I knew why our lists were not indexed by google.
> >
> > Anyway, lacking being on that thread, it's currently impossible to
> > reply.
>
> The Lore page contains instructions for various ways of replying even
> without having the original email message in your mailbox. It's at the
> bottom...
>
> > That said, the l4s fq_codel patch is intrinsically fair, which is
> > vastly superior to the dualpi approach.
>
> Yup, I agree it's better, but I don't like baking in the ECT(1)
> semantics to UAPI. I suggested a filter-based approach which I'm
> currently discussing with Eric on that thread as you might have noticed :)
>
> -Toke



-- 
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw

Dave Täht CEO, TekLibre, LLC

Re: [Ecn-sane] [Cake] l4s kernel submission

[Jonathan Morton]

> On 15 Oct, 2021, at 1:17 am, Dave Taht <dave.taht@gmail.com> wrote:
> 
>> You can also subscribe to Linux lists by importing the mails from Lore,
>> as one of the replies in the thread above pointed out. Been meaning to
>> switch to that myself, but haven't gotten around to it yet...
> 
> I attempted to subscribe again, nothing happened.
> 
> figuring out lore... is too much work for today. I'd rather hammer
> small things into oblivion on my boat.
> 
> please feel free to pass along my comments and the sce teams findings
> into that thread.

https://lore.kernel.org/all/308C88C6-D465-4D50-8038-416119A3535C@gmail.com/

I haven't yet posted a link to the WGLC Objections document.  I will if it seem s necessary to do so.

 - Jonathan Morton

Re: [Ecn-sane] [Cake] l4s kernel submission

[Sebastian Moeller]

Hi Jonathan,


> On Oct 16, 2021, at 10:04, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
>> On 15 Oct, 2021, at 1:17 am, Dave Taht <dave.taht@gmail.com> wrote:
>> 
>>> You can also subscribe to Linux lists by importing the mails from Lore,
>>> as one of the replies in the thread above pointed out. Been meaning to
>>> switch to that myself, but haven't gotten around to it yet...
>> 
>> I attempted to subscribe again, nothing happened.
>> 
>> figuring out lore... is too much work for today. I'd rather hammer
>> small things into oblivion on my boat.
>> 
>> please feel free to pass along my comments and the sce teams findings
>> into that thread.
> 
> https://lore.kernel.org/all/308C88C6-D465-4D50-8038-416119A3535C@gmail.com/
> 
> I haven't yet posted a link to the WGLC Objections document.  I will if it seem s necessary to do so.

	I think that might help, but I also think that some one subscribed should weight in on the exempt one packet from marking, especially in the light of GRO/GSO. I would but a) I am not subscribed and b) tend to get too aggressive in discussions with Bob, not helping to make my points.

Regards
	Sebastian


> 
> - Jonathan Morton
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Ecn-sane] [Cake] l4s kernel submission

[Jonathan Morton]

> On 16 Oct, 2021, at 11:38 am, Sebastian Moeller <moeller0@gmx.de> wrote:
> 
> I also think that some one subscribed should weight in on the exempt one packet from marking, especially in the light of GRO/GSO.

I do have some experience with this from Cake, but Cake has the distinct benefit of (usually) knowing what the dequeue rate is, without having to estimate it.  Without that knowledge, I'm not sure it's profitable to guess - except to specifically avoid tail *loss*, which is not at all the same as *marking* the last packet.

 - Jonathan Morton

Re: [Ecn-sane] [Cake] l4s kernel submission

[Sebastian Moeller]

> On Oct 16, 2021, at 10:54, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
>> On 16 Oct, 2021, at 11:38 am, Sebastian Moeller <moeller0@gmx.de> wrote:
>> 
>> I also think that some one subscribed should weight in on the exempt one packet from marking, especially in the light of GRO/GSO.
> 
> I do have some experience with this from Cake, but Cake has the distinct benefit of (usually) knowing what the dequeue rate is, without having to estimate it.  Without that knowledge, I'm not sure it's profitable to guess - except to specifically avoid tail *loss*, which is not at all the same as *marking* the last packet.
> 
> - Jonathan Morton

Yes, in SQM/cake we opted for making the target >= 1.5 times the transmission time of a full sized packet, I think that is the correct solution for slow links, but if one goes the exempt one packet from marking this requires GSO-splitting at least n slow links, no?

Regards
	Sebastian

Re: [Ecn-sane] [Cake] l4s kernel submission

[Sebastian Moeller]

Hi Jonathan,


> On Oct 16, 2021, at 10:54, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
>> On 16 Oct, 2021, at 11:38 am, Sebastian Moeller <moeller0@gmx.de> wrote:
>> 
>> I also think that some one subscribed should weight in on the exempt one packet from marking, especially in the light of GRO/GSO.
> 
> I do have some experience with this from Cake, but Cake has the distinct benefit of (usually) knowing what the dequeue rate is, without having to estimate it.  Without that knowledge, I'm not sure it's profitable to guess - except to specifically avoid tail *loss*, which is not at all the same as *marking* the last packet.

	Thinking it over, Bob's recommended special casing one packet will be essentially equivalent to increasing the marking target, except for the case of small packets, where you might see/desire marking before the equivalent sojourn time of a full MTU packet is accumulated. My hunch is that is really rare, and the whole exercise will just lead to artificially and non-functionally low marking threshold...  

Regards
	Sebastian


> 
> - Jonathan Morton

Re: [Ecn-sane] [Cake] l4s kernel submission

[Rodney W. Grimes]

Jonathan, etc,

I went fishing down the rabbit hole and think I see
how the masses have been brainwashed about L4S, at
least partially.  It might be worth spending some
effort to "debunk" the claims in the paper:
	https://bobbriscoe.net/projects/latency/dctth_journal_draft20190726.pdf

I am EXTREAMLY concerned about the following miss leading
assertions by the authors:
	"
BEGIN-QUOTE
V.  DEPLOYMENTCONSIDERATIONS
  A.  Standardization Requirements
    The IETF has taken on L4S standardization work [13]. [19]
    considers the pros and cons of various candidate identifiers for
    L4S  and  finds  that  none  are  without  problems,  but  proposes
    ECT(1)  as  the  least  worst.  As  a  consequence,  the  IETF  has
    updated the ECN standard at the IP layer (v4 and v6) to make
    the ECT(1) codepoint available for experimentation [7].

 [7]   BLACK, D.   Relaxing  Restrictions  on  Explicit  Congestion  Notification
      (ECN) Experimentation.  Request for Comments RFC8311, RFC Editor,Jan. 2018
END-QUOTE


My problem with this "claim" is that it is made in the name of
the IETF, which is not true.  Bob Briscoe and others are who
are making these claims, the IETF has NOT yet spoken formally
on L4S.

Though RFC8311 DOES relax the restrictions, Bob etc al, make it
sound as if L4S is a done deal.

Regards,
Rod

> > On 15 Oct, 2021, at 1:17 am, Dave Taht <dave.taht@gmail.com> wrote:
> > 
> >> You can also subscribe to Linux lists by importing the mails from Lore,
> >> as one of the replies in the thread above pointed out. Been meaning to
> >> switch to that myself, but haven't gotten around to it yet...
> > 
> > I attempted to subscribe again, nothing happened.
> > 
> > figuring out lore... is too much work for today. I'd rather hammer
> > small things into oblivion on my boat.
> > 
> > please feel free to pass along my comments and the sce teams findings
> > into that thread.
> 
> https://lore.kernel.org/all/308C88C6-D465-4D50-8038-416119A3535C@gmail.com/
> 
> I haven't yet posted a link to the WGLC Objections document.  I will if it seem s necessary to do so.
> 
>  - Jonathan Morton
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane
> 
> 

-- 
Rod Grimes                                                 rgrimes@freebsd.org

Re: [Ecn-sane] [Cake] l4s kernel submission

[Dave Taht]

An open question for me:

What happens when a GSO packet is marked? Do all the packets get the
marking, or just the first?

On Thu, Oct 14, 2021 at 3:17 PM Dave Taht <dave.taht@gmail.com> wrote:
>
> On Thu, Oct 14, 2021 at 3:10 PM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> >
> > Dave Taht <dave.taht@gmail.com> writes:
> >
> > > On Thu, Oct 14, 2021 at 2:44 PM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> > >>
> > >> Dave Taht <dave.taht@gmail.com> writes:
> > >>
> > >> > weirdly enough, my gmail account has not received anything from netdev
> > >> > since oct 11.
> > >>
> > >> You're not alone in that:
> > >> https://lore.kernel.org/netdev/20211014112718.6aed7f47@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com/T/#t
> > >
> > > ok. One of these years I'll go back to running my own email server
> > > full time.
> >
> > You can also subscribe to Linux lists by importing the mails from Lore,
> > as one of the replies in the thread above pointed out. Been meaning to
> > switch to that myself, but haven't gotten around to it yet...
>
> I attempted to subscribe again, nothing happened.
>
> figuring out lore... is too much work for today. I'd rather hammer
> small things into oblivion on my boat.
>
> please feel free to pass along my comments and the sce teams findings
> into that thread.
>
> >
> > >> > yes, i think fq_codel will be better, and even the proposed
> > >> > too-shallow threshold will make for less of a dent on the internet.
> > >> >
> > >> > still... I do wish I'd seen this earlier.
> > >>
> > >> Earlier? You forwarded the patch hours after it was posted...
> > >
> > > I have a daily search for fq_codel, bufferbloat, etc. I have noticed
> > > lately that some mailing list traffic from us is being indexed again.
> > > I wish I knew why our lists were not indexed by google.
> > >
> > > Anyway, lacking being on that thread, it's currently impossible to
> > > reply.
> >
> > The Lore page contains instructions for various ways of replying even
> > without having the original email message in your mailbox. It's at the
> > bottom...
> >
> > > That said, the l4s fq_codel patch is intrinsically fair, which is
> > > vastly superior to the dualpi approach.
> >
> > Yup, I agree it's better, but I don't like baking in the ECT(1)
> > semantics to UAPI. I suggested a filter-based approach which I'm
> > currently discussing with Eric on that thread as you might have noticed :)
> >
> > -Toke
>
>
>
> --
> Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw
>
> Dave Täht CEO, TekLibre, LLC



-- 
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw

Dave Täht CEO, TekLibre, LLC

Re: [Ecn-sane] [Cake] l4s kernel submission

[Toke Høiland-Jørgensen]

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

> An open question for me:
>
> What happens when a GSO packet is marked? Do all the packets get the
> marking, or just the first?

When segmenting a GSO packet, the IP header is copied to all segments.
The code has grown quite complex over the years, but it's easier to see
in the original submission from 2006:

https://lore.kernel.org/all/20060622081400.GC22671@gondor.apana.org.au/

Which means all packets in a GSO segment will end up marked on the
wire...

-Toke

Re: [Ecn-sane] [Cake] l4s kernel submission

[Dave Taht]

my more specific question was gro. On gro assembly is the dscp/ecn
header examined?

On Mon, Oct 18, 2021 at 6:02 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> Dave Taht <dave.taht@gmail.com> writes:
>
> > An open question for me:
> >
> > What happens when a GSO packet is marked? Do all the packets get the
> > marking, or just the first?
>
> When segmenting a GSO packet, the IP header is copied to all segments.
> The code has grown quite complex over the years, but it's easier to see
> in the original submission from 2006:
>
> https://lore.kernel.org/all/20060622081400.GC22671@gondor.apana.org.au/
>
> Which means all packets in a GSO segment will end up marked on the
> wire...
>
> -Toke



-- 
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw

Dave Täht CEO, TekLibre, LLC

Re: [Ecn-sane] [Cake] l4s kernel submission

[Toke Høiland-Jørgensen]

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

> my more specific question was gro. On gro assembly is the dscp/ecn
> header examined?

Yes, and only packets with the same value get aggregated:
https://elixir.bootlin.com/linux/latest/source/net/ipv6/ip6_offload.c#L263

-Toke

Re: [Ecn-sane] [Cake] l4s kernel submission

[Dave Taht]

On Tue, Oct 19, 2021 at 4:19 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> Dave Taht <dave.taht@gmail.com> writes:
>
> > my more specific question was gro. On gro assembly is the dscp/ecn
> > header examined?
>
> Yes, and only packets with the same value get aggregated:
> https://elixir.bootlin.com/linux/latest/source/net/ipv6/ip6_offload.c#L263

Good to know. Thx.

> -Toke



-- 
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw

Dave Täht CEO, TekLibre, LLC

Re: [Ecn-sane] [Cake] l4s kernel submission

[Sebastian Moeller]

So that still leaves us with GSO introducing CE "spikes" into the network, that might not necessarily reflect what would happened if the meta-packet had been segmented before.... I note that rfc3168 probably will not care, since it will signal a CE mark for >= a full RTT anyway, but HFCCs will care. 

Regards
	Sebastian



> On Oct 19, 2021, at 15:30, Dave Taht <dave.taht@gmail.com> wrote:
> 
> On Tue, Oct 19, 2021 at 4:19 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> 
>> Dave Taht <dave.taht@gmail.com> writes:
>> 
>>> my more specific question was gro. On gro assembly is the dscp/ecn
>>> header examined?
>> 
>> Yes, and only packets with the same value get aggregated:
>> https://elixir.bootlin.com/linux/latest/source/net/ipv6/ip6_offload.c#L263
> 
> Good to know. Thx.
> 
>> -Toke
> 
> 
> 
> -- 
> Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw
> 
> Dave Täht CEO, TekLibre, LLC

Re: [Ecn-sane] [Cake] l4s kernel submission

[Dave Taht]

On Tue, Oct 19, 2021 at 6:34 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>
> So that still leaves us with GSO introducing CE "spikes" into the network, that might not necessarily reflect what would happened if the meta-packet had been segmented before....



I am not sure the proper term for this, the "wavefront" of a GSO'd
packet will get scheduled and not marked, and the tail of the wave,
were it not GSO'd, might be marked. The next wavefront, assuming it's
accumulated a negative deficit, will all be marked. Now what this
means for the next "wavefront" I don't really understand, my guess is
packets will start to get paced naturally from the sender but might
still be arriving in a bunch to the receiver.

On the GRO side, I am glad toke has reassured me that at least in
linux, GRO checks all the headers. as for what hardware offloads or
the device drivers might do, unknown.

In our world we've been splitting up gro/gso in self defense so much
that we don't know what the rest of the world looks like. sch_fq has a
3000 byte quantum and always releases two packets by default.

> I note that rfc3168 probably will not care, since it will signal a CE mark for >= a full RTT anyway, but HFCCs will care.

I have long thought that responding better to multiple rfc3168 marks
in an RTT would be a nice addition for a transport to have. But, no,
they don't care.

> Regards
>         Sebastian
>
>
>
> > On Oct 19, 2021, at 15:30, Dave Taht <dave.taht@gmail.com> wrote:
> >
> > On Tue, Oct 19, 2021 at 4:19 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> >>
> >> Dave Taht <dave.taht@gmail.com> writes:
> >>
> >>> my more specific question was gro. On gro assembly is the dscp/ecn
> >>> header examined?
> >>
> >> Yes, and only packets with the same value get aggregated:
> >> https://elixir.bootlin.com/linux/latest/source/net/ipv6/ip6_offload.c#L263
> >
> > Good to know. Thx.
> >
> >> -Toke
> >
> >
> >
> > --
> > Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw
> >
> > Dave Täht CEO, TekLibre, LLC
>


-- 
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw

Dave Täht CEO, TekLibre, LLC