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

[Fumio Teraoka <tera@ics.keio.ac.jp>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Dave,

Sorry for late response. There are some comments about the
description of the LIN6 identifier in your artcle as a co-author
of the LIN6 i-d.

LIN6 introduces a 64-bit "node identifier (node id)" which is
assigned to a node. The node id is not only a transport layer
identifier. The node id in LIN6 is used in the application layer,
the transport layer, and the network layer (possibly, in the link
layer). In the network layer, the node id is concatinated with a
64-bit network prefix to generate a IPv6 address. In the application
layer and the transport layer,the node id is concatenated with a 64-bit
"fixed value" to generate an identifier which is compatible with
the IPv6 address format.

Unfortunately, I have not read the MAST i-d yet. I'll read the i-d and
post some comments on this list.

Best regards,

Fumio Teraoka

At 03/09/06 19:58 -0700, Dave Crocker wrote:
>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>