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

["Spencer Dawkins" <spencer@mcsr-labs.org>]

Dear Dave,

As you requested - the following are my comments on MAST,
revectored to multi6.

Rather than send detailed comments (which I can do, if you think it
would be helpful), I'd like to start at 50,000 feet...

- I like the possibility of using MAST with IPv4. I took a quick look
at LIN6, after Masataka's note on MULTI6. There were things I liked
about LIN6, but the IP version number in the acronym was not a
feature.

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

- I understand why you are thinking "end hosts only". You might also
want to think about MAST proxies to allow MAST mobility against an
unmodified correspondent host (to use the MIP term). If I learned
anything in TRIGTRAN, it was to think about who had the incentives to
deploy something - in wireless mobility, a service provider may have
an incentive to deploy client-side software (if needed) and a server
somewhere in the access network, but the correspondent hosts usually
don't have an incentive to deploy anything.

- MAST seems to be very agnostic about the "bootstrap" IP address. It
happens that I am working on a product that has some MASTish
functionality. We started out being agnostic, too. I'm arguing that we
really need a more useful host identifier (note the use of the
lower-case "h" and "i"). You are explicitly punting on the question of
rendezvous in 4.2.5. There's a lot of prior art that assumes one host
is mobile (WAP had this focus) and that all application exchanges are
mobile-initiated, but much less on how two mobile hosts find each
other. I'm not sure how we do this without HIP-DNS, an LIN6 mapping
agent, or something else within the network.

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

- I agree with Matataka's note that selecting an interface is not an
easy problem. When I've asked about this in places like DNA, the
pushback is that this decision is internal to a host, and need
not/should not be standardized in IETF. You might want to think about
this, and mention your position on this explicitly.

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

- I'm wondering how much you have thought about the use of PROBEs to
verify path connectivity from time to time. The transport view of the
world is that this is really an application-level responsibility,
because the transport (hence, the MAST) doesn't know how often to
verify path connectivity - too often risks punting on paths that are
broken now but will be healed before they are needed, and too seldom
forces the application to probe, anyway. Coming from my particular
part of the world, I think hosts really do see access link failures
(for some values of "see" and "failures"), that hosts can send "Now
I'm at this address" when access links fail, and that connection path
failures for inactive paths beyond the access links are likely to be
resolved before the path is needed (think, "core network routing
update").

- The feedback I got in TRIGTRAN was that it was OK for transports to
ignore path changes when they are doing congestion control, because
all we know is that at least part of the connection path has changed;
Slow Start wouldn't be WRONG, but it might be unnecessary - we could
also see if we can sustain the current rate, and perform congestion
avoidance based on losses (as transports do today), not notification
of path change (today's transports ignore subnetwork path changes
within a single IP hop, right?). You might want to mention your
position on this point explicitly, because we're still having the
"where is the right place for this functionality?" discussion that
includes "but transport does its thing on a single connection path
today".

- When you get to scenario-playing, the hard questions happen when
both hosts move simultaneously. But you know this, of course.

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

Hope this helps! Have a great weekend.

Spencer