Marcel Waldvogel | 1 Nov 09:15 2004
Picon

Re: Internet path dynamics

Randy,

Thank you for the pointer. Unfortunately, RouteViews still only seems to 
keep track of BGP-level connectivity and changes. The data I would be 
interested in would hop-by-hop (i.e., router-by-router) changes of 
paths. But it seems that no such data is currently available.

-Marcel

Randy Bush wrote:

>http://route-views.org/
>  
>

Jeroen Massar | 1 Nov 09:26 2004

Re: Internet path dynamics

On Mon, 2004-11-01 at 09:15 +0100, Marcel Waldvogel wrote:
> Randy,
> 
> Thank you for the pointer. Unfortunately, RouteViews still only seems to 
> keep track of BGP-level connectivity and changes. The data I would be 
> interested in would hop-by-hop (i.e., router-by-router) changes of 
> paths. But it seems that no such data is currently available.

What about http://ris.ripe.net then? :)

Greets,
 Jeroen

Randy Bush | 1 Nov 18:03 2004

Re: Internet path dynamics

> Thank you for the pointer. Unfortunately, RouteViews still only seems to 
> keep track of BGP-level connectivity and changes. The data I would be 
> interested in would hop-by-hop (i.e., router-by-router) changes of 
> paths. But it seems that no such data is currently available.

marcel,

you are correct.  very isps even gather or keep those data
internally.

randy

Randy Bush | 1 Nov 19:01 2004

Re: Internet path dynamics

> you are correct.  very isps even gather or keep those data
                        ^ few
> internally.

Nischal Piratla | 1 Nov 19:13 2004

RE: Internet path dynamics

Marcel,
You may already know about this forum, if not, you can try asking them for 
such data:
http://www.nanog.org/mailinglist.html
- Nischal

>===== Original Message From Randy Bush <randy <at> psg.com> =====
>> Thank you for the pointer. Unfortunately, RouteViews still only seems to
>> keep track of BGP-level connectivity and changes. The data I would be
>> interested in would hop-by-hop (i.e., router-by-router) changes of
>> paths. But it seems that no such data is currently available.
>
>marcel,
>
>you are correct.  very isps even gather or keep those data
>internally.
>
>randy

/******************************************
Research Assistant
Computer Networking Research Laboratory
Department of Electrical and Computer Eng.
1373, Colorado State University, 
Fort Collins, CO 80523 USA
http://www.cnrl.colostate.edu
http://lamar.colostate.edu/~nischal
*******************************************

(Continue reading)

Dmitri Krioukov | 1 Nov 21:51 2004
Picon

RE: Internet path dynamics

marcel,

could you please point me to the igp-monitoring studies?

thanks,
--
dima.
http://www.caida.org/~dima/

> -----Original Message-----
> From: end2end-interest-bounces <at> postel.org
> [mailto:end2end-interest-bounces <at> postel.org]On Behalf Of Marcel
> Waldvogel
> Sent: Friday, October 29, 2004 4:05 PM
> To: end2end-interest <at> postel.org
> Subject: Re: [e2e] Internet path dynamics
> 
> 
> I am looking for data on how frequently the actual routing path changes.
> I am aware of studies that infer BGP AS route changes and those that
> monitor OSPF messages, but for our work, we would be interested in the
> rate of change to the set of routers on an end-to-end path.
> 
> As I do not want to flood arbitrary sites with constant traceroutes (see
> the "probing and laws" thread) nor limit myself to skewed subsets (such
> as PlanetLab), I would appreciate pointers to existing data sets.
> 
> -Marcel
> 
> >You may find:
(Continue reading)

Jing Shen | 2 Nov 12:29 2004
Picon

Re: Internet path dynamics

If OSPF-ECMP or similar technique is used, you could
find route swan between routers between packets.
I met such thing when trying to traceroute to a
Japanese server.

Sometimes route table analysis may not be adquate
because even packet flow through the same router the
address it shows may be different ( PBR or load
balancing configurations). 

regards

jing shen

> I am looking for data on how frequently the actual
> routing path changes.
> I am aware of studies that infer BGP AS route
> changes and those that
> monitor OSPF messages, but for our work, we would be
> interested in the
> rate of change to the set of routers on an
> end-to-end path.
> 
> As I do not want to flood arbitrary sites with
> constant traceroutes (see
> the "probing and laws" thread) nor limit myself to
> skewed subsets (such
> as PlanetLab), I would appreciate pointers to
> existing data sets.
> 
(Continue reading)

Jon Crowcroft | 4 Nov 10:13 2004
Picon
Picon

NAT traversal for src+dst routing

File this under
Truly Horrible Idea/Concept/Kludge (T.H.I.C.K.)

reading some stuff recently about how MPLS can be used to do various
traffic engineering hacks that "cannot" be done  with normal IP
forwarding as it would need source+destination, which we "know" doesnt
scale (if there's an algorithm for labels, i dont quite see why an
algorithm for fast longest prefix packet classification doesnt just
double in time/space for src+dst given both are in the FIB anyhow, but 
hey...)

so i was also reading about various cute NAT traversal hacks (many
aimed at allowing incoming SIP signaling for end-customer VOIP calls
etc....

so one can combine these - if a provider has a set of destination 
prefixes that are used to share out load over various paths, then one 
can achieve src+dst routing by looking at the _source_ of the call at the
application layer hack that triggers the nat traversal, and put in a
NAT globally reachable address on the public  side from the
appropriate _destination_ prefix in - then the src is irrelevant - but
different sources or potentially the same source with different calls
are going to different "destinations" 

i.e. a NAT is a label switch - it operates in a nice part of the
architecture where we (the end users, not the router and swithc
vendors) can still play...

the statefulness of the NAT is no different (in terms of being yucky)
from the statefulness of forwarding equivalence classes - there are
(Continue reading)

Xiaoming Fu | 4 Nov 10:43 2004
Picon

Re: NAT traversal for src+dst routing

Jon,

Binding/Address-mapping state instantiation (as well as maintenance and 
deletion) for NAT devices is being discussed in IETF NSIS WG (previously 
also in MIDCOM); 
http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-04.txt 
describes a soft-state based approach. Is this a way you'd expect?

Cheers,
Xiaoming

Jon Crowcroft wrote:
> File this under
> Truly Horrible Idea/Concept/Kludge (T.H.I.C.K.)
> 
> reading some stuff recently about how MPLS can be used to do various
> traffic engineering hacks that "cannot" be done  with normal IP
> forwarding as it would need source+destination, which we "know" doesnt
> scale (if there's an algorithm for labels, i dont quite see why an
> algorithm for fast longest prefix packet classification doesnt just
> double in time/space for src+dst given both are in the FIB anyhow, but 
> hey...)
> 
> so i was also reading about various cute NAT traversal hacks (many
> aimed at allowing incoming SIP signaling for end-customer VOIP calls
> etc....
> 
> so one can combine these - if a provider has a set of destination 
> prefixes that are used to share out load over various paths, then one 
> can achieve src+dst routing by looking at the _source_ of the call at the
(Continue reading)

Marcel Waldvogel | 4 Nov 16:46 2004
Picon

Re: Internet path dynamics

Dmitri,

the ones I know are due to personal communications and seem to be based 
on informal sources or close personal contacts with ISPs. As such, there 
is really nothing public I can point you to, sorry.

-Marcel

Dmitri Krioukov wrote:

>marcel,
>
>could you please point me to the igp-monitoring studies?
>
>thanks,
>--
>dima.
>http://www.caida.org/~dima/
>
>  
>
>>-----Original Message-----
>>From: end2end-interest-bounces <at> postel.org
>>[mailto:end2end-interest-bounces <at> postel.org]On Behalf Of Marcel
>>Waldvogel
>>Sent: Friday, October 29, 2004 4:05 PM
>>To: end2end-interest <at> postel.org
>>Subject: Re: [e2e] Internet path dynamics
>>
>>
(Continue reading)


Gmane