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

[Dave Crocker <dhc@dcrocker.net>]

Folks,

Thanks for the comments.  Keep them coming.  Some responses:

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.

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.

MAST defers #1, focuses on #2, and treats #3 simplistically. This is
intentional, of course.

HIP and LIN6 are more ambitious.


SD> - I like the possibility of using MAST with IPv4.

HIP and LIN6 are tied to IPv6 and involve notable enhancements to the Internet
architecture.  Both seem pretty clean to me, architecturally.  MAST does not
take such an approach for two major reasons.  One is installed base, and the
support thereof.  I like to be friendly to millions of hosts, when possible.

The other issue is administrative overhead. MAST does not create any
interesting administrative load HIP and LIN6 impose some significant new
administration. MAST currently involves none. If MAST tackled mutual mobility
(specifically, anytime a caller needs to find a callee for the first time)
then some sort of third-party mechanism is needed and no existing Internet
mechanism is sufficient to the task, I believe. See #3, next segment, below,
re: LIN6.


SD> I took a quick look at LIN6,

Glad to see the reference to it.  I will fold consideration of it into the MAST
proposal.  Here are some initial thoughts:

I think that comparison of HIP, LIN6 and MAST will be helpful.  There are some
pretty interesting differences among them.  I'm planning on doing something
more detailed, but for now:

1. The MAST proposal has a discussion of HIP.  I'm hoping that a HIP savant
will tell me of any errors, so I can fix them.

2. LIN6 appears to be a transport-layer host identifier paradigm, with new
administration of the addresses and then a mapping between the transport-layer
id and one or more classic IP-layer addresses.  By contrast, MAST
introduces *no* new addresses on the wire.  New addresses within the end-nodes
are not required, though internal use of private IP addresses is discussed as
an implementation choice.

3. The LIN6 specification also provides for the rendezvous function, using
DNS, which MAST chooses to defer. The LIN6 rendezvous mechanism appears to be
two-stage.  Stage one is a domain name, with a new, MA record.  Stage two is a
dynamic mapping service, using the transport-level id and any IP-level
addresses that are currently operational.

Without worrying about the fine-grained details of this mechanism, I'll say
that I think it is generally the right approach, when the initiator of an
association must find a mobile host. My guess is that DNS is better for
"sticky" values and that anything that is more dynamic should use something
else. To this end, I find myself thinking in terms of a "presence" service, a
la instant messaging.


SD> - I like your awareness of NATs in IPv4 networks as a deployment
SD> issue.

Be friendly to the installed base and minimize adoption dependencies (ie,
number of changes to make and number of new mechanisms required.) Also, avoid
changing the infrastructure if at all possible.

Adoption of a new mechanism will be a lot easier.


SD> - I understand why you are thinking "end hosts only". You might also
SD> want to think about MAST proxies to allow MAST mobility against an
SD> unmodified correspondent host (to use the MIP term).

Section 8.3 of the MAST proposal is relevant, here. It does not use quite the
same language, but I think the functionality is exactly what you are
describing, or only needs a bit more. If not, please elaborate.


SD> - MAST seems to be very agnostic about the "bootstrap" IP address.
...
SD> mobile-initiated, but much less on how two mobile hosts find each
SD> other.

See above. DNS + distributed, dynamic bulletin boards (presence) function
seems like the right approach to me.

Basically, I think such a mechanism is very important and involves major
effort. It deserves its own focus.

MAST defers this type of mobility out of respect for its difficulty. I think
we do not need to put solving the rendezvous problem into the critical path of
the multi-homing and "client mobility" uses.


SD> - One HIP issue I've wondered about, but have not mentioned in public,
SD> is how an application might make of "whatever it THINKS is the IP
SD> address" (because a mobile address/identifier looks like any other
SD> address). What happens if an application expects to do a reverse DNS
SD> lookup of a HIP HI, for instance? Per your 8.1, I THINK any IP
SD> addresses your transports/applications see are really IP addresses,
SD> but they may not be routable or reachable at any given moment... I'm
SD> not the application guy here, I'm just wondering out loud.

Any application that uses IP addresses is a problem for any translation
function. To handle it, something has to change. The mapping code needs to
know about the application, or the application needs to know about the new
address, or the "address" needs to be something newly assigned thing (end
point identifier) that stays constant. Whatever the choice, it is a big deal.


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.


SD> When I've asked about this in places like DNA, the pushback is that this
SD> decision is internal to a host, and need not/should not be standardized in
SD> IETF.

That is like saying that the TCP retransmission algorithm is internal to a
host and need not/should not be standardized in the IETF.

This is something that has a direct impact on the rest of the Internet. A bad
scheme, implemented in lots of hosts, is going to do a lot of operational
damage.

It needs to be standardized.


SD> You might want to think about
SD> this, and mention your position on this explicitly.

Section 7 tries to do this.  While the current text might seem like a cop-out,
it is not meant to be.

Again, I have too much respect for the complexity and sensitivity of this bit
of mechanism to believe it should be set into concrete too soon, other than
for a simple, safe mechanism just to get things started. More interesting
address selection -- I'm not fond of calling it path selection -- mechanisms
are needed, but again, this can be taken out of the initial critical path for
development and deployment.


SD> - I'm wondering if you have looked at RSIP lately (Experimental
SD> protocol), re: NAT traversal, or at STUN - it looks like you're
SD> including some STUN functionality in PROBE.

I haven't.  Suggestions for what to change, in the PROBE function, would be
welcome.


SD> - I'm wondering how much you have thought about the use of PROBEs to
SD> verify path connectivity from time to time.

Second bullet of the first list under 5.4.  Yes?


SD> The transport view of the
SD> world is that this is really an application-level responsibility,
SD> because the transport (hence, the MAST) doesn't know how often to

My original thinking was that the module that knows about the multiple
addresses should check for their continued validity, especially since the
higher levels do not even know that the multiple addresses exist (in the MAST
proposal). In that sense, I think we need to distinguish things like
application-level aliveness tests from link-level keep-alives. In that sense,
MAST's PROBE is a lower-layers function.


SD> verify path connectivity - too often risks punting on paths that are
SD> broken now but will be healed before they are needed, and too seldom
SD> forces the application to probe,

This is all standard routing-table maintenance stuff, isn't it?  Hence we
should be able to re-use the learning from that task, in terms of balancing
switchover delay, versus flapping.

I don't have any religion on this, other than appreciating the challenge of
getting it right.


SD> - When you're moving forward from proposal to specification, you'll
SD> need someone smarter than I am about security on the design team.

I had not known about the Purpose-Built Key internet-draft.  It seems perfect
for the security MAST needs to provide, specifically to avoid hijacking the
MAST association.



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.

This point appears to be easy to miss, so let me summarize this aspect of
MAST again:

     MAST uses simple domain names as public, unique end-point identifiers.
     Oddly, MAST doesn't do much with them, yet, for the portion of the
     problem space that MAST attacks.

     MAST creates no new addresses.  None.  Internal to a MAST host, there
     might be a mapping of the changing IP addresses to a stable one that is
     private to that host.  Again oddly, this is like having a NAT function
     just inside the host, between transport and IP.

     
>> - I'm wondering how much you have thought about the use of PROBEs to
>> verify path connectivity from time to time.
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.


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.


d/
--
 Dave Crocker <mailto:dcrocker@brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>