Re: Fwd: A comment about MAST

["Eugene M. Kim" <gene@nttmcl.com>]

On Sat, Sep 13, 2003 at 12:48:20AM +0859, Masataka Ohta wrote:
> Eugene;
> 
> > If I understood you correctly, your concern seems to be that, with the
> > proposed MAST API, some applications are required to be modified just to
> > suit MAST as they had to with NAT.  Is this correct?
> 
> Wrong. There is no MAST API. It is NAT API. Applications for the API
> is, behind NAT, notified address of a NAT box and tell it to its peer.

Not verbatim.  In order for that to work, a new protocol is needed
between a NAT gateway and machines behind it so the gateway can notify
address changes to them.  To the best of my knowledge, none of the
existing IETF protocols do this, much less can MAST.  I think you are
worried about something that does not even exist.  If you or anyone else
could point me to an existing, widely implemented standard that serves
this purpose, I would stand corrected.

> 
> Of course, application on the peer also need modification, which is
> practically impossible.
> 
> Try to design the API of a host and its peer, for example, for FTP.

Do we have to modify FTP further than RFC 2428 in order to accomodate
MAST if it provided the API to get the up-to-date peer address for the
control connection?  If so, why?

> 
> > Assuming the answer is yes, I still don't think it's a definitively
> > prohibiting reason against the API.  I say this under the assumption
> > that MAST will be just a transition protocol, or a stopgap, with which,
> > again, simple applications can work without any modifications.
> 
> You miss the point that MAST does not solve *THE* problem
> and is useless even as an intermediate solution.

I'm afraid you did not communicate what was `*THE* problem' you were
trying to solve here.  And before putting your answer in a short phrase
such as `multihoming' or `roaming', please bear in mind that there are
people who lock on different facets of those vague subjects.

OT: Actually I was reading your E2E multihoming draft this morning then
encountered a similar problem; you apparently believed in the concept of
E2E by using phrases like `end to end _principle_' but failed to clarify
what `end-to-end' exactly implied.  If you meant some concept widely
believed in by other people, perhaps adding at the end of the draft a
reference to some other document that discusses the concept would help
the uninformed camp (including me) understand you and your proposal
better.

> 
> Worse, you miss the other point that no intermediate solution
> is necessary.

Only if we can come up with a real solution in rather a short timeframe.
I thought it would be rash to draft, implement and adopt something as a
standard in such a short timeframe that existing needs need not be met
at all in the meantime.

> 
> Worst, your hidden assumption is that almost all the hosts use MAST,
> which is not a sound assumption for an intermediate, if any, solution.

MAST does not worsen the case where one host knows MAST and the other
does not, because it is designed in such a way that it does not impede
the transport later without first verifying that the peer also knows how
to do it.  So it need not be worried about if the peer doesn't speak
MAST, because in that case MAST will not kick in but the communication
will proceed as if neither party knew MAST.

> 
> > With these two assumptions, authors of complicated application (i.e.
> > those that must be modified to take advantage of MAST) have two choices:
> 
> Completely wrong.
> 
> Those applications that must be modified to take advantage of
> multihoming with multiple addresses have a single choice to
> be modified so with no further modification.

Again, you seem to be assuming that we can come up with the long-term
solution in a really short timeframe.  Unless you can show me some
proposal is already up for that task, including deployment plans and
scenarios, I still think such an assumption is rash.

Thanks,
Eugene