Re: Multihoming by IP Layer Address Rewriting (MILAR)

[Greg Maxwell <gmaxwell@martin.fl.us>]

On Tue, 4 Sep 2001, Ramakrishna Gummadi wrote:

> > 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.

It's a total layering violation to require DNS lookups in this place.

SCTP has no such requirement, clear you confusion child. The only reason
that DNS has to be aware of multiple prefixes AT ALL, is because the
client needs 1 working prefix to bring up a connection. As the connection
is brought up, the client may transmit the rest of it's prefixes to the
server and ther server may do the same to the client.

With a minor extension likely to be in most SCTP implimentations, nodes
can transmit additional endpoint addresses at any time during
communications.

Again, the DNS lookup in the SCTP case is only needed where one would be
needed anyways, but it provides just a little more information.

> 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...

You can open a single stream and pretend it's TCP. Yes, if you want to
take advantage of multiple streams (which HTTP really should do!) you will
need some massive application chages. Nice thing is that it could be done
totally transparently and SHTTP 1.1 could over time be migrated to SHTTP
1.2.

> > 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.

Yes it can. You can open a single stream and pretend you are talking on a
TCP connection totally transparently. Yes, you don't get all the
advantages, but you do get multihoming.