On Fri, 30 Jan 2004, Iljitsch van Beijnum 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.
This _kind_ of a solution has already been proposed by Joe Touch and Ted
Faber in their ICNP 97 paper, "Dynamic Host Routing for Production Use of
Developmental Networks". It works, but on of the problems is that you hide
path information from the transport. 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.
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
As far as I can tell, most of the multi6 wg participants are thinking
along similar lines.
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. _Maybe_ SCTP doesn't solve _all_ the
problems, but I think SCTP should be evaluated more closely before
developing yet another protocol. ...because I believe that no matter how
much we don't want to touch TCP or IP, something has to be changed to get
all this functionality. In my opinion, the transport is the easiest to
change, since they live on the endpoints and operating systems do
eventually get upgraded.
Yes.. if you wanted to do HTTP over SCTP and use features such
as streams you WOULD WANT to extend HTML so that you could
have the client "get pages" on particular streams...
Why extend the markup language?
I think that was a typo...
HTTP has supported sessions that stay alive so they can be used for
more than just one operation for many years now. The trouble is that
you get head of line blockage if you fetch all the elements that make
up a WWW page in serial fashion. Being able to multiplex different
streams (within an SCTP session) that all fetch elements simultenously
would fix this. This of course requires changes to both HTTP clients
and servers, but it should otherwise be transparent to the user.
This is essentially what Jana did. I don't really know the details of his
changes, but he exploited SCTP's multistreaming to avoid head of line
blocking. Sourabh Ladha did similar work with FTP.
Sourabh Ladha, Paul D. Amer, Improving Multiple File Transfers Using
SCTP Multistreaming , IPCCC 2004, Phoenix AZ.
Anyway, with IPv6 the address format is fundamentally incompatible with
that of IPv4 so there is no choice but running them concurrently during
the transition period. A new multihoming-capable transport protocol
doesn't have to be incompatible with existing TCP so this situation is
No, it doesn't have to, but as I said above... something has to
change. Without change, you're limited to the improvements you can make.
| Armando L. Caro Jr. | Protocol Engineering Lab |
| www.armandocaro.net | University of Delaware |