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 evenfewer for which scalability is a serious issue, compared to a fewbillion hosts. Deploying something new at the network layer that might require changes to host stacks or applications to maintain performanceat 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 purepull-based system, the only applications that would need to change would be those that are very sensitive to delays in the initial flow RTT. ToI agreedate, 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 theycan be streamed from the same source address. If they are streamed frommultiple 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... StigRegards, -drc -- 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
-- 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