Subject: Re: Under IESG review: draft-coene-sctp-multihome-03.txt

From: Bill Fenner <[email-masked]>
Date: Wed, 2 Apr 2003 23:45:59 -0800

Here's my take.

----- Begin forwarded message:

From: Bill Fenner <[email-masked]>
Subject: draft-coene-sctp-multihome
Date: Wed, 2 Apr 2003 16:13:51 -0800
To: [email-masked]

There are a lot of grammar / spelling / sentence structure / document
structure issues, which I won't go into.  It certainly made the document
hard to read.

I think my biggest concern is from section 2.2; my previous assumption
was that if you really wanted to use SCTP multihoming you would make
arrangements a priori to get routing tables that would make it work.
The most obvious answer there was static routing and letting the SCTP
probes learn what paths were or weren't alive; alternately you could
run a seperate instance of the routing protocol specifically to distribute
a known subset of the routes to an SCTP speaker.

However, the second sentence of 2.2 says "The host does not know
beforehand to which other host it is going to send something".
I had not previously considered this as a usage mode of SCTP
multihoming, simply because it was inconceivable to me that there
was a way to make it work properly with routing without teaching
end systems every single route, which in itself is a non-starter
except in very special situations.

I'm not sure what to suggest here.  While it's reasonable to distribute
a small amount of routing information to a multi-homed host, I'm not
particularly comfortable with having that information dynamically based
on what multihomed SCTP peers the host currently has associations with
(as is proposed in the second paragraph).  I'm not sure what the actual
direction would be for the proposal in the final paragraph (of not
requiring any information at the host for multihoming) - perhaps this
means there's an SCTP proxy that knows how to do multihoming and the host
forwards all of its connections through the proxy?  *Something* needs
to have enough information.

I guess I need to get my expectations set (or set someone else's).
I've been expecting that complete use of SCTP multihoming requires a
very special network configuration that most sites would not have,
and either end-systems capable of handling full routing tables or
a special routing setup for the known destinations.  If this is
acceptable, then section 2.2 could say that; if it's not, then
I need to understand better what the expected usage model of SCTP
multihoming is.

On a seperate topic, Section 2.4 seems to be obsoleted by
draft-ietf-ipsec-sctp-04.txt (it has a reference to -02; I don't know if
it has changed significantly).  Since draft-ietf-ipsec-sctp-04.txt is
on this week's telechat, does it make sense for the "issues" document
to raise a solved issue [presuming that ipsec-sctp-04 passes] in the
same way as it talks about the others?

  Bill

----- End forwarded message:

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 3 Apr 2003 13:36:18 -0500

Folk,

I'll admit up front that I haven't studied SCTP in detail.  Alex
asked for some input.  Given that I just got back from vacation,
here's some random observations based on a perhaps incomplete 
understanding of SCTP.

If my premises are wrong, please set your flamethrowers to 1/2. :-)

> a known subset of the routes to an SCTP speaker.

The impression I had from my initial read of SCTP some months ago was
that an end system would be assigned one or more addresses that
had been assigned to systems within that routing domain.  In a
typical Internet attached network, this end system would typically
have just a single default route towards a router that knows what
to do for both sets of addresses and routing your packets towards
the appropriate destinations.

The fault protection that SCTP seems to provide seems best applicable
to existing inter-AS multihoming situations where multiple address
ranges have been allocated from multiple upstreams.  Given that
providers tend to announce their allocations out all of their
connections, where policy allows it, the paths are likely to be
much the same.  In order for SCTP multihoming to be effective, the
announced routes *must* be done in such a way as to introduce
path redundancy in the routing system.  I say this because, in
general, routing failures are due to a failure in the path to an
AS and thus usually to all prefixes (or perhaps "atoms" to borrow
the caida work) announced by that AS.  I *believe* but can't
support through empircal data that attempts to introduce actual
path redundancy are done as a side effect of trying to introduce
load balancing in a network.

> to have enough information.

Right.  This is what has confused me most about this document.  The
impression I got is that the knowledge would exist as part of the
routing system and the routing system allows for the distribution
of the redundant paths.  This document seems largely to focus upon
the idea that the redundancy exists in the end-systems and would
require a lot more routing intelligence than we've been wont to put
into an end-system.

> I need to understand better what the expected usage model of SCTP

Yeah, having this clarified would be useful.  I suspect I'm sort of
on the right track.  One useful side effect of SCTP everywhere is that
you can reduce the Internet routing table a bit since you wouldn't
need provider independant address space quite as much.  You can live
strictly with one or more sets of provider assigned addresses and
never worry about announcing them out your other network connections.
However, I don't think SCTP addresses primary address assignment in
a useful enough way to deal with traffic balancing issues appropriately.

-- 
Jeff Haas 
NextHop Technologies