Subject: Re: Multiple Address Service for Transport (MAST)

From: Dave Crocker <[email-masked]>
Date: Fri, 29 Aug 2003 08:50:45 -0700

[ 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>[email-masked] 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:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 02 Sep 2003 10:25:35 +0300

(Discussing TCP vs. wedge approaches)

>           impression is that the tcp option approach does not impose a

There are a couple of other issues worth consider, too:

             f) transport layer implementation requires more signalling,
             i.e., separately for each connection, than a wedge one,
             which is basically host-to-host (or end-point-to-end-point)

             g) a wedge implementation will have interesting interplay
             with transport layer RTT and throughput estimates.  OTOH,
             that information is actually more host-to-host (or path
             related) in nature than connection related.

--Pekka Nikander

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 2 Sep 2003 14:22:34 -0500

Dear Pekka,

>              related) in nature than connection related.

You'd think so, but I sure haven't heard of a lot of people doing
ftp://ftp.rfc-editor.org/in-notes/rfc2140.txt in production TCPs...

Maybe the wedge approach would provide an incentive here?

Spencer

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 03 Sep 2003 09:16:22 +0300

Spencer,

>>    with transport layer RTT and throughput estimates.
>>    OTOH, that information is actually more host-to-host (or path

I haven't really checked the BSD stack code recently, but
it does keep the RTT and throughput estimates in routing
table entries and not in tcb entries.  In fact, it has a cloned
routing table entry for each active host, and that entry carries
the RTT and throughput estimates over consequent TCP connections.

I would need to study to source code more closely to be able
to say anything more.

> Maybe the wedge approach would provide an incentive here?

Maybe.

--Pekka Nikander

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 3 Sep 2003 22:40:54 +0859 ()

Dave;

MAST is another form of (original) LIN6.

While you say:

	It requires no change to the IP infrastructure, and no change
	to IP modules or transport modules in the end-systems.

	It requires no change to existing transport protocols and
	no changes to IP. Instead, it defines a wedge layer between
	IP and transport.

	In contrast, the current proposal provides support that
	requires no new infrastructure and no changes to existing
	protocols.

	The service should require no changes to the IP network
	infrastructure, to the IP layer in end-systems, or to the
	transport layer in the end-systems.

They are all wrong.

First, a transport protocol is defined on the wire, not at the
API. So, if, on the wire, packets with different pairs of
source/destination addresses belong to the same connection,
it is not TCP but a new protocol.

Second, while you don't have to modify existing transport
code, you must add something to the transport module. That is,
as transport has its own checksum on addresses, calculation
of which is transport dependent, your code include additional
transport module. If you want to add new transport, your
code must also be modified.

Yes, as you correctly observe, your proposal is only as
transparent as NAT.

You modify everything only to have a system to be able to
handle address changes not so efficiently.

But, the worst problem of your proposal is that you don't
properly address the most serious issue on when to change
addresses and which address should be preferred. Read my
draft.

							Masataka Ohta