The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Sep> msg00514



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Any SPs using QoS ???

  • From: Ping Pan <pingpan@research.bell-labs.com>
  • Date: Fri, 29 Sep 2000 13:01:44 -0400
  • CC: Ping Pan <pingpan@cs.columbia.edu>, Randy Bush <randy@psg.com>, mpls@UU.NET
  • Organization: Bell Labs, Lucent

Olivier Bonaventure wrote:
> 
> 
> Some time ago, we looked at the BGP routing table of the Belgian research ISP and
> found a similar result. We looked at the number of reachable IP addresses
> (i.e. IP addresses announced through BGP) and found that most
> addresses were between two and 5 AS away from our small ISP.
> 
> LEVEL = 1  ADDRESSES =  43131944
> LEVEL = 2  ADDRESSES = 177739421
> LEVEL = 3  ADDRESSES = 410798057
> LEVEL = 4  ADDRESSES = 347784802
> LEVEL = 5  ADDRESSES = 114262352
> LEVEL = 6  ADDRESSES =  14626560
> LEVEL = 7  ADDRESSES =    943360
> LEVEL = 8  ADDRESSES =    235264
> LEVEL = 9  ADDRESSES =      4352
> 
> This concentration of the addresses is probably due to the fact that BGP
> prefers shortest path (measured in AS path length) and thus ISPs tend
> to establish as much peerings as possible to obtain short paths.
> I'm not convinced that the shortest path in terms of BGP path length
> is the best path, but that's how the market it working today.
> 

Hi,

I am not sure shortest path is the default routing policy used by the
ISP's. But you also have to take two more things into consideration:

1. The AS-path information is what has been advertised by BGP. The
actual AS-path taken by data may be shorter depending routing
computation at border;
2. On the other hand, as I have noticed from a backbone route dump
months ago: the AS number received at border may be small due to *route
aggregation*. In reality, BGP route trace may not give us all the ISP
networks.

What will useful as an exercise is to run traceroute to/from many places
in the world, and take the results against the AS info in RADB. That may
give us better answer on the exact traversing ISP networks....

> Concerning QoS, an interesting point was mentionned this week at the COST263 QoS
> workshop in Berlin, Germany by the IETF chairman (Fred Baker). Today, the main factor
> againts the development of interdomain QoS are the ISPs themselves. They don't believe
> that having interdomain QoS is the best solution from their selfish marketing/economical
> point of view and they are relunctant to work on this topic.

That may not be ISP's fault. One critical issue is: how much data do you
want to reveal to your peers? You are inviting for trouble if you start
to propagate private peering information around.

Also, I feel that one of the major problems for Internet-wide QoS is the
protocols and the tools that we have. Unless we start to re-evaluate
what we have and present a better picture to the ISP's, they are not
going to risk their business to support a solution that is not reliable,
secure and scalable. 

The Paste solution from Yakov and Tony Li was a nice start. Please take
a look. 

Also, we have been working on an inter-domain solution based on some
measurement and the basic knowledge we had on ISP. Please check
http://www.cs.columbia.edu/~pingpan/projects/bgrp.html, and please
provide feedback.

- Ping

> Since ISPs (at least big ones)
> are not interested in interdomain QoS, network providers do not work on enhancing protocols
> to support interdomain QoS since they don't see a business case for such features today.
> The presentation is available from http://www.fokus.gmd.de/events/qofis2000/slides/25ix00/session-00/fred-baker-new.pdf
> 
> My personnal feeling is that interdomain QoS is key to the deployment of QoS within
> the Internet. We won't really have QoS until we manage to find a suitable interdomain
> method to provide it. I guess that small ISPs could have a strong interest in
> such interdomain QoS, but they usually don't have people able to influence the work
> within IETF or network equipment vendors.
> 
> Olivier Bonaventure
> 
> ---
> http://www.infonet.fundp.ac.be