Subject: RE: [Tsvwg] multiaddressing

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 29 Nov 2004 22:11:18 -0800

> -----Original Message-----
> From: Ted Faber [mailto:[email-masked]]
> Sent: Monday, November 29, 2004 7:00 PM
> To: Henderson, Thomas R
> Cc: Randall Stewart; [email-masked]; Mark Allman; Janardhan Iyengar
> Subject: Re: [Tsvwg] multiaddressing
> 
> 
> On Mon, Nov 29, 2004 at 04:25:47PM -0800, Henderson, Thomas R wrote:
> > 
> > 
> > > -----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.
> 
> 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. 

Two main reasons come to mind-- cases where DNS is not used, and 
dynamic scenarios where updates are expensive and addresses are
somewhat transient.

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

I was more suggesting that it may need to be resolved in the stack somewhere
than not at all, since the debate in that thread seemed to be application
vs. transport.

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

Putting it into a session layer that runs over unmodified TCP does seem
doable (there was a clever paper about Rocks and Racks in Mobicom a
few years back) but it seems like it could get complicated synchronizing
across the connections.  For instance, what happens to data that was
sent into the TCP send buffer of a now defunct connection-- is it yanked
back out of the send buffer? (SS7 has a protocol that actually works
like this:  MTP-3 over MTP-2).  Or a copy kept until a session-layer
ACK comes?

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

The act of picking the destination address correctly might be one
strong argument for putting it in transport layer or in some adjacent
layer that has access to transport state, because transport has the
recent loss and congestion control history to inform the decision.

But your point is well taken that it doesn't necessarily need to
be in transport.  My sense has been that it might be cleaner in
the long run to solve it below the application somehow, though.

Tom

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

---

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

> dynamic scenarios where updates are expensive and addresses are

No argument.  Neither of those are added dependencies, and the only
solution for doing that without multiple addresses is to use IP
directly, so I'm not sure multihoming changes the problem, though it may
well make it more important.

[snip]

> across the connections.

I agree and I agree.  There are some fine papers about striping across
TCP connections as well that touch on some of these issues, and I'm sure
there are some more out there that the community has yet to confront.

>                          For instance, what happens to data that was

If you really want to make sure it gets to the application, your ACK
needs to be end-to-end (in this case session-to-session or maybe
app-to-app).  Less strict semantics mean less strict memory
requirements.  That seems like a good argument for a couple types of
multi-whatsis layers or libraries to me.

[snip]

> the long run to solve it below the application somehow, though.

I think separation of concerns is good when one can achieve it as is
reuse of a good idea, so I'd like to see the idea in a {layer, library}.
I'm not blind to costs or impossibilities that might push function into
existing transports, but I don't see any of the latter now.  Costs will
be a matter of building and measuring.

I'm glad we see eye-to-eye.

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