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 [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
