We don't yet have a full draft spec, but we do have an implementation that we're currently debugging and testing. A spec will follow, once we're more certain we understand all the more subtle interactions.
As for path discovery - there's the simple solution and the more complex solution. For now, we're assuming that at least one of the hosts is multi-homed, and we simple use the path diversity that comes from this. It certainly doesn't guarantee the paths stay separated, but if you link the increase/backoff algorithms in the right way, the hope is (and some of the theory dictates) that the aggregate of the multiple subflows simply ends up behaving like a regular TCP flow if the bottleneck is in the common part of the paths. Thus there's no requirement to enforce that the paths are exclusive, or even to detect if they are. If both ends are mult-homed, then you have more possible paths to choose from, and more probability of finding one that is uncongested or survives a network failure. However, once you have multi-path capable transport, then this opens up the option of doing smarter things for path discovery to try and ensure diversity. The goal then is to specify these mechanisms in such a way that they can operate self-contained with whatever addresses and paths they're given, or to give better results when you add extra path choice mechanisms in the future. Overall though, it remains a research question as to how much path diversity is needed overall to realize the benefits of resource pooling, and this is what we are currently starting to examine. - Mark On Thu, Nov 27, 2008 at 4:01 PM, Flinck, Hannu (NSN - FI/Espoo) < [EMAIL PROTECTED]> wrote: > > Hello Christian > > Could you please remind us again where the multi-path TCP draft is? I am > curious to know how the paths through the network are discovered and > made exclusive. > > Best regards > Hannu > > >-----Original Message----- > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > >Behalf Of ext Christian Vogt > >Sent: Thursday, November 27, 2008 15:35 > >To: Christopher Morrow > >Cc: Routing Research Group Mailing List; Noel Chiappa > >Subject: Re: [rrg] Maybe it's not "either-or": Considering > >ahost/network-based solution pair > > > > > >> I saw it as: The pain we see is in the network, host solutions don't > >> (as of yet) provide the control required for large-scale TE issues > >> [...] > > > >Hi Chris - > > > >On the other hand, RRG does have several host-based > >multi-homing solutions that enable the network to exercise > >traffic engineering: > >Six/One gives the network explicit traffic engineering control > >through address prefix rewrites in routers. Multi-path TCP > >gives the network an implicit means for traffic engineering > >through bandwidth limits and packet loss. And both Six/One > >and multi-path TCP can be used within the framework of a > >hostname-oriented network protocol stack. > > > >The only argument that can be brought up against host-based > >multi-homing is that it becomes effective only if a > >considerable portion of all hosts supports it. Even if > >networks can ensure that local hosts do support multi-homing, > >there is still a dependency on remote hosts supporting it as > >well. However, the dependency on the remote side does exist > >also for network-based multi-homing. Like host-based > >multi-homing, network-based multi-homing does require support > >on both sides of a connection. > >Consequently, host-based multi-homing is IMO deployment-wise > >just as feasible as network-based multi-homing. And > >technically, host-based multi-homing is IMO even preferable > >for two reasons: (a) It is inherently more robust because it > >does not add new single points of failure. (b) It is more > >reliable because only hosts can monitor the availability of > >complete end-to-end paths. > > > >FWIW: The above considerations apply only to RRG's goal of > >enabling multi-homing. They do NOT apply to RRG's second goal > >of eliminating renumbering. Eliminating renumbering entirely > >is possible only with a network-based solution. And unlike > >enabling multi-homing, eliminating renumbering is achievable > >with only unilateral support: Six/One Router Unilateral mode > >and NAT66 are example solutions. Since the first goal can IMO > >best be solved in hosts, whereas the second goal is achievable > >only with a network-based solution, I was suggesting the dual > >approach consisting of a host-based solution plus a > >network-based solution. > > > >- Christian > > > > > >_______________________________________________ > >rrg mailing list > >[email protected] > >https://www.irtf.org/mailman/listinfo/rrg > > > _______________________________________________ > rrg mailing list > [email protected] > https://www.irtf.org/mailman/listinfo/rrg >
_______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
