[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
and the findee. In classic client-server scenarios, that is what we
DNS for. Clearly, some mobility scenarios create challenges that
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
host-pair transport context to be able to use more than one address
life of the association.
3. Multi-address use -- intelligently choosing among multiple available
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
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
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
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
IvB> when the first fails because there is no reasonable alternative
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.
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
IvB> I'm convinced that as soon as we've got the basic multiadressing
IvB> mechanisms in place, load balancing single TCP sessions over
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
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.