Subject: Re: [arch-d] It's about Information

From: [email-masked] (Noel Chiappa)
Date: Fri, 8 Dec 2006 11:20:23 -0500 (EST)

> From: Bruce Curtis <[email-masked]>

    > If we imagine a time in the future where every host has 100 Mbps
    > connection to the Internet like some homes in Japan today and we have
    > networks that upport Jumbo frames

Without taking a position on the specific point under discussion, let me push
(again) this particular aspect: in thinking of architecture, try to imagine
it on the hardware of 10 (or more, for networking stuff) years out. If what
you imagine is impossible, or completely uneconomic, on today's hardware, OK,
you have to rethink a bit. However, try to design for tomorrow's constraints,
not today's.

(In processors, this conceptual mistake used to show up in address spaces
that were too small. And don't we all wish the IPv4 header had "wasted" 2
bytes more overhead, been 2 more bytes longer, to have source and destination
address length fields? Etc, etc, etc.)

    > That is, we put all of the destination addresses X,Y,Z in the packet as
    > well as the source addresses A,B,C. So basically we take the
    > information about multiple paths

Minor nit: even if you only have one address on each each end, you can still
have multiple paths.

This point is one I particularly notice because people try and specify paths
using addresses (which is not what's happening here, I know), and it really
doesn't work well. If you want to control paths, control them directly, don't
try and do it indirectly via addresses.

    > out of the routing tables where it doesn't scale and put the multiple
    > path info in each packet

What's happening with the multiple addresses is that you're taking some of
the cost of supporting multihoming and moving it out of the routing, and
moving it elsewhere in the system.

[And from a different message...]

    > I know there have been proposals about having the addresses or locators
    > based on location or GPS and it solved some routing problems ..
    > .. I was thinking of the GPS info as more of an ID than a locator.
    > Sometimes when there is a problem host it would be nice to have it's
    > location info, but there are privacy issues .. as well.

Yup.

    > But one way to use the same model but turn my thinking on it's head is
    > to consider the GPS info as the primary locator and the other multiple
    > locators as ISP specific locators.

Umm, I'm going to call you on your terminology here. We have mostly been using
"locator" to mean "a name that tells you were you are in the network".  Your
geographical location tells you nothing about your connectivity to the
network, or the relationship in the network connectivity (aka "topology") to
any entity you might want to exchange packets. So, I object to calling (or
thinking of) any GPS-derived name a "locator".

	Noel

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Bruce Curtis <[email-masked]>
Date: Fri, 8 Dec 2006 13:08:56 -0600

> Minor nit: even if you only have one address on each each end, you  

    True.  I'm guilty of thinking of this model in terms  of the  
multi-homing issue because that's the problem that led me to think of  
the model.  And one of the issues was that ISPs objected to some  
proposals because they could not do traffic engineering in the way  
they can with the old model.

    If I restate the old model end users have control over the path  
packets take in the first hop when leaving their site and can  
influence which path packets enter their network on the last hop.   
ISPs generally have control over the paths within each ISP network  
and between ISPs that the packet takes.

   It is a bit more complicated than that but that seems to be the  
most common case.

> try and do it indirectly via addresses.

   And with a new model with multiple locators per site people will  
be even more tempted to use locators to specify paths.

   In essence one of the big issues is about control, that is, who  
controls the path the packet takes.  The ISPs have a stake but end  
users also might have preferences.

   If the new architecture gives end users a way to specify the full  
path I could see ISPs requesting features in the packet such as a  
"Allow the ISP to change the requested path" bit.

> moving it elsewhere in the system.

   Right.

> thinking of) any GPS-derived name a "locator".

   I admit to having not looked at it for a while but there were  
proposals to lay out IPv6 addresses geographically  and in that  
proposal IPv6 addresses have geographical hierarchy which kind of led  
me down the path of using the wrong terminology.

   If I think "network locator" rather than the the short hand  
"locator" I can see your point.  Sorry about that.

   I haven't thought through the particular example above but it  
occurred to me while responding to another post on the list so I  
threw it out there for other folks more knowledgeable about ISP  
issues to comment on.

   I guess what I was trying to imagine was if having multiple  
locators plus the GPS info in the packet would allow us to think of a  
model where the GPS info really is sort of a locator not on the real  
network but on a virtual or logical network.  Just trying to think of  
a model that would have some of the advantages of a logical network  
with geographically hierarchy but that really ran on a network based  
on locators that reflect the real network topology.

   One thing that comes to mind is that if the GPS info about the  
source is in the packet then perhaps that could be used for anti- 
spoofing checking rather than the source locator.

---
Bruce Curtis                         [email-masked]
Certified NetAnalyst II                701-231-8527
North Dakota State University