John Levine wrote:

I'm wondering how much content is used TiVo style, not in real time, but fairly soon thereafter. It might make sense to multicast feeds to local caches so when people actually want stuff, it doesn't come all the way across the net.

I think the good folks at Akamai may have already thought of this. :-) -- Jay Hennigan - CCIE #7880 - Network Engineering - jay@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV _______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog

...

I'm wondering how much content is used TiVo style, not in real time, but fairly soon thereafter. It might make sense to multicast feeds to local caches so when people actually want stuff, it doesn't come all the way across the net.

I think the good folks at Akamai may have already thought of this. :-)

Akamai has built a Content Delivery Network (CDN) because they do not have to rely on any specific ISP or any specific IP network functionality. If you go with IP Multicast, or MPLS P2MP(Point to MultiPoint) then you are limited to only using ISPs who have implemented the right protocols and who peer using those protocols. P2P is a lot like CDN because it does not rely on any specific ISP implementation, but as a result of being 100% free of the ISP, P2P also lacks the knowledge of the network topology that it needs to be efficient. Of course, a content provider could leverage P2P by predelivering its content to strategically located sites in the network, just like they do with a CDN. IP multicast and P2MP have routing protocols which tell them where to send content. CDN's are either set up manually or use their own proprietary methods to figure out where to send content. P2P currently doesn't care about topology because it views the net as an amorphous cloud. NNTP, the historical firehose protocol, just floods it out to everyone who hasn't seen it yet but actually, the consumers of an NNTP feed have been set up statically in advance. And this static setup does include knowledge of ISP's network topology, and knowledge of the ISP's economic realities. I'd like to see a P2P protocol that sets up paths dynamically, but allows for inputs as varied as those old NNTP setups. There was also a time when LAN's had some form of economic reality configured in, i.e. some users were only allowed to log into the LAN during certain time periods on certain days. Is there any ISP that wouldn't want some way to signal P2P clients how to use spare bandwidth without ruining the network for other paying customers? --Michael Dillon _______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog

Am 26.04.2008 um 20:42 schrieb Antonio Querubin:

On Sat, 26 Apr 2008, Marc Manthey wrote:

...

" IF we would use multicast" streaming ONLY, for appropriet content , would `nt this " decrease " the overall internet traffic ?

On one hand, the amount of content that is 'live' or 'continuous' and suitable for multicast streaming isn't s large percentage of overall internet traffic to begin with. So the effect of moving most live content to multicast on the Internet would have little overall effect.

right, i am aware of that and i was ment as an hypothetically rant ;)

However, for some live content where the audience is either very large or concentrated on various networks, moving to multicast certainly has significant advantages in reducing traffic on the networks closest to the source or where the viewer concentration is high (particularly where the viewer numbers infrequently spikes significantly higher than the average).

i am not a math genious and i am talking about for example serving 10.000 unicast streams and 10.000 multicast streams would the multicast streams more efficient or lets say , would you need more machines to server 10.000 unicast streams ?

But network providers make their money in part by selling bandwidth. The folks who would need to push for multicast are the live/perishable content providers as they're the ones who'd benefit the most. But if bandwidth is cheap they're not really gonna care.

well , cheap is relative , i bet its cheap where google hosts the NOCs , but its not cheap in brasil , argentinia or indonesia.

...

Isn´t this an argument for ip6 / greenip6 ;) aswell ?

It's an argument for decreasing traffic and improving network efficiency and scalability to handle 'flash crowd events'. IPv6 has nothing to do with it.

thanks for your opinion. Marc

Antonio Querubin whois: AQ7-ARIN

_______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog

...

i am not a math genious and i am talking about for example serving

10.000 unicast streams and 10.000 multicast streams

would the multicast streams more efficient or lets say , would you need more machines to server 10.000 unicast streams ?

hello all ,

...

For 10000 concurrent unicast streams you'd need not just more servers.

thanks for the partizipation on this topic , i was "theoreticly " speaking and this was actually what i wanted to hear ;)

You'd need a significantly different network infrastructure than something that would have to handle only a single multicast stream. But supporting multicast isn't without it's own problems either. Even the destination networks would have to consider implementing IGMP and/or MLD snooping in their layer 2 devices to obtain maximum benefit from multicast.

i was reading some papers about multicast activity on 9/11 and it was interesting to read that it just worked even when most of the "big player " sites went offline, so this gives me another approach for emergency scenarios. <http://www.nanog.org/mtg-0110/ppt/eubanks.ppt> <http://multicast.internet2.edu/workshops/illinois/internet2-multicast-worksh...

Akamai has built a Content Delivery Network (CDN) because they do not have to rely on any specific ISP or any specific IP network functionality. If you go with IP Multicast, or MPLS P2MP(Point to MultiPoint) then you are limited to only using ISPs who have implemented the right protocols and who peer using those protocols.

so this is similar to a "wallet garden " and not what we really want , but i was clear about that this is actually the only idea to implement a "new" technologie into an existing infrastructure. regards and sorry for beeing a bit offtopic Marc <www.lettv.de>

Antonio Querubin whois: AQ7-ARIN

_______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog

I became aware of something called espn360 last fall. I just did a google search so I could provide a URL, but one of the top search responses was a Aug 9, 2007 posting saying "ESPN360 Dies an Unneccessary Death: A Lesson in Network Neutrality ..." I don't think it's dead, though, and maybe if you don't know about it, you can do your own google search. I think Disney/ABC thinks they can get individual ISPs to pay them to carry sports audio/video streams. I suppose that would be yet another multicast stream method, assuming an ISP location had multiple customers viewing the same stream. Are other content providers trying to do something similar? How are operators dealing with this? What opinions are there in the operator community? Mr. Dale _______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog

Dale: ESPN360 used to be something that internet subscribers paid for themselves, but now it's something that ISPs (most interesting to those who are also video providers) can offer. If you google around you can find a pretty good Wikipedia page on ESPN360. I looked into this for our operations because we do both (internet and video). The price was reasonable and you only pay on the number of internet subs that meet their minimum performance standards. Since 50% of our user base is at 128/128 kbps, that's a lot of subscribers we didn't need to pay for. In the end, I didn't get buy-in from the rest of the management team into adding this. I think they perceived (and probably correctly so) that too few of our users would actually *use* it. If I could get even 2% of our customer base seriously interested I think we would move on this. BTW, there's no multicast (at lease from Disney/ABC directly) involved. It's just another unicast video stream like YouTube. Frank -----Original Message----- From: Dale Carstensen [mailto:dlc@lampinc.com] Sent: Monday, April 28, 2008 8:02 AM To: nanog@nanog.org Subject: Re: [NANOG] would ip6 help us safeing energy ? I became aware of something called espn360 last fall. I just did a google search so I could provide a URL, but one of the top search responses was a Aug 9, 2007 posting saying "ESPN360 Dies an Unneccessary Death: A Lesson in Network Neutrality ..." I don't think it's dead, though, and maybe if you don't know about it, you can do your own google search. I think Disney/ABC thinks they can get individual ISPs to pay them to carry sports audio/video streams. I suppose that would be yet another multicast stream method, assuming an ISP location had multiple customers viewing the same stream. Are other content providers trying to do something similar? How are operators dealing with this? What opinions are there in the operator community? Mr. Dale _______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog _______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog

evening all , found an related article about the power consumtion saving in ip6. - Up to 300 Megawatt Worth of Keepalive Messages to be Saved by IPv6? http://www.circleid.com/posts/81072_megawatts_keepalive_ipv6/ http://www.niksula.hut.fi/~peronen/publications/haverinen_siren_eronen_vtc20... still interested in other links and publications regards Marc -- "Use your imagination not to scare yourself to death but to inspire yourself to life." Les enfants teribbles - research and deployment Marc Manthey - head of research and innovation Hildeboldplatz 1a D - 50672 Köln - Germany Tel.:0049-221-3558032 Mobil:0049-1577-3329231 jabber :marc@kgraff.net blog : http://www.let.de ipv6 http://www.ipsix.org xing : https://www.xing.com/profile/Marc_Manthey

On 5 mei 2008, at 0:57, Adrian Chadd wrote:

I'd seriously be looking at making current -software- run more efficiently before counting ipv6-related power savings.

Good luck with that. Obviously there is a lot to be gained at that end, but that doesn't mean we should ignore power use in the network. One thing that could help here is to increase the average packet size. Whenever I've looked, this has always hovered around 500 bytes for internet traffic. If we can get jumboframes widely deployed, it should be doable to double that. Since most work in routers and switches is per-packet rather than per-bit, this has the potential to save a good amount of power. Now obviously this only works in practice if routers and switches actually use less power when there are fewer packets, which is not a given. It helps even more if the maximum throughput isn't based on 64- byte packets. Why do people demand that, anyway? The only thing I can think of is DoS attacks. But that can be solved by only allowing end- users to send an average packet size of 500 (or 250, or whatever) bytes. So if you have a 10 Mbps connection you don't get to send 14000 64-byte packets per second, but a maximum of 2500 packets per second. So with 64-byte packets you only get to use 1.25 Mbps. I'm guessing having a 4x10Gbps line card that "only" does 14 Mpps total rather than 14 Mpps per port would be a good deal cheaper. Obviously if you're a service provider with a customer that sends 10 Gbps worth of VoIP you can only use one of those 4 ports but somehow, I'm thinking few people use 10 Gbps worth of VoIP... Iljitsch PS. Am I the only one who is annoyed by the reduction in usable subject space by the superfluous [NANOG]?

On 5 mei 2008, at 21:56, Mike Fedyk wrote:

...

So if you have a 10 Mbps connection you don't get to send 14000 64-byte packets per second, but a maximum of 2500 packets per second. So with 64-byte packets you only get to use 1.25 Mbps.

You have just cut out the VoIP industry, TCP setup, IM or most types of real-time services on the Internet.

Of course not. Like I said, as an average end-user with 10 Mbps you get to send a maximum of 2500 packets per second. That's plenty to do VoIP, set up TCP sessions or do IM. You just don't get to send the full 10 Mbps at this size.

On Tue, May 06, 2008, Nathan Ward wrote:

Maybe you just start calling "10Mbps" "10Mbps, assuming a 500b average packet size."

Anyway, nice idea in theory - putting more real world limitations in to sold product limitations - but I don't see it working out with marketing people, etc. unless someone has been doing it for years already. It'd be good if the world were all engineers though, huh?

NPE-XXX, anyone? Adrian

found an related article about the power consumtion saving in ip6.

no, you found an article about bad nat design in a market lacking the ability to stanardize on a clean one. if you look, you can also find statements by the same folk explaining how ipv6 will help prevent car accidents involving falling rocks. yes, i am serious. note that i work very hard on ipv6 deployment. i just don't encourage or support marketing insanity. randy

Am 29.04.2008 um 18:31 schrieb Jorge Amodio:

besides the multicast argument,

hi Jorge , all ok, i was talking about a "campus" installation imagine you want to broadcast a live event so 10.000 unicast streams and 10.000 multicast stream for example. from what toni replyed , you need less horsepower with the multicast streams

For 10000 concurrent unicast streams you'd need not just more servers.

but would like to know how this could be calculated. my 00.2 ;) marc - Les enfants teribbles - research and deployment Marc Manthey - Hildeboldplatz 1a D - 50672 Köln - Germany Tel.:0049-221-3558032 Mobil:0049-1577-3329231 jabber :marc@kgraff.net blog : http://www.let.de ipv6 http://www.ipsix.org Klarmachen zum Ändern! http://www.piratenpartei-koeln.de _______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog