On Tue, 23 Jul 2002, Kuntal Chowdhury wrote: > Pekka Savola wrote: > > Assuming CN is in ISP 1's network, MN is vising ISP 2's > > network and HA is > > in ISP 3's network. > > > > Your argument was, if I got it right, that route optimizations is bad > > because traffic is between ISP 1 and ISP 2 so ISP 3 does not > > get revenue. > > > > This seems ridiculous. > > Consider the scenario where ISP 3 (Home domain of the user) does volume > based accounting i.e. byte counts. The visited domain (ISP 2) does > not support volume based accounting. Therefore the home domain assigns > an AAA client in a router (which may well be the HA) which is guaranteed to > be in the data path. Reverse tunneling is enforced by the home domain to > ensure that the all the data to/from the user pass through the home > domain. Now the user performs RO with the CN. The CN starts sending data > directly to the MN bypassing the home domain. Therefore the byte counts > in the AAA client in the home domain will not be accurate.
What is the purpose of byte counts? Most often to see how many bytes have been transferred to the node in the specified network. In Route Optimization case, such byte counts are close to zero. I see no reason to artificially try to create these byte counts. Only the node and the networks it visit know how much traffic is used. > > What makes you think that the TEed route between the CN and the MN > > (i.e. Chicago -> Miami -> Dallas) will be a slow path? > > > The speed of light is a constant. > > It seems the assumption is that the link between CN and the MN is an optical > link. Similar restrictios apply to non-optical links too. The main factor is the length of the link. [...] > Say CN is in site A, MN in site B and HA in site C. Say the link between > site A and B is OC-48, older fiber type 'USF' and no EDFAs. However the > A -> C -> B is OC-192, newer fiber 'NZDF' with EDFAs. Also the number of 3Rs > between A -> B is more than the number of 3Rs for the link A -> C -> B. > Therefore the link speed, quality and available bandwidth will be far better > > for A -> C -> B than A -> B. > Now if the MN performs RO, then it will end up shifting the traffic from > a better link (A -> C -> B) to a worse link (A -> B). This will be the case > when the link A -> B is not congested. > When the link between A -> B is congested, and TE is implemented, the > traffic may be shifted back to the original link A- > C -> B. That will have > the opposite effect of RO. > I hope it is clear now that the speed of light is not the limiting factor > for a > light path. If the sites choose to prefer A -> B path instead of A -> C -> B (and they can easily do so, if they want), it's their choice. > Moreover performing RO w/o knowledge of the network topology > and constraints does not guarantee good results. I agree that RO is sometimes not worth the effort, but where optimized path would be worse seem to be just corner cases to me. > The shortest path may not be the best/fastest path even in stable scenarios. > It depends on the factors listed above for the light paths. By 'shortest path' I mean the path that the network admins have chosen to be the best path to other site X. It does not necessarily have to physically the shortest one, of course. But it does not usually go through third parties either, though. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
