From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 48BE321F1C3 for ; Fri, 29 Nov 2013 08:55:56 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id hi5so2330041wib.2 for ; Fri, 29 Nov 2013 08:55:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Au2EYvYbXlmsGnJyUx7GN2qDFGL/UprizBR2chijYdI=; b=v5t0zxPhhKAzCwhVzTARZpPZS5mtnQ8FsWtKyt+lHrtD49k/p5NTwvhjLANt/0H6Ok b9oL0PN6RMDeaCnxDC+B0wQL5r7lAhZLmzodCgXvqgPYNNY0gqYbkYKSy9ZMDNi6EZMV 4qBo4i4CsqSqYzKCpgQHbgQBLL2PAg8lwY3NwwRiyLOKe3AgUm2ClEt8CiCfsnkhNzWR /cn2CxAoc9X73Yn5n/0B3ba1uvf0ts6v3U9f/Y8AyiU5lSa7MKRauiunMfGRkofTgeSo MAj3mpMiI9qOTjj4MxZ59B3JdyM3yx8HEb8qjhiTj+8GglPoRdhKVh4dW9Cv9rN0XTG8 4tSA== MIME-Version: 1.0 X-Received: by 10.194.236.169 with SMTP id uv9mr2770363wjc.73.1385744154795; Fri, 29 Nov 2013 08:55:54 -0800 (PST) Received: by 10.217.51.5 with HTTP; Fri, 29 Nov 2013 08:55:54 -0800 (PST) Received: by 10.217.51.5 with HTTP; Fri, 29 Nov 2013 08:55:54 -0800 (PST) In-Reply-To: <503FC4CA-967A-407A-9A93-97D61FE11566@netapp.com> References: <87zjoojr5u.fsf@toke.dk> <87mwknk0hw.fsf@toke.dk> <5392347C-BC88-4836-BB53-F48523210237@netapp.com> <87haavjr4m.fsf@toke.dk> <503FC4CA-967A-407A-9A93-97D61FE11566@netapp.com> Date: Fri, 29 Nov 2013 08:55:54 -0800 Message-ID: Subject: Re: One-way delay measurement for netperf-wrapper From: Dave Taht To: Lars Eggert Content-Type: multipart/alternative; boundary=089e0149402418a2bd04ec53b4d8 Cc: Midori Kato , bloat-devel X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 16:55:58 -0000 --089e0149402418a2bd04ec53b4d8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Nov 29, 2013 6:30 AM, "Eggert, Lars" wrote: > > Hi, > > On 2013-11-29, at 14:04, Toke H=F8iland-J=F8rgensen 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. --089e0149402418a2bd04ec53b4d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Nov 29, 2013 6:30 AM, "Eggert, Lars" <lars@netapp.com> wrote:
>
> Hi,
>
> On 2013-11-29, at 14:04, Toke H=F8iland-J=F8rgensen <toke@toke.dk> wrote:
> > Now, some possible issues with this:
> >
> > - Are we measuring the right thing? This will measure the time it= takes
> > =A0a message to get from the application level on one side to the=
> > =A0application level on another. There are a lot of things that c= ould
> > =A0impact this apart from queueing latency; the most obvious one = is
> > =A0packet loss and retransmissions which will give some spurious = results
> > =A0I suppose (?). Doing the measurement with UDP packets would al= leviate
> > =A0this, 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 b= e 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
> > =A0computed delay as-is means that the numbers will be meaningles= s
> > =A0without very accurately synchronised clocks. On the other hand= , not
> > =A0processing the numbers before outputting them will allow peopl= e who
> > =A0*do* have synchronised clocks to do something useful with them= .
> > =A0Perhaps a --assume-sync-clocks parameter?
>
> Yep. Or you could check for the accuracy of the NTP synchronization, a= s suggested by Hal.
>
> > - Echoing back the delay measurements causes traffic which may or= may
> > =A0not be significant; I'm thinking mostly in terms of runnin= g
> > =A0bidirectional measurements. Is that significant? A solution co= uld be
> > =A0for the receiver to hold on to all the measurements until the = end of
> > =A0the test and then send them back on the control connection. >
> Depends on the measurement interval. I'm guessing it won't mat= ter much if you e.g. only timestamp once a millisecond or something.
>
> > - Is clock drift something to worry about over the timescales of = these
> > =A0tests?
> > =A0https://www.usenix.org/legacy/events/iptps10/tech/slides/c= ohen.pdf
> > =A0seems to suggest it shouldn't be, as long as the tests onl= y run for at
> > =A0most 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 t= he 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 wa= s discussed at ietf. I am under the impression this is an old SNA feature.<= /p>

http://www.ietf.org/proceedings/88/slides/slides-88-ippm-0.p= df

I liked the chart and I seem to recall there was an implemen= tation.

--089e0149402418a2bd04ec53b4d8--