From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 771933B2A4; Sat, 7 Sep 2019 08:02:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1567857759; bh=8A+DsP4r23yyftmpzaHMc8cndmbo32nquXUTLoh9GMU=; h=X-UI-Sender-Class:Date:In-Reply-To:References:Subject:To:CC:From; b=A1iqXkgceA0480R38NXR61JHpsiVW3gS/IBs3jDMhCVpswlJP+e+hUWPJtfxMWp1K htlXzK3TpQNhbfX6zp4lW3/Nwz/ElQ2TqXQ6Az23UufkoBCgjiMGWr5JdDDXn+5s2o tfVorMD6vMH2l9iRg4FuG67Gqp9EX7u11/NCJr4c= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.133] ([77.181.49.56]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MB2G8-1hytvX22Xk-009yUx; Sat, 07 Sep 2019 14:02:39 +0200 Date: Sat, 07 Sep 2019 14:02:35 +0200 User-Agent: K-9 Mail for Android In-Reply-To: <5D47BF2C-025A-46F0-857C-B2EB673ED798@heistp.net> References: <874l1p25ka.fsf@toke.dk> <63E4F227-7BC3-4238-B3F2-8B57118AAFD1@gmx.de> <87ef0tz4p2.fsf@toke.dk> <875zm5yr8m.fsf@toke.dk> <87lfv1xbmk.fsf@toke.dk> <5D47BF2C-025A-46F0-857C-B2EB673ED798@heistp.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----DT4VS8BSSX2V7D4D9KMJYT0JUO0I0F" Content-Transfer-Encoding: 7bit To: Pete Heist CC: =?ISO-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= , bloat@lists.bufferbloat.net, Matt Taggart , cerowrt-devel From: Sebastian Moeller Message-ID: <182F72BE-7448-4F59-AD4D-64267D0721ED@gmx.de> X-Provags-ID: V03:K1:x1RY9rZ0LIYkPn28/CpYBSwul94hRHGr8o00eJ54/3PPYVBHu/F OFH+zFbmFuXI8ZeCnIHutLupWrFUhD46ZCGuhLlTLmaDcSCyoD4PR7uioIkon0RcByC3XQ8 dzxUYOXjb6lpzFK+A1PvFC67r1Ei5gCLSP5bsNwv8CR5d08mCSuZn98t0LA/3LsnLHrmZ3H c6RDDVj3uPDj1ua4H0zJQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:aDro5Ijaqw0=:lPLLq7IxTaUOpAz2SWpEtT pmX5juhdhJbJ6btThB4hWgM4pyplF70YX7MW2P3gGrmhw30GK/huLneapU2lbW30xe9KZrMG1 a1Jlsk1k3hjm/nFiIO/Nvcz6IS9ocZsg7L5B5YpG/jCZ26nu19/Vm9BjH+JBBQ9g6OfyfFP73 S1GJ0xQM3IpMZVYtnPaVVM2vrW5PnBL34k/PzSYEn2Uec0L/PgIVDYNzzIanvKi/j9FubuTX8 Og1C8nz5HUzL5aR0CU9z5beK2IZXoIS+4tw8545qYkU80SFBpnVYm72CdSOvJdhCyNlCPgJt+ 35kPGpBtUiqYcgxF59iT0gsNaWjX7lkEs8zpjGTT4aTMRhmLR4fcRZ6+g0FKyiaVxqx9AVThI dO1wK3c7Efb7AOCCi0/eCi4iDM3k/kyOYjCgXe8kPqC1qHpJrB6yrfYNn8bveXbyL6cv0NbmP iB27tpMqCufNnXqJ0I7Fl0bu2mN1WRKbvoKYkGeLsKqviFa68PTLUYCKZepbs+Ld4dnaVDnhx UIAmk8gCDe99LhN9gdDoSCCMsoJZYs5Iuir7WOJq4qLnrK81Kfafxnnr229uL6+nMMqY6r/JZ 3n8dwU3YoFgWxM+HEcqWn2l/d1Cieo9ks1qxyzR2WeFUEIQmIiYfzDjf2KklJ3l7Ad/+fJg/1 4eOpHIRNOscnjUrF/ZQ8xTPENKsC/3cpi5+1ESIUwqbqwqHenS5VflZZ0ekhEkQGryvcpCq/Y 8vGpqXWKwmoB/2haZR05gMb7NraGUJ/N55QSzKnPCtnv2KijKmpOr5bP7SMCZD0tBWewAntpI LsDcsZ6vUKGLIygZeqhf/kfzT2vZTHj4vHGnpSnpH6D3WjwjAa5xLuH7pNJGZkDM0xPR9qV4O j5E4gXmlzFjURo8NzmAzVIvWdlTJe7s1n2POb/Ra979pg5PRuyG6gfLsRLfACfVS/UqR1kFOp pv1BPRAO+1xlGcRO0QMPGf8EfGkP+LBikVUaldUP3E0F81UINx3peowgf6W7MiJnVxSITC8Zj t7NqDOP0snQmLiAlYLFbzGwsSDVDJc5QBuwnhPnosUWkhLcpUdFlou9qfOMyN0dyYa22Gu+wX 41AfRRWWsmjSTcXKP8MRWBl8dRytLVcVqbCfKavNCA88uZHiriWEBMKaMXfrFPWwX5nkUnBsa gw949bDAHWJOieZHOio2jRRFcnXyKeeGt51rgsIuAGH7RXRMJAu2CHG4E3XvFkMQdCD/NmCcH zVomyYCnL0XNIM9m0 Subject: Re: [Cerowrt-devel] [Bloat] Ubiquiti Launches a Speed Test Network X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2019 12:02:57 -0000 ------DT4VS8BSSX2V7D4D9KMJYT0JUO0I0F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Pete, If the PayPal ad of an irtt packet would contain the requested DSCP as asc= ci string (maybe starting with a string like "DSCP: 46: 101110 (EF)" in the= first few bytes of the payload would make confirming bleaching/remapping f= rom packetdumps relatively convenient, say just by looking at a packet in W= ireshark and comparing the IP headers DSCP value with the string in the pay= load=2E Sure that is not automated, but would be great in at least allowing= to test for bleaching in the packets received from a irtt server=2E=2E=2E= =2E But, as much as I would like that feature, I believe the total audience wi= ll be quite small=2E=2E=2E=2E Best Regards Sebastian On September 7, 2019 1:33:48 PM GMT+02:00, Pete Heist = wrote: > >> On Sep 7, 2019, at 1:12 AM, Toke H=C3=B8iland-J=C3=B8rgensen >wrote: >>=20 >>>>> From irtt help client: >>>>> --fill=3Dfill fill payload with given data (default none) >>>>> none: leave payload as all zeroes >>>>> rand: use random bytes from Go's math=2Erand >>>>> pattern:XX: use repeating pattern of hex (default >69727474) >>>>> --fill-one fill only once and repeat for all packets >>>>> --sfill=3Dfill request server fill (default not specified) >>>>> see options for --fill >>>>> server must support and allow this fill with >--allow-fills >>>>=20 >>>> As above, we're doing --fill=3Drand today=2E >>>=20 >>> Sama as above, but maybe Pete could be convinced to do the read >back of the first X bytes automatically=2E >>=20 >> Certainly not opposed to adding this support to Flent if it >materialises >> in irtt :) > >Coming into this late so haven=E2=80=99t parsed the full request, but irt= t >sends the requested DSCP value passed in via --dscp to the server >during the handshake=2E It would be possible, though not very intuitive, >to pull this out of the initial request packet, which contains >type/value pairs encoded with varint style encoding: >https://developers=2Egoogle=2Ecom/protocol-buffers/docs/encoding=2E > >The format of the request is =E2=80=9Cdocumented=E2=80=9D in code in the = bytes() method >in params=2Ego=2E Visually, the DSCP value is often the value 0x08, close >to the end of the initial packet, following by the DSCP value as a >signed varint=2E (Clearly, it would have made more sense if I=E2=80=99d j= ust sent >that as an unsigned byte instead of using a varint, let alone a signed >one, but I just leaned on the binary package=E2=80=99s varint support, su= ch as >it is, so one has to grok this: >https://developers=2Egoogle=2Ecom/protocol-buffers/docs/encoding#signed-i= ntegers=2E >I=E2=80=99ve added it to irtt=E2=80=99s todo list to clean this up before= 1=2E0, which >will mean a protocol version bump)=2E > >One unfortunate thing is that if the goal is to verify that DSCP values >have not been modified along the way (without a pcap), afaik the >receiver has no way of obtaining the received DSCP value in user space >without opening up a raw socket and parsing the IP packet in full >(requiring root)=2E But, figuring it out from packet dumps would be >possible=2E If I ever get around to adding irtt support to scetrace >(https://github=2Ecom/heistp/scetrace), I could detect and count changes >to dscp values there, though that=E2=80=99s a ways off at the moment=2E > >Knowing all this, are there any simple changes I can make to get you >what you need? --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------DT4VS8BSSX2V7D4D9KMJYT0JUO0I0F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Pete,

If the PayPal ad of an irtt packet= would contain the requested DSCP as ascci string (maybe starting with a st= ring like "DSCP: 46: 101110 (EF)" in the first few bytes of the payload wou= ld make confirming bleaching/remapping from packetdumps relatively convenie= nt, say just by looking at a packet in Wireshark and comparing the IP heade= rs DSCP value with the string in the payload=2E Sure that is not automated,= but would be great in at least allowing to test for bleaching in the packe= ts received from a irtt server=2E=2E=2E=2E

But, as much as I would l= ike that feature, I believe the total audience will be quite small=2E=2E=2E= =2E

Best Regards
Sebastian

On September 7, 2019 1:33:48 PM GMT+02:00, Pete Heist <pete@heistp= =2Enet> wrote:

On Sep 7, 2019, at 1:12 AM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke= =2Edk> wrote:

From irtt help client:
--fill=3Dfill fill payloa= d with given data (default none)
none: leave payload as all= zeroes
rand: use random bytes from Go's math=2Erand
= pattern:XX: use repeating pattern of hex (default 69727474)
--= fill-one fill only once and repeat for all packets
--sfill=3Dfill = request server fill (default not specified)
see options for= --fill
server must support and allow this fill with --allo= w-fills

As above, we're doing --fill=3Drand today=2E

Sama as above, but maybe Pete could be convinced to do t= he read back of the first X bytes automatically=2E

Cert= ainly not opposed to adding this support to Flent if it materialises
in = irtt :)

Coming into this late so haven=E2=80=99t parsed= the full request, but irtt sends the requested DSCP value passed in via --= dscp to the server during the handshake=2E It would be possible, though not= very intuitive, to pull this out of the initial request packet, which cont= ains type/value pairs encoded with varint style encoding: https://deve= lopers=2Egoogle=2Ecom/protocol-buffers/docs/encoding=2E

The form= at of the request is =E2=80=9Cdocumented=E2=80=9D in code in the bytes() me= thod in params=2Ego=2E Visually, the DSCP value is often the value 0x08, cl= ose to the end of the initial packet, following by the DSCP value as a sign= ed varint=2E (Clearly, it would have made more sense if I=E2=80=99d just se= nt that as an unsigned byte instead of using a varint, let alone a signed o= ne, but I just leaned on the binary package=E2=80=99s varint support, such = as it is, so one has to grok this: https://developer= s=2Egoogle=2Ecom/protocol-buffers/docs/encoding#signed-integers=2E I=E2= =80=99ve added it to irtt=E2=80=99s todo list to clean this up before 1=2E0= , which will mean a protocol version bump)=2E

One unfortunate thing = is that if the goal is to verify that DSCP values have not been modified al= ong the way (without a pcap), afaik the receiver has no way of obtaining th= e received DSCP value in user space without opening up a raw socket and par= sing the IP packet in full (requiring root)=2E But, figuring it out from pa= cket dumps would be possible=2E If I ever get around to adding irtt support= to scetrace (https://gi= thub=2Ecom/heistp/scetrace), I could detect and count changes to dscp v= alues there, though that=E2=80=99s a ways off at the moment=2E

Knowi= ng all this, are there any simple changes I can make to get you what you ne= ed?


--
Sent from my Android device = with K-9 Mail=2E Please excuse my brevity=2E ------DT4VS8BSSX2V7D4D9KMJYT0JUO0I0F--