[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Why delaying initial packets matters
On Feb 15, 2008, at 4:30 AM, Lars Eggert wrote:
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.
The experience with Multicast in this century has been that stack +
application changes, even with vendor support (such as IGMPv3 + SSM),
take about a decade to propagate into something like a critical mass.
Hasn't, for that matter, IPv6 also taken about a decade to get to
where we can consider IPv6 only plenaries ? If anything, I would
regard that delay as likely to increase in the future.
There is probably a role for changes intended for the far future, but
I wouldn't do it lightly.
Regards
Marshall
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
--
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