On Nov 29, 2013 6:30 AM, "Eggert, Lars" wrote: > > Hi, > > On 2013-11-29, at 14:04, Toke Høiland-Jørgensen wrote: > > Now, some possible issues with this: > > > > - Are we measuring the right thing? This will measure the time it takes > > a message to get from the application level on one side to the > > application level on another. There are a lot of things that could > > impact this apart from queueing latency; the most obvious one is > > packet loss and retransmissions which will give some spurious results > > I suppose (?). Doing the measurement with UDP packets would alleviate > > this, but then we're back to not being in-stream... > > right. I happen to be interested in that metric, but not everyone may be. Some folks may only care about latencies added in the network, in which case the TCP-timestamp-based approach might be better (if the kernel can be convinced to generate timestamps with sufficient resolution). > > You could also combine the two approaches. That way, you might be able to account for sender, network and receiver latencies. > > > - As for point 3, not normalising the result and just outputting the > > computed delay as-is means that the numbers will be meaningless > > without very accurately synchronised clocks. On the other hand, not > > processing the numbers before outputting them will allow people who > > *do* have synchronised clocks to do something useful with them. > > Perhaps a --assume-sync-clocks parameter? > > Yep. Or you could check for the accuracy of the NTP synchronization, as suggested by Hal. > > > - Echoing back the delay measurements causes traffic which may or may > > not be significant; I'm thinking mostly in terms of running > > bidirectional measurements. Is that significant? A solution could be > > for the receiver to hold on to all the measurements until the end of > > the test and then send them back on the control connection. > > Depends on the measurement interval. I'm guessing it won't matter much if you e.g. only timestamp once a millisecond or something. > > > - Is clock drift something to worry about over the timescales of these > > tests? > > https://www.usenix.org/legacy/events/iptps10/tech/slides/cohen.pdf > > seems to suggest it shouldn't be, as long as the tests only run for at > > most a few minutes. > > Wouldn't think so. > > > So anyway, thoughts? Is the above something worth pursuing? > > I certainly would like this test. It may also be a good proposal for the IPPM metric. > > Lars > > _______________________________________________ > Bloat-devel mailing list > Bloat-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat-devel > The idea of creating a generic ipv6 header for timestamps was discussed at ietf. I am under the impression this is an old SNA feature. http://www.ietf.org/proceedings/88/slides/slides-88-ippm-0.pdf I liked the chart and I seem to recall there was an implementation.