Date: Sun, 24 Feb 2019 15:03:25 +0100 From: Michael Tuexen <tuexen@freebsd.org> To: Randall Stewart <rrs@netflix.com> Cc: "Scheffenegger, Richard" <Richard.Scheffenegger@netapp.com>, "freebsd-transport@freebsd.org" <freebsd-transport@freebsd.org> Subject: Re: DSACK Message-ID: <7989F557-6C8E-4379-8E3C-6AADEF7CF293@freebsd.org> In-Reply-To: <824585F6-342D-4F7F-BB2A-FA9CA661E5D2@netflix.com> References: <SN4PR0601MB3728752D55B7231BC4CF22B586780@SN4PR0601MB3728.namprd06.prod.outlook.com> <5ACAD39A-2A77-43BB-BE93-994C1C6C93AB@freebsd.org> <SN4PR0601MB3728DDE5402768567DA9415F86780@SN4PR0601MB3728.namprd06.prod.outlook.com> <5AD822A0-06D7-44DB-AFB1-2453FD59A222@freebsd.org> <F75B74B6-752F-4F6A-886A-E00A484E051E@netflix.com> <58102EB5-6A5A-4BE1-ADEA-4EDCB56A39AE@freebsd.org> <328BFA58-EF05-473C-9DC0-05549E662213@netflix.com> <SN4PR0601MB3728B5FF0CBE3154773FA7BE86790@SN4PR0601MB3728.namprd06.prod.outlook.com> <824585F6-342D-4F7F-BB2A-FA9CA661E5D2@netflix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 24. Feb 2019, at 13:14, Randall Stewart <rrs@netflix.com> wrote: >=20 > Richard: >=20 > I agree it would be a nice to add thing.. I have thought about doing > it for Rack and BBR, but there are so many other things that need = tending too :) >=20 > As to =E2=80=9Csupport is claimed=E2=80=9D.. where is that, A simple = grep through the code for 2883 i.e. >=20 > cd sys/netinet > grep =E2=80=9C2883=E2=80=9D tcp* >=20 > does not show anything.. is it in one of the man pages or something? I did the same... I think he is referring to https://wiki.freebsd.org/TransportProtocols/tcp_rfc_compliance Best regards Michael >=20 > Thanks >=20 > R >=20 >> On Feb 24, 2019, at 7:10 AM, Scheffenegger, Richard = <Richard.Scheffenegger@netapp.com> wrote: >>=20 >> Well, RFC2883 support is claimed, and it may have been working = somewhat in very old code (before 2005?) incidentally... >>=20 >> Even though FBSD doesn't make use of DSACK information, Linux does = (unwind of spurious RTOs for example). So having minimal DSACK (again?) = is certainly good to have. >>=20 >> Also, I wanted to see what tcp_update_sack_list does under certain = corner cases, where we've run into issues, when not adjusting the sack = block left edge (belt + suspenders). >>=20 >> -----Original Message----- >> From: Randall Stewart <rrs@netflix.com>=20 >> Sent: Sonntag, 24. Februar 2019 04:03 >>=20 >>=20 >> I just don=E2=80=99t remember ever seeing code in the stack to do = DSACK. I know I have added some small bits to be aware of DSACK coming = in from other stacks in BBR and Rack, but it only does accounting and = does not use the information.. nor does it generate any.. >>=20 >> I have thought about doing it, but I have not placed a big priority = on it=E2=80=A6. >>=20 >> R >>=20 >>> On Feb 24, 2019, at 7:01 AM, Michael Tuexen <tuexen@freebsd.org> = wrote: >>>=20 >>>> On 24. Feb 2019, at 12:32, Randall Stewart <rrs@netflix.com> wrote: >>>>=20 >>>> I don=E2=80=99t think I have ever seen FreeBSD emit a DSACK. Now = admittedly I=20 >>>> have only paid close attention in current. But that spans even back=20= >>>> into 11 days I think. >>>>=20 >>>> Hmm wonder if I have a 10 machine I can go back and look at :) >>> I tried to test on 10.4 yesterday, but packetdrill doesn't run that=20= >>> well on 10.4 (missing pcap functions)... I'm not sure I want to = backport it. >>>=20 >>> Best regards >>> Michael >>>>=20 >>>> R >>>>=20 >>>>> On Feb 23, 2019, at 5:30 AM, Michael Tuexen <tuexen@freebsd.org> = wrote: >>>>>=20 >>>>>> On 23. Feb 2019, at 11:28, Scheffenegger, Richard = <Richard.Scheffenegger@netapp.com> wrote: >>>>>>=20 >>>>>>=20 >>>>>> Bin grad am flughafen und hab leider nur HEAD bei mir (und ein = iso von 10, wo ich grad versuch, das mit scapy zu checken). >>>>>>=20 >>>>>> Falls du schnell einen packetdrill gegen BSD11 ohne D18960 machen = kannst, und es da noch DSACKs raussendet, w=C3=A4re das toll! >>>>>>=20 >>>>>> Ich f=C3=BCrchte aber, das das schon l=C3=A4ngere Zeit kaputt ist = - da wir nun doch noch nicht D18960 drinnen haben, wie ich irrt=C3=BCmlich= dachte. >>>>> OK. I'll take a look. >>>>>=20 >>>>> Have a save trip! >>>>>=20 >>>>> Best regards >>>>> Michael >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Michael Tuexen <tuexen@freebsd.org> >>>>>> Sent: Samstag, 23. Februar 2019 11:25 >>>>>> To: Scheffenegger, Richard <Richard.Scheffenegger@netapp.com> >>>>>> Cc: freebsd-transport@freebsd.org >>>>>> Subject: Re: DSACK >>>>>>=20 >>>>>> NetApp Security WARNING: This is an external email. Do not click = links or open attachments unless you recognize the sender and know the = content is safe. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> On 23. Feb 2019, at 10:29, Scheffenegger, Richard = <Richard.Scheffenegger@netapp.com> wrote: >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> A colleague pointed me to the stack (HEAD) no longer emitting = DSACK options a few days ago... >>>>>>>=20 >>>>>>> I was under the impression, that older versions of FreeBSD would = send out DSACKs for spurious duplicate packets. >>>>>>>=20 >>>>>>> But when I try this script against HEAD, regular cumulative ACKs = without DSACK blocks are showing up. >>>>>>>=20 >>>>>>> Currently bandwidth starved - but was that a conscious decision? = Or was me observing DSACKs never a thing? >>>>>> I would say if it is working in stable/11, but not in stable/12 = and head, it is a regression. >>>>>>=20 >>>>>> Best regards >>>>>> Michael >>>>>>>=20 >>>>>>> Thanks a lot, >>>>>>> Richard >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> freebsd-transport@freebsd.org mailing list=20 >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-transport >>>>> To unsubscribe, send any mail to = "freebsd-transport-unsubscribe@freebsd.org" >>>>=20 >>>> ------ >>>> Randall Stewart >>>> rrs@netflix.com >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >> ------ >> Randall Stewart >> rrs@netflix.com >>=20 >>=20 >>=20 >=20 > ------ > Randall Stewart > rrs@netflix.com >=20 >=20 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7989F557-6C8E-4379-8E3C-6AADEF7CF293>