[rrg] Maybe it's not "either-or": Considering ahost/network-based solution pair

[Flinck, Hannu (NSN - FI/Espoo)]

 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: rrg-bounces at irtf.org [mailto:rrg-bounces at irtf.org] 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
>rrg at irtf.org
>https://www.irtf.org/mailman/listinfo/rrg
>