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 intellegently choose the
>ip address as the source address to send packets or DNS intellegently
>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
