Christian,
First all of, it's good that we agree that we have a problem or
problems to solve. Whether I overstated the problem or you
under-estimated the problem is yet to be seen.
In your message, you did not address the issue of how a host
intelligently choose one of its multiple ip addresses as its source
address when initiate a connection. This is an issue. For example,
a host X with two IP addresses A1 and A2. When it sends a packet to
host Y, it chooses A1 as source address, that means Y will use A1 as
destination address when sending traffic back to X. If at the time,
A1 is not routable at Y's network, (due to outage,etc.), Y will not
be able to send traffic back to X resulting no reachability between
X and Y. At all this time, A2 could be perfectly routable from Y's
network, should X choose A2 instead of A1 as its source address, Y
would be able to send traffic back to X thus communicating with X.
X picked wrong address as source address simply because if has no
routing knowledge beyond its local network. In short, we can have an
unnecessary outage just due to the fact that host picking 'wrong' address.
This will potentially complicate trouble shooting or cause confusion.
E.g. X can not reach Y due to the problem described above while at the
same time, traffic initiated from Y can reach X with no problem
because from DNS Y got A2 as destination to reach X. One can image
other trouble shooting confusions resulting from multiple addresses
per host, especially the majority of the host in the Internet with
multiple addresses.
Other part is that host X in the example has to get an IP address
associated with Y to use as destination address to reach Y. It will
query DNS and DNS will return an IP address.
You seems to indicate that there are two ways of doing this : 1) DNS
intelligently determines which path is less congested and picks
the appropriate address and 2) DNS just randomly picks one address
among multiple addresses associated with a host.
For 1), how does DNS gain knowledge of congestions of networks
along the path? The congestion picture changes frequently, how
how often will the knowledge get updated? I do not believe any such
mechanism is defined at this point and it'd be interesting to see a
mechanism that works and is scalable.
********
Random selection of address is easier but it introduces unpredicatable
behavior: a host will take different path to send traffic to the same
destination host depending on what address DNS picking. Unpredicatability
is always not friendly to operation and trouble shooting. In comparison
to BGP, it picks routes in a predicatable fashion based on well known
rules of BGP and network administrator's policies.
Also, in both random selection or picking based on congestion cases,
DNS should pick an address which is routable at the time. How does a
DNS server know if an address is routable several hops away? It needs
to have routing knowledge. Then how DNS get Internet routing knowledge
and how often will it be updated? Again, it'd be interesting to see
a proposal which works and scalable.
cheers!
--Jessica
------- Forwarded Message
Return-Path: [EMAIL PROTECTED]
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25])
by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id PAA07772
for <[EMAIL PROTECTED]>; Tue, 14 Dec 1999 15:32:13 -0500 (EST)
Received: from breeze.research.telcordia.com (breeze-fddi.research.telcordia.com
[192.4.5.9])
by mail.nyp.ans.net (8.9.3/8.9.3) with ESMTP id PAA20805
for <[EMAIL PROTECTED]>; Tue, 14 Dec 1999 15:32:08 -0500 (EST)
Received: from mailee.research.telcordia.com (mailee [192.4.7.23])
by breeze.research.telcordia.com (8.9.3/8.9.3) with ESMTP id PAA22236;
Tue, 14 Dec 1999 15:30:46 -0500 (EST)
Received: from pluto.cc.telcordia.com ([128.96.14.7])
by mailee.research.telcordia.com (8.8.8/8.8.8) with SMTP id PAA12656;
Tue, 14 Dec 1999 15:30:43 -0500 (EST)
Received: from uunet-14-7.cc.telcordia.com ([128.96.14.7]) by pluto.cc.telcordia.com
via smtpd (for mailee.research.telcordia.com [192.4.7.23]) with SMTP; 14 Dec
1999 20:30:36 UT
Message-Id: <[EMAIL PROTECTED]>
X-Sender: [EMAIL PROTECTED]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Tue, 14 Dec 1999 15:26:59 -0500
To: Jessica Yu <[EMAIL PROTECTED]>
From: Christian Huitema <[EMAIL PROTECTED]>
Subject: Re: IP network address assignments/allocations information?
Cc: [EMAIL PROTECTED]
In-Reply-To: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Length: 3725
At 02:07 PM 12/14/99 -0500, you wrote:
>Brain,
>
>Looks like we have a teminology issue. Notice I did not say routing
>system but ROUTING will have problem. Because the choice of a
>multi-addressed host to use one of its IP address to include in
>packet header implies routing decision, the host, in effect, does
>some routing decision making. How a host intelligently choose the
>ip address as the source address to send packets or DNS intelligently
>choosing an ip address for a query are complex issues which we do not
>have an answer for as you indicated in your message.
Jessica,
I believe you overstate the problem. To begin with, a domain manager is
never obliged to advertize all possible routing prefixes for all its hosts.
In principle, it will only advertize those network connections that are
deemed "good enough." So, at a 10,000 feet level, picking an address at
random in the list, without any information whatsoever, gives you a
connection that may not be optimal, but is probably reasonable. Which means
that the proverbial "five lines client", which presumably will transfer 5
packets, will get adequate service. You will tell me that this may not be
optimal, but then, explain me exactly how the current BGP fabric guarantees
that routes are picked optimally? In fact, in their communication at the
last ACM SIGCOMM conference, "On Estimating End-to-End Network Path
Properties", Mark Allman and Vern Paxson observe that it is quite frequent
for interdomain routing to converge on a less than optimal route today.
The question indeed arises when one of the addresses in the list goes
through a provider that is experiencing heavy congestion. Let's first
remark that, if clients were to pick addresses at random from a list, we
would obtain automatically some level of traffic spreading, which would
generally tend to ease congestion -- but we all agree that congestion will
not be eliminated. If the congestion is already present at the beginning of
the connection, the answer is simple. The first SYN packet gets lost, and
the client simply picks another address in the list and tries again. Again,
this may not be optimal, but it will provide an adequate solution for even
the most brain dead of clients. The smart clients will no doubt find how to
resolve the problem in a smarter way.
So lets focus on the remaining part of the problem. What happens if a
client picks an address at the beginning of a connection, only to find out
that the transit networks are becoming congested. There are solutions,
which require minimal adaptation to TCP. An example is discussed at
http://www.chem.ucla.edu/~beichuan/etcp/; another solution is developed as
part of MobileIP. Indeed, if there is no modification to TCP, there is no
good solution. But then, this is not very different from the current state
of the art. a TCP connection can only survive the loss of a transit network
if BGP manages to detect and correct the loss faster than it takes for the
TCP timers to break. If I believe the recent reports to Nanog, this is far
from guaranteed today.
So, yes, we have a problem. We need to somehow adapt the TCP stack to
survive losses of transit networks. But we should not overstate that
problem. It only affects long connections, it only makes a difference if a
connection to a transit provider breaks, and if the routing tables could
have been repaired by BGP. In any cases, there are simple modification to
TCP, for which we already have some experience, that could handle the
problem. In the long run, once these modifications are in place, we are
better off than in the current situation, because we will rely less on the
speed at which interdomain routing converges.
- -- Christian Huitema
------- End of Forwarded Message
