[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] a few draft towards convergence
- To: Lixia Zhang <lixia@CS.UCLA.EDU>
- Subject: Re: [RRG] a few draft towards convergence
- From: Brian E Carpenter <brian.e.carpenter@gmail.com>
- Date: Sun, 27 Jul 2008 00:21:04 +1200
- Cc: rrg <rrg@psg.com>
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=XXZk3IgauQO6NVoqMKJtQtPulddkQ2PVF7gG4EGm/m/7NSfvmmW+siy2AJ9QUZdPGM 5dfqtzU2pxXy2Kb4WdC0qiVdbWHN0Wjndw0/pk4W/novOjolIY4ssn/kn791IqWH4GDx rnIKIiqFYSPe13a0b0NOEcbwxVB84yJlU+Xsc=
- In-reply-to: <96D366FB-6140-4316-9EFC-EA3B4CA1F5CF@cs.ucla.edu>
- Organization: University of Auckland
- References: <96D366FB-6140-4316-9EFC-EA3B4CA1F5CF@cs.ucla.edu>
- User-agent: Thunderbird 2.0.0.6 (Windows/20070728)
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...
> 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
--
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