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:
>
> 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
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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 PROTECTED]
Ethernet address: 00-00-AC-CF-5B-82
