Subject: [RRG] a few draft towards convergence

From: Lixia Zhang <[email-masked]>
Date: Mon, 21 Jul 2008 07:01:57 -0700

To contribute to the convergence effort, we made a first (drafty)  
draft on the roles and differences of map&encap vs transport multipath  
solutions.  a link to the draft is
   http://www.cs.ucla.edu/~lixia/draft-efit-mapping-multipath-00.txt

We are looking forward to your comments!

Lixia

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 27 Jul 2008 00:21:04 +1200

On 2008-07-22 02:01, Lixia Zhang wrote:
> To contribute to the convergence effort, we made a first (drafty) draft
> on the roles and differences of map&encap vs transport multipath

Here are a couple of comments...

> 3.  The Multipath Transport Approach
> 
> 3.1.  Benefits
> 
>    There has not been any published work describing a specific
>    realization of the multipath transport solution. 

Really? I would have expected that at least some learnings from
SCTP were available, or don't you consider SCTP to be in this
space?

...
>    A more fundamental distinction between the multipath transport
>    solution and SHIM6 is that the former utilizes multiple paths in
>    parallel, rather than using one at a time (as in SHIM6).  In addition
>    to the potential performance improvement, the simultaneous use of
>    multiple paths easily tolerates the loss of any single path, hence it
>    becomes less important to keep track of the status of any individual
>    path.  This last point makes it feasible for network providers to
>    aggregate PA addresses.  

I don't understand the last sentence, as a contrast to SHIM6. SHIM6
automatically allows PA aggregation at any BGP speaker that cares
to do so, and it does reachability detection at the host level.

I also don't see the argument that transport level solutions easily
tolerate the loss of a path. They still have to learn that a particular
destination locator is failing, in order to stop using it; their only
advantage is that this particular version of reachability detection
can be piggy-backed on the transport layer ACK mechanism (or more
precisely, on the mechanism for handling missing ACKs). And if the
transport protocol is one like TCP that tolerates extremely long
periods of silence, it may even be necessary to insert artificial
keep-alives in the transport stream, at which point the mechanism
is almost identical to SHIM6 reachability detection.

In fact I think the *only* fundamental distinction from SHIM6 is
that the transport layer solution can use multiple paths in
parallel (and I'm sure that could be added to SHIM6, but with
out-of-order delivery likely).

     Brian

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 26 Jul 2008 06:47:43 -0700

On Jul 26, 2008, at 5:21 AM, Brian E Carpenter wrote:

>> draft

thanks for the comments!
Helpful in seeing what's unclear in the text (both your comments  
rooted in one point: by "multipath transport" we meant a transport  
session utilize multiple paths in parallel)

> SCTP were available, or don't you consider SCTP to be in this

consider I was a co-author of the first SCTP spec, I'd sure want to  
sell it as much as I could :-)
Unfortunately I can't do it here: SCTP uses one single path at a time.

> to do so, and it does reachability detection at the host level.

Yes. However as you pointed out below, (reliable) transport has built- 
in path failure detection with no additional overhead, and in ideal  
case can detect loss in about one round trip time (TCP's RTT measure  
has gone through years of tuning).

Host level reachability detection, on the other hand, faces a few  
difficulties.
It incurs new cost
It faces the dilemma of too high overhead by poking too frequent, or  
too slow detection otherwise.
It also has the concern with routing convergence timing...
It also faces danger of running into out of sync with transport  
detection/retransmission (there was a paper here, but can't find the  
pointer as I'm heading to airport now)

for using multipath in parallel: you dont really depend on any single  
one to make progress

> out-of-order delivery likely).

yes, one fundamental difference is using multipath in parallel.
doing it at transport level is also another fundamental difference