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>
|
- Re: A follow up question, (continued)
- Re: A follow up question, Keith Moore
- RE: A follow up question, Tony Hain
- Re: A follow up question, Keith Moore
- Re: A follow up question, Valdis . Kletnieks
- Re: A follow up question, S Woodside
- Re: A follow up question, Keith Moore
- Re: A follow up question,
John C Klensin <=
- Re: A follow up question, Keith Moore
- RE: A follow up question, Tony Hain
- Re: A follow up question, Keith Moore
- RE: A follow up question, Tony Hain
- Re: A follow up question, Keith Moore
- Re: A follow up question, Dave Crocker
- TCPng/ multiple addresses per node (was Re: A follow up question)_, Alain Durand
- Re: A follow up question, Stephen Sprunk
Re: A simple question, Bob Braden
|
|
|