On Feb 15, 2008, at 3:51 AM, Stig Venaas wrote:
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.
From my point of view, this could be viewed as just a CDN design
constraint (i.e.,
if streams need to be sources from the same /56 to have fast change,
then they can be), but I
know of others who would not like this.
Here is a toy model : I am sending you a 2 Mbps video stream, and you
are on a 100 Mbps connection.
I have a 2 second "group of pictures" or GOP in the MPEG sense, so
you cannot
see a good image until on average 1 second has passed, and ~ 2
seconds in the worst case. To this
time has to be added the RTT time (you to signal me that you want a
new channel, and the data
to get from me to you), plus some time for routers and servers to do
their thing.
Fast channel change / fast start means that I send to you initially
at a fast rate, so that the first 2 seconds
of a new channel are sent in, say, 0.04 seconds (using your full wire
rate). If your RTT is 100 msec,
and internal stuff takes, say, 50 msec, you could be receiving a new
channel 200 msec after you
push the button on the remote, and those sorts of times are viewed as
the desired goal.
After 0.05 seconds (in this toy model), the rate drops down to the
long term value. Something like this is done by, e.g., Quicktime
Streaming Server right now, with initial QTSS bandwidths being
routinely x2 or x3 the long term. (Both live streams and VOD can
benefit from this.)
If all of this is coming from one server farm, all is well and good.
But, what if (like Joost) these
streams are being provided by P2P ? Each new P2P node would have this
delay, which will definitely hinder fast start and may caP2P scales
well for fast start, as you can have more nodes send stuff
in the beginning, but this would destroy that advantage as well. So,
people looking to replace CDN's with P2P meshes for streaming would
probably not like this.
I have seen various plans for in-line advertising where ads come from
different IP addresses than the regular stream, and this would also
mess that up, although there might be engineering work-arounds to that.
Also, you consider not just unicast, but SSM multicast (would every
SSM group join be delayed which the SSM unicast address is being
resolved ?).
Note, too, that many simple web pages have in them pieces from other
servers and other IP addresses (banner ads
are frequently done this way) and so this could put a real
performance hit on web page load times in the real world.
Regards
Marshall
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
--
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
