RE: LSRR traceroute packet acceptability

Stefan Savage (savage@cs.washington.edu)
Tue, 22 Sep 1998 14:13:18 -0700

I don't think there's anything inherently wrong with using lsr... we
just have to be careful to design our experiments around its
limitations.

I think LSR is still a fine way to establish that alternate routes are
better. If you can get from A to B faster using a LSR-based route then
the normal route then that is valid (since LSR can only be slower than a
real route). So experiments where we test routes from:
UW<---normal--->X vs UW<---lsr--->X
seem valid.

Its also interesting to know just how much LSR support is out there.

However, I'm not sure we can gather the kind of n^2 data that John was
gathering because of the noise between lsr comparisons.

- Stefan

-----Original Message-----
From: Kenichi Ishikawa [mailto:ishi@cs.washington.edu]
Sent: Tuesday, September 22, 1998 2:08 PM
To: Stefan Savage
Cc: Neal Cardwell; syn@cs.washington.edu
Subject: RE: LSRR traceroute packet acceptability

I was not aware of the difference of behavior between normal and
LSR packet.
Thank you for pointing out that.

Hmm... I'm also confused.

--
Kenichi Ishikawa


On Tue, 22 Sep 1998, Stefan Savage wrote:


> I'm confused about exactly how we hope to use LSR for measurements.
The
> classic problem with LSR is that intermediate routers do not process
> them on the "fast path".  They are not routed on the line cards but
are
> frequently shunted to a much slower host processor.  Consequently,
these
> packets will traverse the network slower than regular packets and are
> more likely to be dropped.  
> 
> Its seems like LSR paths can be used as a lower bound when compared
with
> normal paths (ie a lsr path will only be slower and lossier than a
> normal path).  However, I'm not sure how reasonable it would be to
> compare metrics for two lsr paths (since the metrics will differ due
to
> router architecture, load on the host cpu, etc...).  Am I
> misunderstanding the experiment?
> 
> - Stefan