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

From: Jennifer Rexford <[email-masked]>
Date: Thu, 13 Nov 2003 09:50:29 -0500 (EST)

>> we = researchers 
>> a) network operators 
>> b) 'normal' end users 
>> c) 'programs'
>
> we should recognize that these entities have different interests and
> needs (or, rights, as jon argues below). 

Good point.  I think it might be helpful to consider in more detail
what might be helpful in troubleshooting/diagnosing network problems.
Granted, operators do have different needs than researchers, and often
have access to more diverse data from their own networks.  Still,
about the rest of the Internet they often don't have much more
visibility than a typical end-to-end kind of probe would afford.  
As such, fingerpointing to identify the party responsible for your
customer's problem is still very hard.  Better support for active
measurement would help a great deal in this.

This may be beyond the scope of IMP, but I think it is important to
consider that reachability problems might not be caused by a bug or
network anomaly -- they may relate to policies such as packet filters,
firewalls, MTU limitations, etc.  I think it would be *great* if an
end host (belonging to a user or operator) could send a probe saying

  "I have a packet with these attributes (e.g., IP and TCP/UDP headers, 
   and size).  What the @^*%$ is going to happen to it?"

and find out what the scoop is -- the forwarding path itself (at the
link or AS level), the reverse path, some performance stats like RTT,
and where the thing breaks down and why (policy conflict, forwarding
loop, busted link, blackhole, etc.).  You could imagine pushing this
further into the packet contents -- to account for devices that might
filter traffic based on the packet contents -- but that opens an even
larger can of worms... ;)

I would venture to say that maybe a hop-by-hop probe is a good
building block, but perhaps the "final answer" to the end host should
be something more aggregated -- either because that's what a (regular)
user might want or because that's what the operators or routers are
willing to provide.  Maybe an ISP could have a server that provides
partial answers to the "what's going to happen" question without
really letting the *user's* probe do the talking to the router.  In
some case, the ISP might have cached or computed information, or could
pull FIB entries from the routers, rather than doing active probes.
In the end, perhaps a typical end user doesn't want or need
traceroute/ping (and maybe the operator doesn't want to, or shouldn't
have to, give all the details), as long as the problem is identified,
the responsible party spanked, and the problem hopefully fixed or the
inherent policy conflict noted.

Jon, thanks for getting this discussion rolling.  IMP is neat.

-- Jen

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

---

From: jon bennett <[email-masked]>
Date: Thu, 13 Nov 2003 12:10:47 -0800

>visibility than a typical end-to-end kind of probe would afford.

One area where the ability to redirect the IMP packet would be useful to 
ISPs would be where they have arranged with their peers to allow each other 
to bounce packets of the router on the other side of the peering point so 
that you can simulate packets entering your network from the outside.

>    and size).  What the @^*%$ is going to happen to it?"

Actually this is, I think, almost entirely within the scope of IMP. If you 
send the IMP packet off the same src/dst addre and src/dst ports (in the 
'faux-port' fields), proto num (in the faux-port field) with the same size 
etc then it should be handled by most devices just as it would be if it 
were the user packet. To make this work really well it would be nice if we 
could specify that the TTL=0 behavior of the router would be to send back 
the IMP packet as if it had been turned around rather than sending back a 
time exceeded. Then you could do a trace route to find the place at which 
the packet is not handled properly.

I should point out that with IMP you can do trace route in log N packets 
rather than N packets for an N hop path, since you just need to find out 
how long N is and the packet will contain all the hops.

>building block,

IMP is not really a "hop-by-hop" probe, it may be stamped at each hop, but 
it is while it is "just passing through".

>  Maybe an ISP could have a server that provides
>really letting the *user's* probe do the talking to the router.

Yes, another one of the differences in our drafts is that I provide for the 
router to give you the address of a "proxy" host that will answer 
complicated (or simple) questions which the operator does not want the user 
to ask directly of the router.

>In
>pull FIB entries from the routers, rather than doing active probes
>have to, give all the details),

Yes this would also be a good way to interface to things like a GTTP 
server, you might want to only probe the tunnel at X/probes per minute and 
then give out caches answers.

>as long as the problem is identified,

Yes, this was what I was getting at with my example about automatic trouble 
reporting.