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

From: Jessica Yu <[email-masked]>
Date: Tue, 14 Dec 1999 14:07:58 -0500

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.  

So I disagree with those who think it's not a problem in the Internet 
where majority of hosts with multiple addresses. 

						--Jessica  

------- Forwarded Message

Date: Mon, 13 Dec 1999 16:05:48 -0600
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Jessica Yu <[email-masked]>
CC: [email-masked]
Subject: Re: IP network address assignments/allocations information?
Content-Length: 2452

Jessica,

I don't think this is a problem for the routing system. It will deliver to
whatever destination address is in the packet. The problem is for hosts
to choose which destination address to use when there is a choice,
and ditto for the source address.

I don't agree with those who see this as asking the host to guess at
routing decisions. However, it's a complex topic that is already 
an active work item in the IPNG WG.

   Brian

Jessica Yu wrote:
> 
> You seem to disagree with my statement of "routing may not be adequate."
> in the Internet where majority of the hosts with multiple IP addresses.
> 
> Do you really believe that there is an adequate support for the routing
> issue described below in majority-hosts-with-multiple-ip-addresses
> environment?
> 
>                                                 --Jessica
> 
> Date:    Fri, 10 Dec 1999 12:49:57 EST
> To:      Bill Sommerfeld <[email-masked]>
> cc:      Jessica Yu <[email-masked]>, Keith Moore <[email-masked]>,
>          Christian Huitema <[email-masked]>,
>          Sean Doran <[email-masked]>, [email-masked]
> 
> From:    Keith Moore <[email-masked]>
> Subject: Re: IP network address assignments/allocations information?
> 
> Return-Path: [email-masked]
> X-URI:   http://www.cs.utk.edu/~moore/
> In-reply-to: Your message of "Fri, 10 Dec 1999 12:32:18 EST."
>          <[email-masked]>
> Sender:  [email-masked]
> Content-Type: text
> Content-Length: 913
> 
> > > There is also a potential scaling issue of using multiple addresses
> > > as general purpose multihomging mechanism. This is because if this
> > > is the case, most of the Internet hosts will end up with multiple
> > > addresses.
> >
> > I don't see why this is inherently a problem.
> 
> it's a problem because it's essentially asking the sending host to do
> routing in the absence of any routing information.
> 
> if multiple addresses are available for a host, the chances are good
> that the paths associated with some of those addresses are significantly
> better, or worse, than others.  with IPv4 multihoming, the routing system
> sorts out which path to use.  this doesn't work perfectly but at least
> the decision is made in light of some information about the nature and
> current state of those paths.  with IPv6 multihoming, the sending host is
> just guessing.  it's difficult to believe that this will work well.

------- End of Forwarded Message

---

From: Christian Huitema <[email-masked]>
Date: Tue, 14 Dec 1999 15:26:59 -0500

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

---

From: Christian Huitema <[email-masked]>
Date: Tue, 14 Dec 1999 15:26:59 -0500

Jessica,

---

From: John Stracke <[email-masked]>
Date: Tue, 14 Dec 1999 16:29:11 -0500

Christian Huitema wrote:

> The first SYN packet gets lost, and
> the client simply picks another address in the list and tries again.

The APIs I've used don't tell me about lost SYN packets (thank goodness); they
only tell me if the connection has timed out.

> problem. It only affects long connections,

(a) But long connections are important; they're more efficient (and give the
users better performance) than short connections.  Modern application
protocols are being designed with this in mind.

(b) It also affects short connections, just not as often.  If Joe User's HTTP
connection gets dropped, he'll see "Transfer interrupted" and think there's
something wrong with the server (or he'll see a broken image and think the
site's HTML is messed up).  It would not occur to him that the trouble would
be in a transit network; he's probably never heard the term.  So he'll come
away thinking that the Internet is just plain flaky.

> it only makes a difference if a
> connection to a transit provider breaks,

Or if the chosen path becomes congested over time.

> In any cases, there are simple modification to
> better off than in the current situation,

OK.  How long is the long run? How long did it take to get the LFN fixes
deployed? They were described in 1989 (RFC-1106); I seem to remember they
weren't widely available as of 1994 or so.  (My memory may be skewed, though,
because one of the machines I was using was running SunOS 4.x, which wasn't
being updated much.)

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |They prayed for their fates to be quick,     |
[email-masked]|painless, and, ideally, someone else's.      |
\==============================================================/

---

From: John Stracke <[email-masked]>
Date: Tue, 14 Dec 1999 16:29:11 -0500

---

From: Christian Huitema <[email-masked]>
Date: Tue, 14 Dec 1999 17:50:14 -0500

>Or if the chosen path becomes congested over time.

No. This is no different from the present situation. BGP does not recompute
routes in case of congestion. It is a problem that we are stuck with today,
that multi-address multi-homing actually gives us the hope of solving.
-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Tue, 14 Dec 1999 17:50:14 -0500

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Dec 1999 16:25:04 -0800

>that multi-address multi-homing actually gives us the hope of solving.

Only minimally, as long as a TCP connection is tied to an IP address...

d/

ps.  Christian and I separately suggested changing this, to support IP 
mobility, a few years ago.

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Dec 1999 16:25:04 -0800

d/

=-=-=-=-=

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 14 Dec 1999 22:34:42 -0500

> mobility, a few years ago.

indeed, and something like this appears to have surfaced again, albeit
briefly, in the IPNG working group..

see the sep/oct section of http://playground.sun.com/pub/ipng/html/meetings.html
particularly, the "Preserving Active TCP Sessions ( pdf ), P. Tattam "

				- Bill

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 14 Dec 1999 22:34:42 -0500

- Bill

---

From: John Stracke <[email-masked]>
Date: Wed, 15 Dec 1999 22:08:06 -0500

Christian Huitema wrote:

> routes in case of congestion.

But the routers do load balancing, don't they, with the result that a TCP
connection's packets may migrate from a congested path to an uncongested one?
Or is this something that winds up not working in actual practice?

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |We want forty million helicopters and a dollar!|
[email-masked]|--"Dinosaurs"                                  |
\================================================================/

---

From: John Stracke <[email-masked]>
Date: Wed, 15 Dec 1999 22:08:06 -0500