Re: A tunneling proposal

[Geoff Huston <gih@telstra.net>]

At 7/18/01 01:41 AM, Ramakrishna Gummadi wrote:
> > > Economics is a major constraint on the potential solution space.
> >
> > I'm not even talking about economics, but just basic functionality and 
> human
> > nature: how are you going to convince someone stop doing something that 
> works
> > for them to help some greater good, that doesn't show obvious signs of
> > needing help? "Global warming? Let me turn up the airco..."
> >
> > If there really is a limit above which global routing breaks down, we 
> should
> > implement some policies to prevent the number of routes from reaching this
> > limit. This means forcing existing ASes to aggregate, and limiting the 
> growth
> > in the number of ASes. That way, SCTP-like solutions become more 
> attractive.

It would be good if we could say "this is the number of routes in the 
global table which will cause the integrity of the global routing system to 
collapse". Unfortunately we know of no such hard limit. We suspect that 
somewhere between where we are (a little over 100,000) and 4 billion route 
entries (every /32 address fragment is announced globally) there is such a 
limit. Our concern is that we will not know what such a threshold is until 
a number of As's cross it.

>Currently, multihomers pay each their ISPs extra to carry non-aggregatable
>routes. This means if the ISPs encounter problems with the
>additional routes, they are directly going to charge the sites
>more. This way, one can impose artificial constraints on how
>many sites multihome, but this is exactly what we are trying to avoid.


Do you have some evidence of such an arrangement? While I've heard of such 
charging for routing entry schemes in the past I've yet to see it become 
commercially viable in a heavily contested IP transit market. Your comment 
suggests that such a scheme has become commercially viable in some IP 
transit markets, and it wouldbe interesting to learn more about such a 
development.


>As for backpatcing TCP to work with multihoming, this would
>not work with the current apps, and socket API if done the SCTP
>way---SCTP requires the apps to *explicitly* give a list of addresses
>to use on a connection. To backpatch TCP to do the same would mean
>requiring the TCP layer itself to figure out what additional addresses
>it can use *without* the app knowledge. This means that the protocol
>stack can get it wrong if there is address translation going on
>for getting provider independence, etc...
>Ultimately, it will basically look like GxSE...


The problem is that multi-homing may be a number of AS's away. i.e. the 
local AS may single-home to an upstream AS which in turn may multi-home to 
a number of AS's via peering connections, multiple upstreams, etc. How then 
does the local TCP session  understand the situation if the upstream AS is 
doing multi-homing via dynamic translation of the routing goop part of the 
end point's address?

regards,

   Geoff