ietf
[Top] [All Lists]

Re: A follow up question

2003-04-23 19:59:23
Keith,

I am going to try to address the pieces of this that weren't covered --in a context I'm more comfortable with-- in my response to Tony's note.

--On Wednesday, 23 April, 2003 21:31 -0400 Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> wrote:

Daniel Senie writes:

> Separately, if there is genuine interest in addressing the
> scoping problem, I suggest that be addressed separately.

I guess it depends on what you define as "the scoping
problem".  If the problem is that the network can impose
apparently arbitrary restrictions on whether hosts can
communicate between point A and point B (for arbitrary A and
B) I don't see that as an architectural problem, nor something
that should be the responsibility of applications to solve.

and if you define the problem as that hosts are expected to be
able to simultaneously have access to multiple scopes that
must be accessed via different source addresses or different
network interfaces or different tunnels, and to be able to
provide connectivity to each of those for applications on that
host, I still have to question whether giving each scope a
separate address prefix is a constructive way to implement
that.

Here, I have to agree with Tony, or at least a position I think Tony would take.

We have two very serious network problems right now. There are probably others (I could even name some candidates), but let's concentrate for the moment on these two.

        * We don't have a routing architecture that is
        independent of the structure of IP addresses.  I wish we
        did.  I think the fact that we don't is going to lead us
        into [other] very serious problems in the long term.
        But the fact remains that we don't have anything
        resembling an IP-address-independent routing fabric
        proposal on the table, certainly not one that is
        complete enough to be plausible.
        
        * We are seeing more and more requirement for
        multihoming of one type or another, whether you count
        community wireless schemes or other small-group or
        small-ISP models into the mix or not.

One implication of the first problem is that one can't solve the second one by giving everyone who wants to connect to more than one provider independently-routable PI space. Now, if we don't come up with a solution to both of those problems, it doesn't make any difference what features are in IPv6, because IPv6 will fail, and it will fail because the Internet --at least the Internet as we know it-- will fail. I think we even know what the alternative looks like, at least in general terms, with islands of walled gardens, each with independent address spaces, and connected by bilateral agreements being the most likely of those alternatives. Those proposals have been around for years, we know what they look like, and they don't provide the edge-oriented, end-to-end, "dumb" network we all believe is the core strength of the Internet.

So, while I've got serious misgivings about site-local (partially because I think I'd prefer to see globally-unique addresses even if they can only be routed locally and partially because I see "local" as a hierarchy), and have as little (or less) desire to see applications obligated to screw around in topology as you do, I'm not willing to give up on multiple addresses per host, or multiple prefixes, unless there is a clear proposal for an alternative on the table.

At least so far, "give every host one address and let the network (the routers?) sort out the routing" seems to me to reproduce the current IPv4 situation. That doesn't seem to me to be a solution because it:

        * Assumes that everyone who has a LAN that they want to
        connect to multiple providers will have routable PI
        space.  Or
        
        * Assumes that everyone who has a LAN that they want to
        connect to multiple providers will be able to do so by
        punching holes in CIDR blocks.

From my perspective, those two approaches don't scale. Or they
scale only at the price of assuming that only those with huge networks (or enough resources to convince backbone ISPs to violate CIDR and polute routing tables with small blocks) deserve to multihome. The latter violates my religion about the network, your mileage may differ.

John Klensin writes:

Tony, I think this pretty well reflects where I've found
myself  going on this, fwiw.   From an applications
standpoint, the  scoping issues, and what is, or is not,
"topology information",  just obscure the problem.  "The
problem", from an applications  point of view, is that, if we
are going to stop pretending that  the address space is
completely flat and global --and I agree  that to do
otherwise is unrealistic at this stage-- then we need  a
model by which the application can specify to the stack what
it needs/ expects, and the stack can tell the application
whatever the latter really needs to know about what is
happening.

I don't see why it's unrealistic to have a global address
space that encompasses all hosts that are connected any
network that is connected to the Internet, and to expect
applications to use that global address space.  I agree that
we cannot expect complete or near-complete connectivity.

But, if we have a one-address-per-host global address space -- which I think is what you are asking for-- and don't have near-complete connectivity, then we are either going to see rising times to set up the typical TCP connection, and a lot of UDP attempts fall off the edge, or we are going to need a lot more PI space. I don't see realistic alternatives for the reasons discussed above. Do you? And, if so, what are they?

In my mind, the reason we need feedback from the network to
applications about when applications try to violate
administrative prohibitions on use of the network is not so
that applications can try to route the messages through other
paths (though it does enable that to some limited degree) but
so that applications can provide accurate indications to their
users as to why they're failing.

Keith, while I'm very much in favor of accurate feedback, messages with the ultimately semantics of "you lose" have a long and well-documented history of being unpopular with users. In that regard, while they inspire rather different families of sick jokes, there really isn't much difference among a cute cartoon of something crashing and burning; getting a message containing network gobblygook about timeouts, firewalls, or address scopes; having a code of a few letters, several digits, and another letter or two appear after the codeword "reply"; or suddening seeing a blue screen with possibly-irrelevant nonsense in white characters in the middle. I'd rather focus on getting the network to work better and more often, while reporting accurately on failures if there is no alternative but to fail.

ICMP, as now defined and used, won't help with the
problem for a reason much more pervasive than the one Daniel
and  others have identified: most of our current applications
have no  interaction with either ICMP or IP -- they call on
TCP or UDP  functions and don't know about the internet
layer.  The Internet  layer doesn't have any path (by
"signalling" or otherwise) to  pass information back to the
apps.

I don't see why TCP and/or UDP stacks can't provide such
interfaces to applications, even though of course this means
that there will need to be other interfaces (invisible to
applications) between TCP and IP and UDP and IP to pass that
information upstream.

They can't provide it because we don't have a model, or set of abstractions, for providing it. If it is important, maybe we had better get started.

So, I would suggest that we really do have a problem here.
Unless we have a realistic proposal for a routing fabric that
is  not dependent on the addresses used, the solution-set
almost  certainly includes being able to use multiple
addresses per  host, with different semantics associated with
those addresses.

the solution set to what?  I don't see what problem this is
attempting to solve, but I do see lots of problems that this
creates.

See above and the note to Tony.

As the competence level of the average ISP declines (which
seems  to have been a clear trend for the last several
years),  multihoming (in some form) needs to increase as the
only  satisfactory alternative... and it better not be only
for the  rich or the huge.  The idea of a single,
exclusively-global,  flat address space has been history for
years; we clearly aren't  going to get back there as long as
different providers charge  differently for different paths
(independent of any of the  enterprise localization,
firewall, RIR-granted PI space, or  other issues).

radical idea: we need to get away from the notion that the IP
address is a path specifier and back to the notion that an IP
address is a location or interface identifier or (possibly
virtual) host identifier.

Sure. Good idea. I anxiously await your I-D for how we are going to route packets from host to host if we make that change.

But, unless we are prepared to discard the model of a layered
stack architecture, or accept our applications becoming as
(or  more) complex and knowledgeable about network
architectures as  switches get in the PSTN, then we should be
looking at stack  abstractions that permit applications to
express their needs,  and get information back, without
deducing network topology,  transport or mobility economics,
etc.

I don't think these things need to be provided in the "stack"
at all - for the same reason that apps don't want to cope with
them - neither the host nor the app has the information needed
to make those decisions.  and lacking a uniform address space,
there's no basis for lower layers to make the decisions.  (for
some reason a potentially-changing set of IP addresses doesn't
strike me as a good endpoint identifier for any layer)  so we
need a uniform location name space to be used by higher
layers, and we need for the network to make the path selection
decisions.  now maybe these decisions need to be made at
border routers rather than core routers (so that finer details
of path selection are handled in the periphery where you get
better scaling, and the core routers just forward things along
pre-determined paths) but you don't want to push the routing
information all the way to hosts.

I'm not sure about all of the implications of this, but it is quite possible that we agree. But there is no way I can evaluate the above without a real proposal. There, the advocates of multiple prefixes have a very considerable advantage over these speculations in the form of documents on the table.

        john


Keith







<Prev in Thread] Current Thread [Next in Thread>