Re: [Ecn-sane] Fwd: my backlogged comments on the ECT(1) interim call

[Bob Briscoe <ietf@bobbriscoe.net>]

Jonathan,

On 29/04/2020 10:49, Jonathan Morton wrote:
>> On 29 Apr, 2020, at 12:31 pm, Bob Briscoe<ietf@bobbriscoe.net>  wrote:
>>
>>> Can the L4S and SCE folk run the rrul test some day soon? Please?
>> [BB] Does this measure the delay of every packet, so we can measure delay percentiles?
> As shown in our test results, Flent (which implements the RRUL test) is indeed now capable of tracking the latency experienced by individual TCP flows.  It does not do so at the packet level, but at the socket level.
>
> Of course it is also possible to capture the traffic and analyse the traces offline, if you really do want packet-level detail.

1. So, why do you continue to use this approach? It hides all the larger 
delays underneath a moving average. This seems more designed to hide 
inconsistent delay results than to measure them. If a real-time 
application waited only for the median delay before rendering, it would 
have to discard the 50% of traffic in the upper median! TCP also 
delivers nothing until the more delayed packets have been delivered to 
get the stream in order. So median (or mean) delay is a meaningless metric.


2. I also notice you didn't address Dave's point about using short flows 
as well as long. I don't believe I have ever seen a test from you or 
PeteH with anything but long flows.


3. I should add that I know you personally have tried to address the 
asymmetric capacity problem with the ACK thinning in CAKE.




Bob


>   - Jonathan Morton
>

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/