Subject: [IMRG] Re: The case for an Internet Measurement Protocol

From: Mark Foster <[email-masked]>
Date: Wed, 12 Nov 2003 13:49:47 -0800

I feel we've needed something like this for a few years.

Right now, we spend an awfully lot of effort putting together
information on things such as reachability (ping), paths
(traceroute), and path characteristics (iperf/nuttcp).

As more and more networking organizations take knee-jerk
reactions to ICMP-based attacks (shutting off ICMP), the few
relatively primitive methods we have become even more limited.
A well designed, relatively easily implemented facility such as
IPMP would go a long way toward improving the network capability
picture with reduced effort in getting that picture.

In addition, I think we'd see a lot less "characterization" traffic
across networks with a broad IPMP deployment.  Fewer ping meshes,
less intrusive bandwidth estimation testing, etc.

Additional comments below.

----
Mark Foster
NASA Research & Education Network
NASA Ames Research Center / CSC

>3) What do we want to measure
>
>Path Properties         MTU/Avail BW/Link Speed/AQM
>
>Is that everything? Too many things? Not enough things?

I would add something about "duplex" to the path properties.
A number of performance issues boil down to duplex mismatch.

The list may be a bit long, but each piece has some merit to
what is needed to support the end applications.

>3.1) Operational Considerations to Measurement
>
>Item 5 : Where ever possible make IMP work with existing equipment
>          that is not IMP aware, and where it is IMP aware don't force
>          it to have twice the flow state

I think this is key.  It's going to be crucial that IMP be able to
be deployed gradually and across a mixed environment (some devices
supporting, some not).

>b) No ISP will ever run anything like this.

IMP may be the sort of thing that gets the best traction by
first deploying on research/education networks.  It doesn't get to
the end goal right away, but it could shake out some of the issues
without requiring commercial ISPs help.  While some commercial
ISPs might be willing, unless it meant losing customers, they might
be slow to adopt.

>c) It will take so long to deploy that it will never be adopted.
>
>The recent run of security problems in the Internet have brought us to
>the point where if the device is software/firmware based then
>deploying IMP into it is just a patch release away.

Particularly if the IMP feature were enabled by default in such
updates/patches.

_______________________________________________
IMRG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/imrg

---

From: jon b <[email-masked]>
Date: Wed, 12 Nov 2003 14:40:11 -0800 (PST)

> A number of performance issues boil down to duplex mismatch.

If by 'duplex' you mean backward path measurement, then that is already
well addressed in the draft. If you meant something else could you
explain what?

> what is needed to support the end applications.

One of the issues to address is to see how many needs can be met with
what is still esentialy one protocol. i.e. some people want to know the
AS number, some people want to know the MTU, other than asking for a
different data field to be stamped in the packet as it pass the router,
the protocol would otherswise be the same for both applications. 

In order to get wide spread interested in IMP we will need wide spread
applicability.

> While some commercial

if the feature comes in their new router (or OS image) then its not
that hard to adopt it. The real issue is convincing the router makers
to include it in the first place.

> Particularly if the IMP feature were enabled by default in such

exactly :-)

jon

---

From: Mark Foster <[email-masked]>
Date: Wed, 12 Nov 2003 15:16:09 -0800

>well addressed in the draft. If you meant something else could you

Sorry.  I wasn't referring specifically to an ipmp draft.
Since the itemized list was sort of a wish list, I was adding
my 2c.  I'm thinking in terms of the problems that Rich Carlson's work
on NDT identifies and addresses. See
http://moat.nlanr.net/PAM2003/PAM2003papers/3703.pdf

Given the set of conditions NDT goes through to intuit duplex mismatch,
I don't think it belongs in ipmp, per se, but should be part of the
general discussion.

-- Mark

---

From: jon bennett <[email-masked]>
Date: Wed, 12 Nov 2003 18:22:39 -0800

>I don't think it belongs in ipmp, per se, but should be part of the

so what you are really saying is that adding "link auto negotiate state" to 
the list of link properties we might be interested in would be a good idea? 
Just ask rather than have to intuit the duplex mismatch.

jon

---

From: Mark Foster <[email-masked]>
Date: Mon, 17 Nov 2003 17:04:27 -0800

At 06:22 PM 11/12/2003 -0800, jon bennett wrote:

>so what you are really saying is that adding "link auto negotiate state" 
>to the list of link properties we might be interested in would be a good 
>idea? Just ask rather than have to intuit the duplex mismatch.

Yeah, I think that's right, although I'm unclear if everything
along the path would be able to give us this info (i.e., some
of the endpoint OSes may not have drivers that would give us
this state info).

-- Mark