Subject: Re: Death of the Internet - details at 11

From: Dave Crocker <[email-masked]>
Date: Sun, 1 Feb 2004 11:39:40 +0900

Randall,

>>Let's see.  I get a CIDR network address from one provider.  I get
>>another from another.  I can have my BGP announce both of them all the
>>time or one of them at a time.  I guess I do not see the horrible
>>scaling problem.

RRSh> The scaling problem shows up when you tell the provider of ISP-1
RRSh> to announce a route for the other address... this effectively
RRSh> becomes a "host route" being advertised....

Why would the provider of ISP-1 need to announce a route for the other
address?

And, of course, my own answer is that they would not need
to do this.  The entire point behind having multiple A record
addresses to the same host is so that each address is advertised by
the ISP that assigns it, thereby permitting normal cidr aggregation.

There's an I-D that just came out about this topic
(draft-huitema-multi6-hosts).  It also discusses issues raised by this
approach.

RRSh> But of course the whole point is that we don't need this.. at least
RRSh> not with SCTP

There is a small matter of getting 500 million hosts to convert to
SCTP and then to convert all Internet applications over to it.

So, some additional techniques might be helpful.

For what it's worth, SCTP certainly provided the template for the MAST
proposal and, I would say, exemplifies the control and security model
that is used by several of the candidates.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 1 Feb 2004 12:56:50 +0100

On 31-jan-04, at 2:14, Armando L. Caro Jr. wrote:

>> That's why I think it makes more sense to backport the SCTP 
>> multihoming
>> features to TCP so all TCP apps can use them without having to be
>> changed, or even better: contain the changes in a separate shim layer
>> so that all transport protocols can become address agile without 
>> having
>> to be changed.

> TCP maintains congestion control
> information about a single destination, with the assumption that the 
> path
> will not change during the connection. If it does occasionally, then 
> it's
> fine. However, with multihoming, the change may be a common occurance
> throughtout the lifetime of a connection depending on the application 
> and
> the use of the multiple paths (failover, concurrent multipath transfer,
> etc). So TCP (or whatever transport) should not be blind to the fact 
> that
> data is potentially going over a different path. Otherwise, the 
> congestion
> control parameters/algorithms will not work properly.

I don't think path changes are _that_ common with multihoming, either 
today or with a new protocol. In my ODT draft path changes only occur 
when the primary path fails in the first place, as this way the session 
can be compatible with regular TCP (or other upper layer protocol) if 
there are no failures.

> Also, since the transport is maintaining per path information, it is in
> the best decision to decide which path to use. Yes, a shim layer could
> cooperate with the transport to get this info, but then you are 
> changing
> TCP anyway.

I see three steps in the evolution of a shim approach:

1. Implementation in proxy multihoming boxes
2. Implementation as a shim layer in host stacks
3. Integration of the shim layer and common transport protocols

The idea is that a type 1 implementation can work together with a type 
2 or 3 implementation.

> I must admit that I haven't following the multi6 too closely yet, but I
> plan to catch up and follow. But from what I have seen, it seems that 
> SCTP
> is ignored on the sidelines.

Actually the chairs went out of their way to get an SCTP multihoming 
draft in before the deadline. The deadline for submitting drafts that 
would be considered has recently passed, so now is a good time to read 
the drafts and join the architectural analysis that should be starting 
shortly.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 1 Feb 2004 07:02:51 -0600

Agreeing with what Iljitsch said, with the addition that the
"deadline" was imposed to get people to submit proposals so the
working group had something to discuss, not to exclude proposals that
show up two weeks later.

The chairs made explicit requests on the mailing list to ANYONE to
submit an SCTP multihoming draft, so SCTP won't be excluded.

Spencer

From: "Iljitsch van Beijnum" <[email-masked]>

---

From: Eliot Lear <[email-masked]>
Date: Sun, 01 Feb 2004 10:02:36 -0800

Dave,

> SCTP and then to convert all Internet applications over to it.

I think this argument can be taken too far.  Yes, there are 500 million 
hosts out there.  So long as we don't break the existing world for them, 
there is nothing wrong with adding new functionality.

The next question is whether the new functionality is useful until it's 
implemented in 500 million hosts.  I claim the answer is "yes".  Like 
any other advance it can be used in limited deployments for limited 
purposes until such time as it is generally available.

Imagine an application checkbox that says "try SCTP first".  I think 
part of the SCTP transition, however, should be something more than 
simply modifying socket options.  I would rather see our notion of 
services and well known ports more comprehensively addressed at the same 
time, so as to avoid such "checkbox" solutions in the future.

Eliot

---

From: Janardhan Iyengar <[email-masked]>
Date: Sun, 1 Feb 2004 13:41:55 -0500 (EST)

Hi Spencer/Armando,

I haven't been following this discussion through.. so let me know if I'm
going off track.

> On Fri, 30 Jan 2004, Spencer Dawkins wrote:
>
> > something, transports ignoring path changes makes a lot of sense. If
> > you are changing paths frequently (and round-robin would be the
> > limiting case), slow-starting every time you change paths is
> > excessive - and, if you're going to respond to PATH_CHANGE, what else
> > would you do? You could do congestion avoidance during the first round
> > trip, or actually lose something and do congestion avoidance on the
> > second round trip - not a big difference, conceptually.

Lets assume that the sending transport is allowed to maintain separate
congestion control parameters per path to the destination. I think this
debate about what the sender should do on each PATH_CHANGE would be easier
to resolve with per-path congestion control. The sender may not have to
slow-start on each PATH_CHANGE *if* the sender has "recently" used that
path to send data. Thus, if the sender is changing paths frequently enough
to be sending data on multiple paths concurrently, the sender can evolve
multiple independent cwnds concurrently. If not, a slow-start should not
hurt much. Of course, this is possible only if multihoming is supported at
the transport.

Further, having a multipath aware transport allows us to encode "correct"
Concurrent Multipath Transfer (CMT, or end-to-end load balancing) into the
transport, as against possibly aggressive CMT by an application. A feature
such as PATH_CHANGE is very enticing for app developers to use for CMT.

regards,
jana

---------------------------------------------------------------
         Visit www.narmada.org, www.indiatogether.org
---------------------------------------------------------------

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 02 Feb 2004 12:54:56 +0900

Daniel Senie;

> Ah, so you have indeed made routing policy decisions and placed them 
> into the end systems of the originator of the session. This is most 
> interesting. A site which has multiple connections with varying cost has 
> to either live with the routing policy you've encoded into the stack or 
> force dropped packets in some fashion to try to fool your stack.

Routing policy of a site is represented by IGP metric that
my stack at the transport or the applicaiton layer can just
accept IGP information and use it to choose the most favourable
address of my peer. If the chosen address does not work, the
transport or the application layer try others, after
transport or application layer dependent timeout.

There is nothing encoded in the stack.

There is no routing architecture change.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 02 Feb 2004 12:59:39 +0900

Iljitsch van Beijnum;

>>> Ok, we can discuss whether the changes are significant but the fact 
>>> that changes are required at all is the main problem.

>> You don't get new features without change of some sort...

> Sure. But wouldn't it be better to keep the number of places where 
> changes are necessary to an absolute minimum?

"absolute minimum" is not a good terminlogy for technical
discussion.

However, even if we change something for multihoming, it does
not mean we must change API nor source code.

That is, we should use the current IPv6 API for applications,
if any :-), already running over IPv6 even if a host is
multihomed.

And, it is being done with 8+8 addressing, as is described in:

	http://www.ietf.org/internet-drafts/draft-ohta-multi6-8plus8-00.txt

Masataka Ohta

---

From: Dave Crocker <[email-masked]>
Date: Sun, 1 Feb 2004 09:09:26 +0900

Randall,

d/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 2 Feb 2004 07:24:51 +0900

Eliot,

EL> Dave,

>> SCTP and then to convert all Internet applications over to it.

EL> I think this argument can be taken too far.  Yes, there are 500 million

My note was prompted by a desire to make sure the adoption issues were
considered explicitly.  It is always tempting to see an existing
solution and simply direct everyone to use it.

We should pay close attention to the types of changes that will be
needed for adoption. As you note, the difference between "useful for
the first two adopters" versus "not useful until almost everyone
adopts" is an example of an essential point of analysis.

Similarly, it's useful to ask what parts of an implementation must
change, in order to adopt the solution. Is it ok to have to change all
applications? Is it ok to have to change the networking
infrastructure? And so on.

And then, lastly, we need to look at the particular choice being
offered. I don't have an opinion about whether SCTP should be the TCP
replacement -- and I guess the UDP replacement -- but that seemed to
be the suggestion.

d/