David Conrad wrote: > Lars, > > On Feb 13, 2008, at 6:50 AM, Lars Eggert wrote: >> But there are maybe a few million routers in the world, and maybe even >> fewer for which scalability is a serious issue, compared to a few >> billion hosts. Deploying something new at the network layer that might >> require changes to host stacks or applications to maintain performance >> at current levels would be a non-starter. > > We already have to change host stacks and applications to support IPv6. > Given the minimal deployment of IPv6 to date, particularly within the > application space, this doesn't seem like a non-starter to me. > > And to be clear, most applications that exist today (that have been > ported to IPv6) wouldn't need to change. Even in the worst case pure > pull-based system, the only applications that would need to change would > be those that are very sensitive to delays in the initial flow RTT. To
I agree > date, there has been mention of one (channel changing) on this list. I'm not sure if channel changing need to pose a problem. E.g. if they can be streamed from the same source address. If they are streamed from multiple addresses but covered by the same locator mapping (assuming that you can get a single id-prefix/range to locator mapping from the mapping service), this might also be fine. > I'm sure there are others and I'd be interested in understanding their > constraints, but I imagine those applications are in a distinct minority. I'm thinking of trying to study some particular application, or DNS resolve implementation or something, myself. If I find some time to spare... Stig > > Regards, > -drc > > > -- > to unsubscribe send a message to [EMAIL PROTECTED] with the > word 'unsubscribe' in a single line as the message text body. > archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
