Re: Multihoming by IP Layer Address Rewriting (MILAR)

[Ramakrishna Gummadi <ramki@cs.berkeley.edu>]

> On Tue, 4 Sep 2001, Ramakrishna Gummadi wrote:
>
> [snip]
> > My second complaint, and this applies to SCTP as well, is that we are
> > implicitly assuming here that one end can do DNS lookups to learn the
> > addresses of the other end---this may be impossible with busy servers.
>
> This is not an issue for SCTP. SCTP learns assoiations from it's peer
> directly. The only time DNS plays into it is connection built-up, where
> DNS is required in the non-multihomed case as well.

A busy public web server today can defer (reverse) DNS lookups (if it does
lookups at all) and just record the client addresses in logs. In
multihomed case, DNS lookup is necessary for connection survivability,
which means it has to be done online. I don't think the semantics are the
same in these two cases.

> > Also, I don't think it is a good idea to mandate every application to be
> > aware of all multi-address details, which SCTP requires. We must remember
> > that SCTP was invented primarily for carrying signaling messages (the
> > abstract says as much), and one of its co-authors I talked to says he
> > thinks that general applications should *not* have to deal with all these
> > details.
>
> You can wrap a TCP like api so the application is unaware of any
> multihoming issues.

May not be as simple as it sounds because SCTP is designed to be
asynchronous, with notifications, etc. Supporting this transparently can
be problematic without threading support to wrap SCTP behavior...

> Have you read the SCTP RFC? It's a very clear superset of TCP and every
> feature it has is an important feature that current apps are emulating at
> higher layers over TCP or UDP (like the use of concurant connections with
> HTTP to simulate multiple streams, or the abundance of UDP apps which
> impliment their own reliable deliverly (and usually misimpliment
> congestion control)).

I read the RFC fairly carefully, and even though it may be a superset of
TCP, the api is not app-transparent like tcp, and can not be directly used
by simple single-threaded apps.

-ramki