Pete Heist <p...@eventide.io> writes: > I’d like to add the ability for https://github.com/peteheist/irtt > <https://github.com/peteheist/irtt> to send N request packets > per-interval, and to optionally vary, at a minimum, the dscp value. > I’d then like to try to use this to try to estimate queueing delay > (technique discussed below). Would anyone else have a use for this, or > have any requests/suggestions/warnings about it? > > This was initially inspired by a link Toke posted earlier to a paper > about Skype’s ping-pair technique: > https://www.microsoft.com/en-us/research/wp-content/uploads/2017/09/PingPair-CoNEXT2017.pdf > <https://www.microsoft.com/en-us/research/wp-content/uploads/2017/09/PingPair-CoNEXT2017.pdf>. > The technique estimates WiFi congestion by sending back-to-back ICMP > echo requests to the AP, one with DSCP 0x00 and another 0xb8. The > difference in round-trip times is used to quantify the contribution to > observed delay from either self-congestion or cross-traffic, then this > is fed back into the congestion control mechanism in Skype so as not > to back off as aggressively in the cross-traffic case. There’s more > historical literature on the "packet-pair” technique in general, and > even “packet-triplets” or related techniques for bandwidth estimation. > > As for me, I’d like to try to estimate queueing delay in a WiFi > backhaul, and to determine what proportion of the overall delay is due > to queueing vs transmission time or channel contention. Before coming > up with a technique to do this, I’m imagining an experiment that sends > a "packet-quadruplet” :) with four different DSCP values, two of which > will be classified into WMM’s BE queue, and two into the VO queue, and > two of which are given strict priority, while two are not. For sake of > argument, let’s use these values: > > 0x00: regular priority in QoS, WMM’s BE queue > 0x01: strict priority in QoS, WMM’s BE queue > 0xb8: regular priority in QoS, WMM’s VO queue > 0xb9: strict priority in QoS, WMM’s VO queue > > Channel contention delay may be estimated by the difference between > the round-trip times for the strict priority VO and BE packets (0x01 > and 0xb9), and queueing delay between the regular vs strict priority > VO packets (0xb8 and 0xb9), right? Theoretically, the differences > between 0x00 and 0xb8, then between 0x00 and 0x01 could be used to > cross-check these numbers, but I’m not sure exactly what to expect > (thus the experiment).
I like the idea, but is there any equipment that actually implements strict priority queueing within a single QoS level? Or how are you planning to elicit this behaviour? > Lastly, I’ll need to find out for sure how much impact the use of UDP > with a userspace client/server (in Go) is having vs ICMP. Attached is > a SmokePing graph of ICMP vs IRTT on the same Internet route. The > minimums are quite similar, but the deviations under load are rather > different. I find it hard to believe that I’m seeing tens of > milliseconds going into userspace. I think there may be some > prioritization of ICMP somewhere on the route, but I need to somehow > prove definitively whether this is the case or not! That does seem a bit much. Hard to tell what is the cause without a more controlled experiment, though... -Toke _______________________________________________ Flent-users mailing list Flent-users@flent.org http://flent.org/mailman/listinfo/flent-users_flent.org
