Re: Multiple Address Service for Transport (MAST)

[Dave Crocker <dhc@dcrocker.net>]

[ 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. ]

Senthilkumar,

   
>><http://brandenburg.com/specifications/draft-crocker-mast-propo
>>sal-00.txt>
ASUS> can you compare your proposal with
ASUS> http://www.cs.ucla.edu/~bzhang/etcp/etcp_draft.txt


Section 4.2.2. of the draft anticipates your question. First, it
acknowledges the cleanliness of putting the mechanism directly into
transport. The two major arguments for a "wedge" approach over a
transport approach that it it puts forward are:

          a) working with the installed base of TCP implementations --
          since no changes are required to TCP, and

          b) working with non-TCP transports

Three other arguments worth considering:

          c) working with mobility, as well as multi-homing

          d) not incurring the per-packet option overhead with a larger
          packet and with option processing.

          e) moving the multi-homing/mobility negotiations out of the
          critical path to transport activity; hence it does not impose
          any start-of-connection delays. on the other hand, my
          impression is that the tcp option approach does not impose a
          delay, either.

I'll skip over any possible IPv6/IPv4 issues and any possible security
issues on the theory that they are, or can be, solved just fine for the
TCP option approach.

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>