Subject: [ippm] "secret sauce"

From: Yaakov Stein <[email-masked]>
Date: Mon, 25 Jul 2011 15:08:48 +0000

I am really sorry to have brought up the "secret sause" issue,

but would like to point out, as Steve said, that there are MANY capacity measurement techniques,

including pathChirp, pathLoad, pipechar, nettimer, Spruce, Yaz, AGI, PTR, ASSOLO, TOPP, MoSeab.

These all send trains of N packets of size S and spacings (either constant delta between them or something else)

and measure delay changes or packet loss. They all need to repeat the measurement at different rates,

so observe when a delay change knee.

These commonalities seem to be sufficient to enable a single extension to OWAMP and TWAMP

to accommodate all of them.

Y(J)S

---

From: "Jeff W. Boote" <[email-masked]>
Date: Mon, 25 Jul 2011 10:48:58 -0600

> to accommodate all of them.

I suspect this might not require a protocol extension. Just an application flag to indicate what patterns you want for different kinds of analysis. (If you want sizes of packets to change within the same train, that would require a protocol extension. I have not looked at all of those techniques to see if that is required or not.)

jeff

>  
> Y(J)S
>  
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: Joel Sommers <[email-masked]>
Date: Mon, 25 Jul 2011 13:02:02 -0400

> I suspect this might not require a protocol extension. Just an application flag to indicate what patterns you want for different kinds of analysis. (If you want sizes of packets to change within th…

I wasn't able to make it online to listen in this morning, so perhaps I am missing the right amount of context.  But a comment to add anyway:

Having written one of these tools (yaz) and having investigated many of the others in a lab setting, I suspect that the issue may not admit a single extension to [OT]wamp to accommodate them all.  Some of the tools require feedback from the receiver, others do not.  Some tools adapt packet size in different probing rounds, others do not.  Some target consistent spacings within a probing round, others vary spacings within a round.  There are probably classes of apps that you can create, and within those classes there are many similarities, but if you look globally across them, there's significant diversity in approach.

Cheers-
Joel

---

From: "Jeff W. Boote" <[email-masked]>
Date: Mon, 25 Jul 2011 11:15:28 -0600

> Having written one of these tools (yaz) and having investigated many of the others in a lab setting, I suspect that the issue may not admit a single extension to [OT]wamp to accommodate them all.…

If you treated each round as a new OWAMP test session, everything you say here is possible with the existing protocol. My comment about changing size of packets was within a single train, that is not currently in the protocol but spacing can be changed within the train (or session). And multiple sessions can be managed using a single control connection.

I would not say the OWAMP protocol is the 'easiest' or most strait forward way of doing any one of these techniques. The only real advantage I see in potentially using OWAMP is that you could leverage the existing installed base of OWAMP servers out there to do this analysis without having to deploy another server-side tool. And, you could leverage the combined desires of all of these tools to create more demand for OWAMP deployments. Individually, each of these tools (owamp included) has much less chance of getting wide-spread acceptance from the system-admin collective.

jeff

---

From: Henk Uijterwaal <[email-masked]>
Date: Tue, 26 Jul 2011 09:20:13 +0200

>>>> so observe when a delay change knee.

The something else is what worries me.  There is an infinite number of
possible patterns, how can we ever accomodate them all?   (Yes, I can
see a registry of patterns and exchange the parameters during setup, but
is this really the way we want to go?).

>>> I suspect this might not require a protocol extension. Just an application
>>> flag to indicate what patterns you want for different kinds of analysis. (If
>>> you want sizes of packets to change within the same train, that would require
>>> a protocol extension. I have not looked at all of those techniques to see if
>>> that is required or not.)

I think that there are 2 generic cases: in the first case, it is known in
advance what packets have to be sent by *WAMP and the results can be analyzed
later.  In the second case, this is not known, one does some measurements,
analyzes and runs a next batch of measurements.  To implement this, I think
we should add things to the protocol that allows one to do the former, but not
the latter.  The latter can be done with multiple sessions.   This leaves
one question: can we specify today what requirements we have for setting up
packet trains.

> I would not say the OWAMP protocol is the 'easiest' or most strait forward way
> of doing any one of these techniques. The only real advantage I see in
> potentially using OWAMP is that you could leverage the existing installed base
> of OWAMP servers out there to do this analysis without having to deploy another
> server-side tool. 

I agree to some extend.  For a known technique, yes, fine.  But I don't think
we can extend *WAMP to a degree where it can accomodate every pattern in
a packet train.   If somebody comes up with a new idea, I'd suggest that
he tries it in an environment where he can deploy his own tools and
show that it works, before adding extensions to *WAMP.

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk(at)uijterwaal.nl
                                          http://www.uijterwaal.nl
                                          Phone: +31.6.55861746
------------------------------------------------------------------------------

There appears to have been a collective retreat from reality that day.
                                 (John Glanfield, on an engineering project)

---

From: "Jeff W. Boote" <[email-masked]>
Date: Tue, 26 Jul 2011 01:39:06 -0600

> is this really the way we want to go?).

I would not think so...

> show that it works, before adding extensions to *WAMP.

Perhaps I'm not understanding, but I don't see why accommodating every pattern is difficult... In fact, I think it is likely already supported. The send schedule is completely generic in OWAMP. You can send any pattern you want as long as all the packet sizes in the session are the same. Send schedules are specified in OWAMP by specifying the amount of time you want between each successive packet as a list. It is a little cumbersome to type in from a command line tool if you have long packet train patterns, but that only requires application flags to make it easier for humans, not changes to the protocol. And would be trivial for a custom OWAMP client that was attempting to do this analysis.

jeff

---

From: <[email-masked]>
Date: Tue, 26 Jul 2011 09:59:10 +0200

Hi Henk,

I don't know the tools. Are they all measuring the overall available bandwidth
(or the total spare bandwidth) or do some only measure, whether a defined
bandwidth of X Mbit/s is available?

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henk Uijterwaal
Sent: Tuesday, July 26, 2011 9:20 AM
To: [email-masked]
Subject: Re: [ippm] "secret sauce"

Henk

---

From: Henk Uijterwaal <[email-masked]>
Date: Tue, 26 Jul 2011 10:17:37 +0200

Hi Ruediger,

> bandwidth of X Mbit/s is available?

Actually, I'm not sure either but I don't think it matters much.

The issue is (at least, I think it is) that there are techniques for measuring
capacity related parameters using packet trains (with various properties of the
trains).  So-far, these parameters have been measured with custom tools sending
the packet trains.  That creates deployment issues.  The question is if and how
*WAMP should be extended to send these packets instead.

Henk

---

From: Henk Uijterwaal <[email-masked]>
Date: Tue, 26 Jul 2011 10:30:59 +0200

On 26/07/2011 09:39, Jeff W. Boote wrote:

> Perhaps I'm not understanding, but I don't see why accommodating every
> pattern is difficult... In fact, I think it is likely already supported. The
> send schedule is completely generic in OWAMP. You can send any pattern you
> want as long as all the packet sizes in the session are the same. Send
> schedules are specified in OWAMP by specifying the amount of time you want
> between each successive packet as a list. It is a little cumbersome to type
> in from a command line tool if you have long packet train patterns, but that
> only requires application flags to make it easier for humans, not changes to
> the protocol. And would be trivial for a custom OWAMP client that was
> attempting to do this analysis.

I think that these techniques have in common that they vary the interval
between packets or the size of the packets.  You are right that the send
schedule can be arbitary (it is too long ago since I looked at this protocol
in detail) so that would solve half the problem.  The size I'm not sure
about and I can predict that at some point somebody will come up with
a pattern where size and interval both vary.

Henk

---

From: Al Morton <[email-masked]>
Date: Tue, 26 Jul 2011 08:27:52 -0400

At 04:30 AM 7/26/2011, Henk Uijterwaal wrote:
>  ...snip...

Already doing it, Henk, in a prototype system. :-)
Al