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
