[Scamper-dev] some scamper thoughts
Bradley Huffaker
bhuffake at caida.org
Sat Jul 10 10:45:45 PDT 2004
----- Forwarded message from k claffy <kc at caida.org> -----
>
>
> since you're thinking more about the database framework
> that could support this kind of thing now..
>
> ----- Forwarded message from Mark Crovella <crovella at cs.bu.edu> -----
>
> Date: Tue, 13 Jan 2004 23:34:26 +0100
> From: "Mark Crovella" <crovella at cs.bu.edu>
> Subject: RE: scope of work for our current skitterNG code author
> To: "'k claffy'" <kc at caida.org>
> X-Mailer: Microsoft Outlook, Build 10.0.4510
>
>
> Here are some rough thoughts regarding decomposing skitter into
> distributable pieces.
>
> Goals:
> allow skitter to be split into the following pieces, with
> protocol-supported interfaces between them:
>
> 1) executive: accepts requests for traceroutes, and responds with
> specification of a (set of) traceroutes to run. Response may include
> considerable information about "how" to run the traceroute (eg, probing
> packet type, probing rate, points in the network where the TR should
> stop, other early TR termination criteria). Protocol should be
> extensible to allow future expansion of the "how" specification.
>
> 2) slave: requests traceroutes from executive. Slave can authenticate
> to executive (somehow). Slave can specify how many "cycles" it has to
> contribute -- ie, how many TRs it wants to run.
>
> 3) data collector: (not necessary just one in any system): accepts
> contributions of TR results and compiles them into a database. Results
> would have to include as much information as would be helpful in
> interpreting results, such as timestamps, information about probe box's
> characteristics, etc.
>
> Now, replace the "traceroute" in the above with "some measurement
> technique". That is, instead of distributing requests for traceroutes,
> the infrastructure could distribute requests for BW probes, etc.
>
> Rationale:
>
> The reason for this is as follows. Suppose I want to contribute some
> cycles to skitter's general goals. I am willing to either write some
> software (maybe I'll embed it in the next kazaa or whatever) or I am just
> willing to try out running an at-home measurement system.
>
> Or let's say I am an "internet researcher". I want to define a new kind
> of topology-measurement strategy and try it out. I could then set up my
> own executive, and ask people to point their slaves at my executive and
> send their result to my collector.
>
> What do you think?
> Mark
>
> -----Original Message-----
> From: k claffy [mailto:kc at caida.org]
> Sent: Tuesday, January 13, 2004 10:44 PM
> To: crovella at cs.bu.edu
> Subject: scope of work for our current skitterNG code author
>
>
>
>
> maybe it's worth getting you involved
> in this discussion sooner rather than later,
> although we are under pressure to get matthew's
> statement of work done since WIDE wants to fund
> his grad student salary for 2004...
>
> anyway, here's where we are so far...
> k
>
>
>
>
> ----- Forwarded message from Young Hyun <youngh at caida.org> -----
>
> Date: Tue, 13 Jan 2004 13:37:51 -0800 (PST)
> From: Young Hyun <youngh at caida.org>
> Subject: Re: URGENT: NEED YOUR APPROVAL
> To: k claffy <kc at caida.org>
> cc: Andre Broido <broido at caida.org>, Kenjiro Cho <kjc at csl.sony.co.jp>,
> brad <bhuffake at caida.org>, Matthew Luckie <mjl at luckie.org.nz>,
> Nevil Brownlee <nevil at caida.org>
>
> My only comment is on the architecture. I hope scamper will be
> designed/re-designed in such a way that the method of probing (currently
> sending UDP packets to a high port) can be replaced with other methods.
> How to do this, and how easily this should be possible, are things that
> need to be figured out, but this is the kind of thing that's hard to
> retrofit into a design/architecture.
>
> --Young
>
> On Tue, 13 Jan 2004, k claffy wrote:
>
> > can you give me any feedback on, or approve,
> > this SOW by midnite tonite?
> >
> > k
> >
> > ----- Forwarded message from Matthew Luckie <mjl at luckie.org.nz> -----
> >
> > Date: Wed, 14 Jan 2004 10:16:40 +1300
> > From: Matthew Luckie <mjl at luckie.org.nz>
> > Subject: updated SOW for WIDE
> > To: Bradley Huffaker <bhuffake at caida.org>
> > CC: k claffy <kc at caida.org>
> >
> > Research Plan for Scamper
> >
> > A one year plan to continue development of scamper.
> >
> > Things done so far:
> >
> > - scamper-0.9.4b4
> >
> > scamper currently can traceroute at a specified packets per second
> > rate to a destination list consisting of both IPv4 and IPv6
> > addresses. It compiles and runs on MacOSX, NetBSD, FreeBSD, and
> > Linux. It collects intermediate RTTs from hops towards a
> > destination.
> >
> > - preliminary PMTU discovery functions
> >
> > scamper can do PMTU discovery for both IPv4 and IPv6 on BSD-like
> > platforms. the code for this is not particularly robust, but it
> > seems to work well enough for use on paths where most intermediate
> > hops will identify themselves and send ICMP fragmentation required
> > messages - like on paths measured by AMP. I have run scamper in
> > PMTU discovery mode on the AMP IPv6 mesh successfully.
> >
> > - preliminary scamper-library functions
> >
> > some preliminary library functions to read scamper output files
> have
> > been completed. they are written in an object-oriented style but
> > using C. they have been used to generate reports from scamper
> runs,
> > like those at http://voodoo.cs.waikato.ac.nz/~mjl12/ipv6-scamper/
> >
> > Things to do in the next 12 months (funded by WIDE):
> >
> > - make sure that scamper has the same operational behaviour as
> skitter.
> > scamper needs to be able to detect an unresponsive path without
> > trying up to 32 hops before giving up. scamper also needs to be
> able
> > to write arts files.
> >
> > - scamper PMTU functionality; these need to be completed and made
> more
> > robust than they currently are. code to conduct PMTU on linux
> needs
> > to be added to enable scamper to work on linux. the motivations
> > behind the PMTU functionality are
> >
> > - the ability to identify the placement of IPv6 tunnels. IPv6
> > tunnels might be forwarding bottlenecks in an end-to-end path.
> > TCP transfers take extra partial-RTTs to set up when faced with
> > ICMP packet-too-big messages. Some paths contain multiple
> tunnels
> > with different MTU properties, increasing the initial delay. We
> > can find and report the current PMTU of paths, and find out
> where
> > the changes occur in the path.
> >
> > - to identify router units by interface grouping. IPv6 TTL
> messages
> > originate from the interface the packet was received on. IPv6
> MTU
> > messages _may_ originate from the outgoing interface that has
> the
> > MTU restriction.
> >
> > - optimise scamper's operation; scamper seems to work quite
> acceptably
> > at 50 packets-per-second, although I am not confident it will scale
> > to 500 packets-per-second as skitter currently does, as the
> > traceroute window is a linked list ordered by start time. this
> seems
> > to be a rather simple thing to fix.
> >
> > - scamper-library functions; scamper's library functions have to be
> > extended to read the existing skitter arts files, but without using
> > the arts library. the library must also be able to handle IPv6
> > addresses. the functions also need to be able to report on
> optional
> > information collected, like MTU values. we need to come up with a
> > flexible method for storing exotic data in the arts traces, such as
> > MTU values, rather than making special cases.
> >
> > - skitterise scamper - as in make scamper operate with the existing
> > skitter architecture that handles data collection from skitter
> > monitors. this involves updating sdcollect and sdserver to use the
> > new scamper library.
> >
> > Plans:
> >
> > - the source to scamper should be released. I'd like to start
> > releasing when scamper-0.9.4 is complete.
> >
> > - use the scamper data to identify 'better' routes to follow. Many
> > sites choose shortest AS path as the route which is likely to
> perform
> > the best. If we are able to collect scamper views where we can
> > identify different paths between the same IP addresses, maybe we
> > could devise a method to identify 'better' routes from variables
> such
> > as RTT and MTU, which is data we collect with scamper. this is
> > fairly weak, but perhaps a start.
> > [ see : http://www.cs.ucsd.edu/users/savage/papers/Sigcomm99.pdf ]
> >
> > Possible extensions:
> >
> > - TCP traceroute. Sites may block UDP probes to high-numbered ports
> > and may be more likely to let probes to port 80 through. some
> > discussion is needed before this is looked at.
> >
> > ----- End forwarded message -----
> >
>
> ----- End forwarded message -----
>
>
>
> ----- End forwarded message -----
----- End forwarded message -----
--
Bradley Huffaker Terrorism is the price of Liberty
CAIDA/SDSC/UCSD Tyranny is the price of Security
More information about the Scamper-dev
mailing list