Subject: RE: Death of the Internet - details at 11

From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" <[email-masked]>
Date: Sat, 31 Jan 2004 15:26:54 -0600

> However, with multihoming, the change may be a common occurance
> throughtout the lifetime of a connection depending on the application and
> the use of the multiple paths (failover, concurrent multipath transfer,
> etc). So TCP (or whatever transport) should not be blind to the fact that
> data is potentially going over a different path. Otherwise, the congestion
> control parameters/algorithms will not work properly.
 
I agree. But, as you mention in an other mail, TCP/SCTP/DCCP has a limit to 
do simultaneous tranfer. It is impossible to provide concurrent multipath
transfer without changing the cc algorithms. But, given current options,
transport is the better judge to do zero click fail-over. 

> Also, since the transport is maintaining per path information, it is in
> the best decision to decide which path to use. 
 
*nod*. It is the main reason why multi addressing is the only 
architectural possibility to do a scalable MH. The problem with
the remaining solutions (at shim/new identity/network layer) is 
that they hide the redundancy factor (multiple address -MA) from
the users. Given the current state (failures, misconfigurations
and rate limitations,) e2e check (by measurements) is the only 
option to check path availability. The MA feature gives user a 
chance to make a choice based on e2e reachability checks. 
 
I dont know why people get suprised by explicit announcement of 
MA. we have been doing this kind of explicit announcement both 
in DNS ( multiple NX records) and SMTP ( multiple MX records.) 
So, in a way SMTP reliability is due to explicit announcement of 
multiple MX records. 
 
id/loc split proposals are cool. But, without modifying the routing
architecture, they can never provide a e2e reliability or explicit 
user control feature. OTOH, I don't forsee any routing change at 
*architectural* level in the near future. It is time to think 
on why id/loc split proposals without routing architecture change 
kill the e2e control/reliability options and are architecturally 
incomplete.
 
So, it is clear that a combination/subset of host-centric MH, 
transport MA and BGP MH (if there exists a solution which 
doesn't bloat routing table) is the ONLY possibility to do a 
scalable MHv6.

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Sat, 31 Jan 2004 20:03:26 -0500 (EST)

On Sat, 31 Jan 2004, Ayyasamy, Senthilkumar  (UMKC-Student) wrote:

> transfer without changing the cc algorithms.

Yes, I never meant to imply that the cc algorithms could remain the same.
I just wanted to point out that concurrent multipath transfer (CMT) can
not be done well without multihoming support at the transport. At UD, we
(in particular, Jana Iyengar) are investigating CMT in multihomed
transports (ie, SCTP) so that only the sender has to modify it's cc
algorithms to remain Internet-friendly.

> But, given current options, transport is the better judge to do zero
> click fail-over.

Yes, I think so.

~armando

0--                                              --0
| Armando L. Caro Jr.  |  Protocol Engineering Lab |
| www.armandocaro.net  |    University of Delaware |
0--                                              --0