Subject: RE: [Tsvwg] multiaddressing

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 29 Nov 2004 16:25:47 -0800

> -----Original Message-----
> From: Ted Faber [mailto:[email-masked]] 
> Sent: Monday, November 29, 2004 3:30 PM
> To: Janardhan Iyengar
> Cc: Randall Stewart; [email-masked]; Mark Allman
> Subject: Re: [Tsvwg] multiaddressing
> 
> I'm a slow thinker.  Can you give me an example of a benefit to doing
> load balancing in transport that's not an implementation 
> workaround, but
> a problem with using the transport service to do what you want?
> 

How do applications learn of and propagate multiple address sets
across which they can open multiple transport streams and load
balance across them?  DNS?  It's probably not a good idea to create
additional DNS dependencies.  Applications themselves?  Then you
burden applications with learning the addresses and communicating
them across to the peer, and it gets messy when NATs are involved
(IP addresses in application data streams are deprecated).

This question probably boils down to what do we want the
transport/application API to look like-- do applications connect to
hosts, or to IP addresses?  If hosts (which would seem to be consistent
with the terminology of RFC 793-- TCP as a "host-to-host" protocol),
then we should probably think about offering load balancing in the
stack somewhere.  Then the question becomes (as you put it in the
previous message) whether we can do a good enough job in the
transport to provide a *common* load balancing service that has
enough utility to multiple applications.

Of course, if these services do not work in the stack, applications
will reinvent them (SIP Reinvite, for example), and we shouldn't
prevent anyone from using atomic building blocks at the application
layer if they so choose, but it is worth considering from a
performance and architecture standpoint whether transport should do
applications a favor by providing such a mode of operation, and
then whether it is of enough common benefit and worth the trouble.

Tom

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Ted Faber <[email-masked]>
Date: Mon, 29 Nov 2004 19:00:01 -0800

On Mon, Nov 29, 2004 at 04:25:47PM -0800, Henderson, Thomas R wrote:
> additional DNS dependencies.

Why *not* DNS?  It's a distributed replicated 1-to-many database.  It
already returns lists of network addresses associated with a string, and
there's a well-known API to get at those.  I don't understand the
additional dependency created here unless the endpoints were not
exchanging DNS names to begin with. 

>                               Applications themselves?  Then you

NATs are sure a problem if you want to go passing IP addresses around.
That's not a problem introduced by multi-{addressing,homing}.  Any
protocol that wants to redirect has it.  Not using IP addresses won't
save you - SMTP accross a NAT may fail because the DNS reverse mapping
that the endpoint believes in isn't the same one that a (paranoia)
server sees.  I don't have an easy answer to the problem of how an
endpoint identifies itself to another endpoint when the endpoint doesn't
know its own name, but I'm pretty sure that getting a list of names
doesn't make it any harder than getting one.

I understand you want to add another layer of indirection here, but I
don't see why that layer needs to be resolved in transport, nor really
what you'd save by doing so.  (I'm a little fuzzy on why you need one at
all).

> enough utility to multiple applications.

There's a lot of space between transport and application.  It's
perfectly reasonable to insert a {library, protocol layer} in there if
you want to create an idea that the application writer looks up a name
and communicates with the named entity without changing the meaning of
an IP address to TCP or another existing protocol.

You're going to have to multiplex from "multiname" to multiple IP
addresses (or transport connections) either way.  Even if you had a
transport protocol that would accept packets from an array of names for
the other end, sending a packet requires picking the destination address
to send to.  You don't save any work doing it in transport, and you lose
any possibilty to cleanly build on the transport.

> then whether it is of enough common benefit and worth the trouble.

I understand the efficiency concerns.  It's very unclear to me that
these dominate at this point.  Until it's clear that they do, or that
there's a big layering violation I still think that the right place to
attack this is above transport (and not necessarily in the app).

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG 
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Nov 2004 00:11:18 -0800

Henderson, Thomas R wrote:
> balance across them?

Why should they? If the addresses "mean" the same thing, that ought to 
be a single socket, and the network-layer delivery ought to figure out 
there's more than one way there (ala multi6 shim).

As to how NATs complicate the system - this version or any other - color 
me shocked. Any time what you want doesn't map to emulating a single 
network address, a NAT is a mistake you have to undo. It should be no 
surprise that it causes problems in this scenario, which clearly breaks 
the basic characteristic of a NAT.

I like the idea of supporting muxing in the stack, but in the network, 
esp. since it can be useful for tunnels as well as for end-to-end apps.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Nov 2004 00:16:15 -0800

Ted Faber wrote:
...
> exchanging DNS names to begin with. 

When DNS returning multiple RRs it doesn't mean they're on the same 
host; they are just 'equivalent' in some fuzzy sense, e.g., replica 
servers of a database, alternate gateways to a VPN, etc.

There would need to be a different record to indicate records that go to 
the same 'box' (i.e., we could call them WH for 'weak host').

Joe

---

From: Ted Faber <[email-masked]>
Date: Tue, 30 Nov 2004 10:07:02 -0800

> servers of a database, alternate gateways to a VPN, etc.

Doesn't mean they're not on the same host, either.  I think the meaning
of the multiple DNS returns is as well defined as the meaning of the list
of names for the multi-{addressing,homing}/mobility thing that's
in the air.

> the same 'box' (i.e., we could call them WH for 'weak host').

This may be a reasonable course.  You may also be able to set up SRV
records or some such thing (no I didn't pull up the format), if you
wanted to argue that service points are what you're naming.  There are
other choices, too.

The point is that if you want a distributed replicated 1-to-many
database that handles primarily infrequent updates, I know where you can
get one.  Cheap.

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Nov 2004 12:29:18 -0800

Ted Faber wrote:
> Doesn't mean they're not on the same host, either.

It tends to, for servers in particular. RRs are used for pseudo load 
balancing; that's where the name came from, AFAIR.

> I think the meaning

Not for multi6; in that case, the set of addresses is defined as being 
on the same endpoint.

> database that handles primarily infrequent updates, I know where you can

Agreed. But not necessarily out-of-the-box, that's all.

Joe