Subject: Re: IP network address assignments/allocations information?

From: Jessica Yu <[email-masked]>
Date: Thu, 16 Dec 1999 13:39:34 -0500

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

Date: Tue, 14 Dec 1999 15:26:59 -0500
To: Jessica Yu <[email-masked]>
From: Christian Huitema <[email-masked]>
Subject: Re: IP network address assignments/allocations information?
Cc: [email-masked]
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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Dec 1999 16:46:16 -0600

This topic is an active work item in the IPNG WG
right now and there is an active address selection draft
(draft-ietf-ipngwg-default-addr-select-00.txt). But I certainly
don't expect the host to choose based on current network outages;
that is a problem for the routing system.

DNS doesn't make a choice. If there are multiple addresses,
it returns all of them. The host makes the choice.

   Brian

Jessica Yu wrote:
> Return-Path: [email-masked]
> 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-masked]>; 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-masked]>; 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-masked]>
> X-Sender: [email-masked]
> X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
> In-Reply-To: <[email-masked]>
> Mime-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"
> Content-Length: 3725
> 

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Attend INET 2000: http://www.isoc.org/inet2000
Non-IBM email: [email-masked]
Ethernet address: 00-00-AC-CF-5B-82

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Dec 1999 16:46:16 -0600

Brian

---

From: "David R. Conrad" <[email-masked]>
Date: Thu, 16 Dec 1999 17:13:35 -0800

Brian,

> it returns all of them. The host makes the choice.

Let me introduce you to today's current crop of DNS-based load balancing
"solutions".  For example, from
http://www.resonate.com/products/global_dispatch/faqs.php3:

How does Global Dispatch relate to DNS architectures?

Global Dispatch is an authoritative DNS solution- meaning that it integrates
into a DNS architecture- but actually replaces existing 'dumb' authoritative
DNS capabilities. The Global Dispatch scheduler sits behind an existing
authoritative DNS server, such as BIND or Microsoft's DNS server. Global
Dispatch resolves a virtual hostname into the IP address of a physical POP.
When a client's local DNS server makes an address resolution request for a
virtual hostname, Global Dispatch responds with the IP address of the most
available physical POP based on latency and load information it receives from
agents installed at each POP.

Rgds,
-drc

---

From: "David R. Conrad" <[email-masked]>
Date: Thu, 16 Dec 1999 17:13:35 -0800

Brian,

Rgds,
-drc

---

From: Jessica Yu <[email-masked]>
Date: Fri, 17 Dec 1999 08:59:48 -0500

>But I certainly

I do not agree with this statement. But detailed technical discussion 
should propabably go to the WG discussion instead of this general 
mailing list. I will bring the issues to the proper working group 
discussion.

cheers!
						--Jessica

---

From: Jessica Yu <[email-masked]>
Date: Fri, 17 Dec 1999 08:59:48 -0500

cheers!
						--Jessica

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Dec 1999 09:14:30 -0600

Sure, I'm quite aware that there are many such tricks in use. I may even have helped
to commit one or two of them in my former life. But the architecture of name 
resolution for IPv6 is as I described - if there are multiple AAAA records,
you get multiple answers and the host gets to choose.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Dec 1999 09:14:30 -0600

Brian