On 2008-2-15, at 0:40, ext David Conrad wrote:
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.
We've had to change (mostly) the network layer of hosts stacks for IPv6. But here we're talking about changing transport layers and (UDP- speaking) applications. That's a different magnitude of change.
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 date, there has been mention of one (channel changing) on this list. 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 a bit hesitant to make predictions without having at least simulated things, but TCP is somewhat sensitive to packets being delayed, lost or reordered during the first few round-trips, and that's independent of what application runs on top of TCP.
Obviously, for a long bulk transfer, a performance decrease due to delay/loss/reordering during the first few round-trips won't matter much when looking at performance of the whole transfer, but for shorter transfers (think web traffic), the user-perceived performance decrease can be substantial.
Now, that said, if this is serious or not depends a lot on how frequently these events will happen, or, in other words, what caching or pre-fetching of mapping information a given RRG proposal employs, and what the overall traffic matrix is like.
I'll pitch again the idea of combining mapping-based routing with an explicit-feedback scheme. If we're making changes to routers that may potentially decrease end-to-end performance of some communication sessions in some cases, providing the communicating end systems with congestion/capacity information that lets them offset the performance loss or maybe even increase performance seems to be a very attractive option, IMO.
Lars -- to unsubscribe send a message to rrg-request@psg.com 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