[e2e] Extracting No. of packets or bytes in a router buffer

[Fred Baker]

On Dec 23, 2006, at 8:01 AM, Matt Mathis wrote:
> ICMP has been dead as a measurement protocol for about 10 years  
> now. The problem is that nearly all implementations process ICMP at  
> substantially lower priority than other protocols, so the  
> measurements are far worse than reality.
>
> I think you are looking for something more along the lines of IPMP,  
> the IP measurement protocol.   Look for the expired Internet drafts:
> draft-bennett-ippm-ipmp-01      2003-03-05      Expired
> draft-mcgregor-ipmp-04  2004-02-04      Expired

http://tools.ietf.org/html/draft-bennett-ippm-ipmp
http://tools.ietf.org/html/draft-mcgregor-ipmp

> There is also a report by several people including Fred Baker and  
> me, analyzing these two conflicting drafts, and proposing yet  
> another variant.  I couldn't find the report quickly.  Perhaps Fred  
> has a copy.....?
>
> If you want to follow this thread, be sure to engage the router  
> vendors/large ISP's early and listen to them carefully, because the  
> academic and industrial agendas clash very badly.   (You should  
> read the report first.)
>
> Thanks,
> --MM--
> -------------------------------------------
> Matt Mathis      http://www.psc.edu/~mathis
> Work:412.268.3319    Home/Cell:412.654.7529
> -------------------------------------------


Is this what you're thinking of?

Let me reiterate your point - if you want features in routers and  
switches that will help you be able to determine what is happening in  
various networks along the way between here and there, you have two  
avenues. One is that you can measure externally and make inferences  
about the total end to end path that may not tell you much about any  
specific point. The other is that you can know specifics of the path  
and perhaps individual nodes on the path by asking them questions. If  
you want supporting features to be available to you in the routers,  
convince the ISPs that *they* want them. Reason: they will have to  
turn them on, and they will have to allow you access, and it will be  
their dollars that convince the vendors to build them. So think hard  
about how these will help the ISPs do what they do.

Note I am not in saying this throwing cold water on it. The ISPs are  
in fact looking for ways to deliver SLAs that involve multiple ISPs  
on an end to end path - that's part of the ITU NGN effort. Help them  
solve that problem and you might get a fair bit of interest. At the  
same time, if your solution is "interesting research" but doesn't  
help the ISPs solve a problem they want solved, expect results to be  
spotty at best.

Begin forwarded message:
> From: Mark Allman <mallman at icir.org>
> Date: September 7, 2004 6:33:19 AM PDT
> To: imrg-ipmp-review at guns.icir.org
> Subject: Mark Allman: [IMRG] ipmp review team report
> Reply-To: mallman at icir.org
>
> *** PGP SIGNATURE VERIFICATION ***
>
> *** Status:   Good Signature
> *** Signer:   Mark Allman <mallman at icir.org> (0xCE3222CE)
> *** Signed:   09/07/04 6:33:19 AM
> *** Verified: 09/07/04 7:13:11 AM
> *** BEGIN PGP VERIFIED MESSAGE ***
>
>
> Folks-
>
> FYI, here is what I sent to the IMRG mailing list (for those who do  
> not
> track it).
>
> Thanks again for all your hard work!
>
> allman
>
>
>
> ------- Forwarded Message
>
> To: imrg at irtf.org
> From: Mark Allman <mallman at icir.org>
> Organization: ICSI Center for Internet Research (ICIR)
> Song-of-the-Day: Paradise City
> Date: Tue, 07 Sep 2004 09:03:02 -0400
> Subject: [IMRG] ipmp review team report
>
>
> Folks-
>
> A while back you might remember that we had some discussion on the IP
> Measurement Protocol.  In order to try to gain some traction I asked a
> few folks to act as a review team to look over the two proposals on  
> the
> table (and the ancillary information).  The team has completed their
> work and did a very nice job of debating the issues involved in  
> IPMP and
> coming up with a summary of their feelings.
>
> The team members are listed at the bottom of the report and I wish to
> thank them for their diligence in reviewing these documents.
>
> The report from the group is below.  Please feel free to discuss the
> ideas enumerated in the report on this mailing list all you want.  The
> team is not the final word.  I convened the team to get some focued
> energy thinking about these issues.  The report is in no way  
> binding nor
> the community's final judgement.  So, please feel very free to  
> continue
> the discussion.
>
> allman
>
>
>
>
>
> IMRG IPMP Review Team Report
> - ----------------------------
>
> The Internet Measurement Research Group (within the IRTF) convened a
> small team to review the materials related to the IP Measurement
> Protocol (IPMP).  The members of the group (listed at the end of
> this report) discussed IPMP and several larger issues.  In
> particular, the team reviewed the following two Internet-Drafts:
>
>     draft-mcgregor-ipmp-03.txt
>     draft-bennett-ippm-ipmp-01.txt
>
> The goal of this effort was to chart a strawman course for moving
> forward with some sort of measurement protocol (if possible).
>
> Note: This message represents the group's consensus.  However, that
> does not mean that each member of the team agrees with each point in
> this note.  The group reached rough agreement, not unaminity.
>
> The following are the high-order bits from the discussion.
>
> The fundamental challenge that measurement protocols attempt to
> address is to provide a means to measure the network characteristics
> researchers and operators want to understand in a way that provides
> fine grained information about the network in a lightweight fashion.
> To this end, we would suggest that IPMP wants to develop tools that
> are:
>
>   - implementable in reasonable timeframes on existing equipment,
>     which means that they should not depend on ASIC development or
>     new equipment purchase
>
>   - deployable; ISPs would ideally want them, and at minimum not
>     turn them off
>
>   - useful to the ISPs in terms of their business rules and the
>     questions they ask about their own networks
>
> If the procedures or protocols are useful to the ISPs, one can
> expect that they will be willing to collect the data, and may under
> some appropriate rules also allow researchers to collect data or
> share collected data with researchers.
>
> In the above context, the team found the motivation for IPMP given
> in both documents to be lacking --- to the point where the team did
> not feel the current proposals are viable.  Several
> related/supporting points were discussed:
>
>   * From the perspective of a vendor developing equipment and
>     protocols or an ISP deploying them, the IPMP proposals on the
>     table do not look viable.  The fundamental goal of IPMP is to
>     display the structure of a network and many of its fine-scale
>     characteristics.  This is information that a service provider
>     does not share with anyone else except - maybe - under
>     NDA. Given that the protocols to obtain the information are
>     fairly complex and involve a fair level of memory writes, the
>     vendor will do this if and only if its ISP customers ask for it,
>     and they are not asking for this.
>
>   * Making a better ping or traceroute is, on the one hand, too
>     narrow and mechanistic a focus and yet also too focused on what
>     researchers might find compelling rather than what operators
>     would.
>
>   * A tool to reverse engineer a network isn't needed by the ISPs.
>     They already know the structure of their own networks.
>
> That said, the team **strongly** believes that there is much room
> for improvement in the state of network troubleshooting and
> debugging.  In particular:
>
>   * Some service providers are asking for a solution to a problem
>     that may yield data that researchers may find valuable.  Within
>     its own network, a service provider is generally interested in
>     locating the links that introduce variability into their
>     network.  It may view them as under-provisioned for offered
>     load, as inappropriately routed, or whatever, but they are in
>     fact interested in locating links that require upgrading in some
>     form.
>
>   * Some service providers are asking (in TIA and related fora) how
>     they can deploy SLAs that cross ISP boundaries. These may be
>     among ISPs that form business coalitions, such as Teleglobe has
>     tried to set up with its transit network customers, or among
>     regional networks such as US RBOCs that view transitive SLAs as
>     a rational approach.  The watchword in such consortia is "trust
>     but verify"; it is in their interest to have a procedure or
>     protocol that will allow them to isolate issues that may prevent
>     them from meeting SLA guarantees in something resembling real
>     time.  Since those SLAs are one-way, this means accurate one-way
>     delay and jitter measurements host to host, POP to POP, or CPE
>     to CPE.
>
> In addition, in looking at the protocols themselves, we found
> ourselves wondering how much could be learned by clever inference from
> fairly simple data collection and black box measurement, as opposed
> to explicit reporting of values.
>
> As another example, we note that the intention of such procedures as
> CalTech's FAST and MIT's XCP protocols is to detect and measure
> variable delays in the network and cause traffic to be sent in such
> a way as to maximize throughput while minimizing such delays. This
> fundamental question is a direct corollary to that raised in
> http://www.nwfusion.com/research/2002/1216isptestside1.html, and
> that raised in the context of transitive Tier 2 network SLAs. These
> would like to be able to identify the existence of an SLA failure or
> other disturbance in the Force on a route, report its magnitude, and
> isolate the disturbing device. To that end, we wonder can be done
> with the numbers measured by Dina Katabi's XCP protocol.
>
> Finally, the team wondered if a protocol that carries less global
> information but more precision would be more deployable.  For
> example if the stamps just consisted of an opaque ID, TTL and simple
> 32 bit counter running on "the most stable local frequency source",
> then the ISP (w/ the engineering documentation for their own gear)
> can use database techniques to compute everything carried by the
> current protocol.  The stamps are simple enough where we can, with a
> straight face, ask for them in multiple places within one box: input
> and output framers, bus DMA engines, etc.  We can envision that this
> would be an extremely valuable tool for an ISP to understand (and
> diagnose) certain QoS properties of their own network.  Note that,
> globally parsable metadata in the stamps probably has negative value
> to most ISPs because it reduces an ISP's ability to keep it's assets
> private.  The barrier to deployment in not so much the cost of the
> implementation, but the indirect cost of the leaking proprietary
> topology information.
>
> At the same time, external researchers could use inference
> techniques to get some of the same information, including most
> dynamic properties such as queue depths etc.  The external users get
> much less topology information, unless they make an explicit
> arrangement with the ISP to get the annotations associated with the
> opaque IDs.
>
> In summary, the team came to two points of consensus: 1) that the
> protocol is inadequately motivated by the proposals, even though
> ISPs would like to be able to measure their and their neighbors'
> networks; 2) that the protocol's complexity and intrusiveness are
> inadequately justified with respect to other, potentially more
> lightweight approaches that may be easier to deploy.  The main point
> is that to get a protocol deployed, ISPs need to ask for it loudly
> enough and router vendors need to be able to implement it easily
> enough, and neither is argued by these proposals.
>
> Review team members: Guy Almes (Internet2), Fred Baker (Cisco), Paul
>   Barford (UWisc), Chistophe Diot (Intel Research), Ralph Droms
>   (Cisco), Larry Dunn (Cisco), Matt Mathis (PSC), David Moore
>   (CAIDA), Jennifer Rexford (AT&T Research), Neil Spring (Univ. of
>   Washington)
> Scribe / team shepherd: Mark Allman (ICIR)
>
> ------- End of Forwarded Message
>
>
>
>
>
>
> *** END PGP VERIFIED MESSAGE ***