[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] a few draft towards convergence


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


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
solutions.  a link to the draft is
 http://www.cs.ucla.edu/~lixia/draft-efit-mapping-multipath-00.txt


Here are a couple of comments...


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) 



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?
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.



...

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


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).


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


--
to unsubscribe send a message to rrg-request@psg.com 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