[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on draft-crocker-mast-proposal-00.txt

On zondag, sep 7, 2003, at 04:58 Europe/Amsterdam, Dave Crocker wrote:

This realm encompasses three bits of functionality:

1. Rendezvous -- finding someone without existing context between the finder
and the findee. In classic client-server scenarios, that is what we use the
DNS for. Clearly, some mobility scenarios create challenges that existing DNS
mechanisms do not cover.

I would argue that MAST doesn't perform the initial rendezvous, but rather just adds additional addresses to an existing context.

2. Multi-address support -- or rather, making it possible for a specific
host-pair transport context to be able to use more than one address over the
life of the association. 

3. Multi-address use -- intelligently choosing among multiple available
addresses.

Yes, this is obviously something we shouldn't overlook. :-)

However unless I missed it twice, the MAST draft doesn't really discuss this. What is the idea here? Are transports supposed to know how to handle the additional addresses? Or does MAST sit between IP and the transport and adjust the addresses one uses to the addresses the other needs? If the latter is the case, then you need to decide your course of action with regard to the transport checksums. If you leave them alone there shouldn't be any problems as when the addresses are restored at the receiver, the checksum becomes valid again. Unless you use NAT, that is. I'm sure most NATs use incremental updates too the checksum so this would still work but I'm equally sure there are one or two out there that simply recompute the whole checksum, which isn't what you want here.

While we're talking about NATs: how is a host behind NAT going to be successfully multiaddressed? Does it make sense to address the corner case where this is possible, or should a NATted host just be a single homed correspondent to a multihomed system?

How are you going to decide when an address jump is in order?

How does MAST fit in the current communication model? Do you do MAST first and then a three way handshake? Set up TCP first and then do MAST?

SD> - I agree with Matataka's note that selecting an interface is not an
SD> easy problem.

I agree. That's why MAST says a) it's a hard problem, worthy of study, and b) until we understand it better, be simplistic and conservative.

Actually if you can jump addresses this is no longer a big issue. Unfortunately, if you negotiate in-band, you can't jump addresses when you need it most: after you notice that the first packet didn't make it to the other side.

Even cooler is letting the routers rewrite the source addresses so:

1. You always have a "good" source address in order to pass ingress filtering by your ISP
2. The other side gets to see it automatically when your view of the path to it changes

IvB> But is it realistic to expect to deploy a technology in IPv4 that uses
IvB> up additional address space?

MAST does not use up new address space in IPv4 or IPv6. None.

Except that you need more than one address to get some use out of MAST, which is neither unusual nor a big deal for IPv6, but certainly the former and possibly the latter in IPv4.

IvB> If you only have two paths you're going to try the second one anyway
IvB> when the first fails because there is no reasonable alternative course
IvB> of action. If you have more paths there is a signicant chance that
IvB> several of them will fail because of the same underlying problem.

Round-robin is sometimes a fine approach. Sometimes it has problems. Just
because a re-try is necessary does not automatically making trying an
alternative address the right thing to do.

I was talking about the first address being dead, in that case it is. :-) Unfortunately it isn't easy to see whether an address is dead, which I think is your point.

IvB> If you really want to be cool, _use_ the different paths concurrently.
IvB> I'm convinced that as soon as we've got the basic multiadressing
IvB> mechanisms in place, load balancing single TCP sessions over multiple
IvB> paths will be the next big thing.

I've always felt that the fastest way to switchover to an alternate path is to already be using it. Still, this is sensitive stuff and needs to be
approached carefully.

If we get the basic multihoming part right then this part is up to the transport guys. I'm sure they'll come up with something great.