Re: updating GSE for the new millennium

[David Conrad <david.conrad@nominum.com>]

Peter,

On Thursday, May 1, 2003, at 03:36  AM, Peter Tattam wrote:
> > I gather your view is different?
> yes, radically.  What you describe is a semi static view of the 
> network.  In
> reality, you have to pick which one of the mappings is suitable to 
> translate.
Yes.  Even in the semi static view (as you put it), you need to pick 
one out of set of potential locators provided to you by the destination 
site.

> It is not possible for the advertising site to determine this because 
> the
> best path to reach that site will depend on where you are in the 
> internet.
True.  I would think, since the destination site is doing the 
advertising, it would be useful to include some 'advisory' information, 
e.g., if all other things are equal, choose locator X instead of Y (or 
choose X for 60% of flows, Y for the rest, or whatever).  Of course, 
this is just advisory information.  It is the source site which is 
making the decision as to what aggregation locator is chosen and there 
can be numerous contributing factors to that decision depending on what 
information is available to the chooser.

> This choice can only be made based on either tracing all possible 
> paths to the
> site, or relying on information gathered about the network.
Of course, by the time you have traced all possible paths, it is 
possible new paths have been established, old paths are out of date, 
etc.  Information gathered about the network can be out of date by the 
time it is collected.  Etc.  In other words, it is simply impossible to 
know the full state of the network at any given point in time.  The 
_only_ thing you can know is what a snapshot of the network looked like 
within some window of time.

Pragmatically speaking, at any given instant, I would argue that the 
vast majority of the end to end connectivity states, that is, whether A 
can reach B regardless of the path between A and B, do not change.  We 
should optimize for that.  A simple, easily implementable solution that 
optimizes for the normal case but continues to work, albeit potentially 
sub-optimally, in the exceptional cases is, I believe, what we should 
be aiming for.

> I think this is a
> point which is constantly overlooked in the debate over MH solutions 
> which
> rely on some kind of mapping tables.
I am not overlooking it.  I have made a conscious decision to focus on 
pragmatism instead of trying to come up with a generic optimal solution 
as I would contend people have been looking for generic optimal 
solutions for a decade now and we have gotten nowhere.

SIP (not Session Initiation Protocol) could have included a wide 
variety of bells and whistles to try to address every possible new and 
sexy idea people had come up with (53 byte packets anyone?).  The 'S' 
in SIP didn't stand for "Steve's", after all...

> Try a few examples of a complex MH network with both ends being nulti 
> homed and
> on opposite sides of the DFZ and you should understand what I am 
> getting at.
I have.  I'd be very interested in discussing (perhaps offline) the 
scenarios you believe wouldn't work with this model.

As an aside, whether a source is multi-homed is, I would argue, 
irrelevant.  A packet hits the border, a lookup in the mapping table 
(however it is propagated/fetched) is done to translate the 
_destination_ site identifier into an aggregation locator.  The source 
address is ignored.

> I have mention the push vs pull approaches to distributing the MH 
> information.  I
> still contend that because of routing topology, a simplistic view like 
> DNS
> won't fly IMHO.
I am not religious.  I think simple is good, but if it can be 
demonstrated it isn't sufficient, then more complex alternatives should 
be explored.

Again, these are just some back-of-envelope type thoughts.  I'm sure 
there are holes here.  Pointers to them would be appreciated...

Rgds,
-drc