Overall Netflix bandwidth usage numbers on a network?
Been lurking for a while and posed a question to a few folks without much response, figured someone here might've done something like this already. So, before I go about building wheels that already exist: I'm interested in doing a bit of a passive survey of bandwidth usage on my network (smallish isp, a few thousand DSL/FTTx customers) to understand the percentage of average/overall traffic generated by Netflix streaming. What I have available is a few gigabit transport switches providing me with mirror ports, a juniper MX series router running 10.4 code, plenty of BSD machines and libpcap-fu. What I'm looking for is either a timed-average or moments-glance number of the traffic. For instance, on an interface moving 150mbit/sec total, 50mbit/sec of it is attributed to Netflix right now. I'm pretty handy with RRDtool, so that isn't out of the question, either. I've really only spent dinnertime considering this, but have come up with two potential approaches so far, and haven't actively investigated either of them: * firewall terms and counters on the MX router + snmp * writing a quick libpcap application to filter and count in a completely out-of-band way on one of my monitoring hosts Some challenges I can see: * Nailing down the streaming source for Netflix, that is, IP ranges etc. * Making assumptions about CDN source IPs that could be used for something else, and further, should I care? Happy to hear thoughts about this, helpful or not! I know Netflix themselves have probably done plenty of studies like this, but pretty likely not limited to my customer base. Not aiming for anything creepy or crazy, just some vague understanding of what's going on, and the ability to do some trending for future planning. -- Jonathan Towne
Surely this is what Netflow is for. no need to re-invent the wheel. Andrew On Sat, Dec 3, 2011 at 12:47 AM, Jonathan Towne <jtowne@slic.com> wrote:
Been lurking for a while and posed a question to a few folks without much response, figured someone here might've done something like this already.
So, before I go about building wheels that already exist:
I'm interested in doing a bit of a passive survey of bandwidth usage on my network (smallish isp, a few thousand DSL/FTTx customers) to understand the percentage of average/overall traffic generated by Netflix streaming.
What I have available is a few gigabit transport switches providing me with mirror ports, a juniper MX series router running 10.4 code, plenty of BSD machines and libpcap-fu.
What I'm looking for is either a timed-average or moments-glance number of the traffic. For instance, on an interface moving 150mbit/sec total, 50mbit/sec of it is attributed to Netflix right now. I'm pretty handy with RRDtool, so that isn't out of the question, either.
I've really only spent dinnertime considering this, but have come up with two potential approaches so far, and haven't actively investigated either of them:
* firewall terms and counters on the MX router + snmp * writing a quick libpcap application to filter and count in a completely out-of-band way on one of my monitoring hosts
Some challenges I can see:
* Nailing down the streaming source for Netflix, that is, IP ranges etc. * Making assumptions about CDN source IPs that could be used for something else, and further, should I care?
Happy to hear thoughts about this, helpful or not! I know Netflix themselves have probably done plenty of studies like this, but pretty likely not limited to my customer base. Not aiming for anything creepy or crazy, just some vague understanding of what's going on, and the ability to do some trending for future planning.
-- Jonathan Towne
Wow.. not sure how I missed that option. Exactly why I posted before dumping a bunch of time into a bottomless bucket! Thanks.. :) -- Jonathan Towne On Sat, Dec 03, 2011 at 12:56:34AM +0000, Andrew Mulholland scribbled: # Surely this is what Netflow is for. # # # no need to re-invent the wheel. # # # Andrew # # # On Sat, Dec 3, 2011 at 12:47 AM, Jonathan Towne <jtowne@slic.com> wrote: # # > Been lurking for a while and posed a question to a few folks without much # > response, figured someone here might've done something like this already. # > # > So, before I go about building wheels that already exist: # > # > I'm interested in doing a bit of a passive survey of bandwidth usage on # > my network (smallish isp, a few thousand DSL/FTTx customers) to understand # > the percentage of average/overall traffic generated by Netflix streaming. # > # > What I have available is a few gigabit transport switches providing me with # > mirror ports, a juniper MX series router running 10.4 code, plenty of BSD # > machines and libpcap-fu. # > # > What I'm looking for is either a timed-average or moments-glance number # > of the traffic. For instance, on an interface moving 150mbit/sec total, # > 50mbit/sec of it is attributed to Netflix right now. I'm pretty handy with # > RRDtool, so that isn't out of the question, either. # > # > I've really only spent dinnertime considering this, but have come up with # > two potential approaches so far, and haven't actively investigated either # > of them: # > # > * firewall terms and counters on the MX router + snmp # > * writing a quick libpcap application to filter and count in a completely # > out-of-band way on one of my monitoring hosts # > # > Some challenges I can see: # > # > * Nailing down the streaming source for Netflix, that is, IP ranges etc. # > * Making assumptions about CDN source IPs that could be used for something # > else, and further, should I care? # > # > Happy to hear thoughts about this, helpful or not! I know Netflix # > themselves # > have probably done plenty of studies like this, but pretty likely not # > limited # > to my customer base. Not aiming for anything creepy or crazy, just some # > vague understanding of what's going on, and the ability to do some trending # > for future planning. # > # > -- Jonathan Towne # > # >
Wow.. not sure how I missed that option. Exactly why I posted before dumping a bunch of time into a bottomless bucket!
Thanks.. :)
-- Jonathan Towne
On Sat, Dec 03, 2011 at 12:56:34AM +0000, Andrew Mulholland scribbled: # Surely this is what Netflow is for. # # # no need to re-invent the wheel. # # # Andrew # # # On Sat, Dec 3, 2011 at 12:47 AM, Jonathan Towne <jtowne@slic.com> wrote: # # > Been lurking for a while and posed a question to a few folks without much # > response, figured someone here might've done something like this already. # > # > So, before I go about building wheels that already exist: # > # > I'm interested in doing a bit of a passive survey of bandwidth usage on # > my network (smallish isp, a few thousand DSL/FTTx customers) to understand # > the percentage of average/overall traffic generated by Netflix streaming. # > # > What I have available is a few gigabit transport switches providing me with # > mirror ports, a juniper MX series router running 10.4 code, plenty of BSD # > machines and libpcap-fu. # > # > What I'm looking for is either a timed-average or moments-glance number # > of the traffic. For instance, on an interface moving 150mbit/sec total, # > 50mbit/sec of it is attributed to Netflix right now. I'm pretty handy with # > RRDtool, so that isn't out of the question, either. # > # > I've really only spent dinnertime considering this, but have come up with # > two potential approaches so far, and haven't actively investigated either # > of them: # > # > * firewall terms and counters on the MX router + snmp # > * writing a quick libpcap application to filter and count in a completely # > out-of-band way on one of my monitoring hosts # > # > Some challenges I can see: # > # > * Nailing down the streaming source for Netflix, that is, IP ranges etc. # > * Making assumptions about CDN source IPs that could be used for something # > else, and further, should I care? # > # > Happy to hear thoughts about this, helpful or not! I know Netflix # > themselves # > have probably done plenty of studies like this, but pretty likely not # > limited # > to my customer base. Not aiming for anything creepy or crazy, just some # > vague understanding of what's going on, and the ability to do some
Also checkout Adrian Cockcroft presentations on their architecture which describes how they use aws and CDns etc Martin On Saturday, 3 December 2011, Jonathan Towne <jtowne@slic.com> wrote: trending
# > for future planning. # > # > -- Jonathan Towne # > # >
-- -- Martin Hepworth Oxford, UK
Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services). Martin Hepworth wrote the following on 12/3/2011 2:36 AM:
Also checkout Adrian Cockcroft presentations on their architecture which describes how they use aws and CDns etc
Martin
Feel free to contact peering@netflix<dot>com - we're happy to provide you with delivery statistics for traffic terminating on your network. Regards, -Dave Temkin Netflix On 12/7/11 8:57 AM, Blake Hudson wrote:
Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services).
Martin Hepworth wrote the following on 12/3/2011 2:36 AM:
Also checkout Adrian Cockcroft presentations on their architecture which describes how they use aws and CDns etc
Martin
Which leads to a question to be asked... Is netflix willing to peer directly with ISP / NSP's ? Regards. Faisal Imtiaz Snappy Internet& Telecom On 12/11/2011 7:29 PM, Dave Temkin wrote:
Feel free to contact peering@netflix<dot>com - we're happy to provide you with delivery statistics for traffic terminating on your network.
Regards, -Dave Temkin Netflix
On 12/7/11 8:57 AM, Blake Hudson wrote:
Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services).
Martin Hepworth wrote the following on 12/3/2011 2:36 AM:
Also checkout Adrian Cockcroft presentations on their architecture which describes how they use aws and CDns etc
Martin
Netflix uses CDNs for content delivery and the platform runs in EC2. What would peering with them achieve? Sent from my iPhone On Dec 11, 2011, at 18:06, Faisal Imtiaz <faisal@snappydsl.net> wrote:
Which leads to a question to be asked...
Is netflix willing to peer directly with ISP / NSP's ?
Regards.
Faisal Imtiaz Snappy Internet& Telecom
On 12/11/2011 7:29 PM, Dave Temkin wrote:
Feel free to contact peering@netflix<dot>com - we're happy to provide you with delivery statistics for traffic terminating on your network.
Regards, -Dave Temkin Netflix
On 12/7/11 8:57 AM, Blake Hudson wrote:
Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services).
Martin Hepworth wrote the following on 12/3/2011 2:36 AM:
Also checkout Adrian Cockcroft presentations on their architecture which describes how they use aws and CDns etc
Martin
On Sun, 11 Dec 2011 19:21:49 PST, Joel Jaeggli said:
Netflix uses CDNs for content delivery and the platform runs in EC2. What would peering with them achieve?
I suspect Faisal's *real* question is "Who at Netflix do I talk to in order to discuss mutually beneficial traffic engineering?"
Simple, keep traffic off paid ip transit circuits.... Faisal On Dec 11, 2011, at 10:21 PM, Joel Jaeggli <joelja@bogus.com> wrote:
Netflix uses CDNs for content delivery and the platform runs in EC2. What would peering with them achieve?
Sent from my iPhone
On Dec 11, 2011, at 18:06, Faisal Imtiaz <faisal@snappydsl.net> wrote:
Which leads to a question to be asked...
Is netflix willing to peer directly with ISP / NSP's ?
Regards.
Faisal Imtiaz Snappy Internet& Telecom
On 12/11/2011 7:29 PM, Dave Temkin wrote:
Feel free to contact peering@netflix<dot>com - we're happy to provide you with delivery statistics for traffic terminating on your network.
Regards, -Dave Temkin Netflix
On 12/7/11 8:57 AM, Blake Hudson wrote:
Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services).
Martin Hepworth wrote the following on 12/3/2011 2:36 AM:
Also checkout Adrian Cockcroft presentations on their architecture which describes how they use aws and CDns etc
Martin
On Sun, Dec 11, 2011 at 10:46 PM, Faisal Imtiaz <faisal@snappydsl.net> wrote:
Simple, keep traffic off paid ip transit circuits....
(I think joel's point was: "peer with amazon, done-and-done")
Faisal
On Dec 11, 2011, at 10:21 PM, Joel Jaeggli <joelja@bogus.com> wrote:
Netflix uses CDNs for content delivery and the platform runs in EC2. What would peering with them achieve?
Sent from my iPhone
On Dec 11, 2011, at 18:06, Faisal Imtiaz <faisal@snappydsl.net> wrote:
Which leads to a question to be asked...
Is netflix willing to peer directly with ISP / NSP's ?
Regards.
Faisal Imtiaz Snappy Internet& Telecom
On 12/11/2011 7:29 PM, Dave Temkin wrote:
Feel free to contact peering@netflix<dot>com - we're happy to provide you with delivery statistics for traffic terminating on your network.
Regards, -Dave Temkin Netflix
On 12/7/11 8:57 AM, Blake Hudson wrote:
Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services).
Martin Hepworth wrote the following on 12/3/2011 2:36 AM:
Also checkout Adrian Cockcroft presentations on their architecture which describes how they use aws and CDns etc
Martin
Thanks for the explanation...did not consider that before...will investigate.., any tips that can be shared will be welcome. :) Faisal On Dec 11, 2011, at 10:49 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Sun, Dec 11, 2011 at 10:46 PM, Faisal Imtiaz <faisal@snappydsl.net> wrote:
Simple, keep traffic off paid ip transit circuits....
(I think joel's point was: "peer with amazon, done-and-done")
Faisal
On Dec 11, 2011, at 10:21 PM, Joel Jaeggli <joelja@bogus.com> wrote:
Netflix uses CDNs for content delivery and the platform runs in EC2. What would peering with them achieve?
Sent from my iPhone
On Dec 11, 2011, at 18:06, Faisal Imtiaz <faisal@snappydsl.net> wrote:
Which leads to a question to be asked...
Is netflix willing to peer directly with ISP / NSP's ?
Regards.
Faisal Imtiaz Snappy Internet& Telecom
On 12/11/2011 7:29 PM, Dave Temkin wrote:
Feel free to contact peering@netflix<dot>com - we're happy to provide you with delivery statistics for traffic terminating on your network.
Regards, -Dave Temkin Netflix
On 12/7/11 8:57 AM, Blake Hudson wrote:
Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services).
Martin Hepworth wrote the following on 12/3/2011 2:36 AM: > Also checkout Adrian Cockcroft presentations on their architecture which > describes how they use aws and CDns etc > > Martin > >
On 12/11/11 19:49 , Christopher Morrow wrote:
On Sun, Dec 11, 2011 at 10:46 PM, Faisal Imtiaz <faisal@snappydsl.net> wrote:
Simple, keep traffic off paid ip transit circuits....
(I think joel's point was: "peer with amazon, done-and-done")
also probably your relationships to akamai and level3
Faisal
On Dec 11, 2011, at 10:21 PM, Joel Jaeggli <joelja@bogus.com> wrote:
Netflix uses CDNs for content delivery and the platform runs in EC2. What would peering with them achieve?
Sent from my iPhone
On Dec 11, 2011, at 18:06, Faisal Imtiaz <faisal@snappydsl.net> wrote:
Which leads to a question to be asked...
Is netflix willing to peer directly with ISP / NSP's ?
Regards.
Faisal Imtiaz Snappy Internet& Telecom
On 12/11/2011 7:29 PM, Dave Temkin wrote:
Feel free to contact peering@netflix<dot>com - we're happy to provide you with delivery statistics for traffic terminating on your network.
Regards, -Dave Temkin Netflix
On 12/7/11 8:57 AM, Blake Hudson wrote:
Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services).
Martin Hepworth wrote the following on 12/3/2011 2:36 AM: > Also checkout Adrian Cockcroft presentations on their architecture which > describes how they use aws and CDns etc > > Martin > >
On Dec 12, 2011, at 12:18 AM, Joel jaeggli wrote:
On 12/11/11 19:49 , Christopher Morrow wrote:
On Sun, Dec 11, 2011 at 10:46 PM, Faisal Imtiaz <faisal@snappydsl.net> wrote:
Simple, keep traffic off paid ip transit circuits....
(I think joel's point was: "peer with amazon, done-and-done")
also probably your relationships to akamai and level3
Netflix's EC2 instances do not speak to end users AFAIK. I believe Akamai, LLNW, & L3 are the only companies that stream movies for Netflix. Peer with the CDNs to save your transit. Happy to be educated otherwise if someone knows more than I do. Netflix's client is also _very_ intelligent. If a user cannot get high enough quality from CDN_1, it will switch to CDN_2 without interrupting the stream. Which is nice if you have good connectivity to one but not the other CDN. (Note I spoke of "good", not "inexpensive" connectivity. The NF client doesn't know how much it costs you to show a video, only whether there is packet loss.) -- TTFN, patrick
Faisal
On Dec 11, 2011, at 10:21 PM, Joel Jaeggli <joelja@bogus.com> wrote:
Netflix uses CDNs for content delivery and the platform runs in EC2. What would peering with them achieve?
Sent from my iPhone
On Dec 11, 2011, at 18:06, Faisal Imtiaz <faisal@snappydsl.net> wrote:
Which leads to a question to be asked...
Is netflix willing to peer directly with ISP / NSP's ?
Regards.
Faisal Imtiaz Snappy Internet& Telecom
On 12/11/2011 7:29 PM, Dave Temkin wrote:
Feel free to contact peering@netflix<dot>com - we're happy to provide you with delivery statistics for traffic terminating on your network.
Regards, -Dave Temkin Netflix
On 12/7/11 8:57 AM, Blake Hudson wrote: > Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services). > > > Martin Hepworth wrote the following on 12/3/2011 2:36 AM: >> Also checkout Adrian Cockcroft presentations on their architecture which >> describes how they use aws and CDns etc >> >> Martin >> >> >
Hi!
I believe Akamai, LLNW, & L3 are the only companies that stream movies for Netflix. Peer with the CDNs to save your transit.
That would be good if more than one of those CDNs peered openly.
So what one doesnt? Akamai will peer with you anywhere and i doubt LLNW will give you trouble. L3, well, they run a superb network and even more superb pricing, so why would they peer with anyone ;) I still think, old fashioned me, that a CDN doesnt do go without peering but some feel otherwise. Bye, Raymond.
On Mon Dec 12, 2011 at 10:11:54PM +0100, Raymond Dijkxhoorn wrote:
Akamai will peer with you anywhere and i doubt LLNW will give you trouble.
LLNW are restictive on peering.
L3, well, they run a superb network and even more superb pricing, so why would they peer with anyone ;)
And as I use L3 for transit, they'd never peer with me. Not that they peer with anyone outside the cabal anyway.
I still think, old fashioned me, that a CDN doesnt do go without peering but some feel otherwise.
Quite so. I don't get why CDNs don't all peer openly. I guess most (i.e. those which aren't Akamai) are more concerned with making money than with delivering a good service to the end user. Simon
On 2011-12-12, at 4:22 PM, Simon Lockhart <simon@slimey.org> wrote:
I guess most (i.e. those which aren't Akamai) are more concerned with making money than with delivering a good service to the end user.
Really? I always thought that higher profits and buying transit were mutually exclusive relative to higher profits and openly peering. So what you are saying is that one stands to make more by paying upstreams for bit swapping? How's that work? If the argument is that the opex required for maintaining peering relationships is too expensive relative to the direct and indirect cost of buying bandwidth, I love to be edumacated on how that math actually works because it makes absolutely no sense to me. -- Sent from my mobile device
On Dec 12, 2011, at 5:00 PM, Jason Lixfeld wrote:
On 2011-12-12, at 4:22 PM, Simon Lockhart <simon@slimey.org> wrote:
I guess most (i.e. those which aren't Akamai) are more concerned with making money than with delivering a good service to the end user.
Really? I always thought that higher profits and buying transit were mutually exclusive relative to higher profits and openly peering.
So what you are saying is that one stands to make more by paying upstreams for bit swapping? How's that work?
You are assuming that peering with $ISP will lower someone's transit bill. That is demonstrably false in the case of Level 3 who (to a first approximation - please do not argue corner cases) pays no one for transit. It is also likely false over some set of $ISP_n for some peers. As a trivial example, if $NETWORK peers with your transit, not only would it not save them money to peer with you, it may cost them money if peering with you endangers the peering with your upstream. This can happen if $NETWORK does not have enough traffic to qualify for peering with your upstream when your traffic is removed from the link. So peering does not always equal profit. Would that life were so simple! =)
If the argument is that the opex required for maintaining peering relationships is too expensive relative to the direct and indirect cost of buying bandwidth, I love to be edumacated on how that math actually works because it makes absolutely no sense to me.
Peering is not free. I can easily see the cost of bringing up a port to someone with 10 Mbps costing more than it saves for some perfectly valid network topologies. And that's just the most obvious example. The one above is another obvious example. There are reasons not to peer. Assuming there are not is a bad way to enter a negotiation. Put yourself in the place of the other network, figure out what their pain points are - performance, complexity, stability, cost, slot density, spare cycles (human and machine), etc., etc. To be successful in a negotiation, I submit it is useful to help them eliminate one or more of those pain points, i.e. make it worth their while. Remember, my company's peering policy (at public exchanges) is "YES". Since I wrote the policy, you can probably guess my view on peering. But if simply I assumed no one ever had a reason to say "no", I wouldn't get very far. There are two sides to every story. Sometimes the other side is confused, or even flat out wrong, but not always. And even when the other side is wrong, it may not be useful to bash them over the head with the truth. -- TTFN, patrick P.S. I also think "giving good service" is one vital component of "making more money". But maybe I'm silly.
On Mon, Dec 12, 2011 at 2:00 PM, Jason Lixfeld <jason@lixfeld.ca> wrote:
On 2011-12-12, at 4:22 PM, Simon Lockhart <simon@slimey.org> wrote:
I guess most (i.e. those which aren't Akamai) are more concerned with making money than with delivering a good service to the end user.
Really? I always thought that higher profits and buying transit were mutually exclusive relative to higher profits and openly peering.
So what you are saying is that one stands to make more by paying upstreams for bit swapping? How's that work?
If the argument is that the opex required for maintaining peering relationships is too expensive relative to the direct and indirect cost of buying bandwidth, I love to be edumacated on how that math actually works because it makes absolutely no sense to me.
I'm somewhat assuming you're trolling here. :/ but just in case... the lost revenue from peering with someone when you could be charging them transit prices is the tradeoff being referred to here; Level3 isn't in the business of paying upstreams for bandwidth. (well, other than comcast, but that's a different thread entirely. And yes, I suppose that would be me trolling. Bad Matt!) Matt
On Sun, 11 Dec 2011, Christopher Morrow wrote:
On Sun, Dec 11, 2011 at 10:46 PM, Faisal Imtiaz <faisal@snappydsl.net> wrote:
Simple, keep traffic off paid ip transit circuits....
(I think joel's point was: "peer with amazon, done-and-done")
DirectConnect seems to be a good way to get a dedicated 1G or 10G link with AWS: http://aws.amazon.com/directconnect/ It's not settlement-free peering, but it's an option if you can't negotiate something. Maybe it will reduce costs in some use cases. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman@angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
Requests to this address appear to go unanswered? Dave Temkin wrote the following on 12/11/2011 6:29 PM:
Feel free to contact peering@netflix<dot>com - we're happy to provide you with delivery statistics for traffic terminating on your network.
Regards, -Dave Temkin Netflix
On 12/7/11 8:57 AM, Blake Hudson wrote:
Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services).
Martin Hepworth wrote the following on 12/3/2011 2:36 AM:
Also checkout Adrian Cockcroft presentations on their architecture which describes how they use aws and CDns etc
Martin
Same here. ----------------------------------------------------------- Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS"
-----Original Message----- From: Blake Hudson [mailto:blake@ispn.net] Sent: Friday, December 16, 2011 8:11 AM To: Dave Temkin Cc: nanog@nanog.org Subject: Re: Overall Netflix bandwidth usage numbers on a network?
Requests to this address appear to go unanswered?
Dave Temkin wrote the following on 12/11/2011 6:29 PM:
Feel free to contact peering@netflix<dot>com - we're happy to provide you with delivery statistics for traffic terminating on your network.
Regards, -Dave Temkin Netflix
On 12/7/11 8:57 AM, Blake Hudson wrote:
Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services).
Martin Hepworth wrote the following on 12/3/2011 2:36 AM:
Also checkout Adrian Cockcroft presentations on their architecture which describes how they use aws and CDns etc
Martin
I'll take a guess they are back logged - they have been working on our traffic stats since a week before that posting made it to nanog list --- Sent via IPhone On 2011-12-16, at 9:16 AM, "Dennis Burgess" <dmburgess@linktechs.net> wrote:
Same here.
----------------------------------------------------------- Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS"
-----Original Message----- From: Blake Hudson [mailto:blake@ispn.net] Sent: Friday, December 16, 2011 8:11 AM To: Dave Temkin Cc: nanog@nanog.org Subject: Re: Overall Netflix bandwidth usage numbers on a network?
Requests to this address appear to go unanswered?
Dave Temkin wrote the following on 12/11/2011 6:29 PM:
Feel free to contact peering@netflix<dot>com - we're happy to provide you with delivery statistics for traffic terminating on your network.
Regards, -Dave Temkin Netflix
On 12/7/11 8:57 AM, Blake Hudson wrote:
Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services).
Martin Hepworth wrote the following on 12/3/2011 2:36 AM:
Also checkout Adrian Cockcroft presentations on their architecture which describes how they use aws and CDns etc
Martin
Yes, sorry. We will respond to all takers shortly; there was a flaw in our logic used to generate these numbers and wanted to ensure that we were painting an accurate picture. We will have statistics out within a week, hopefully. Thanks, -Dave On 12/16/11 9:55 AM, Paul Stewart wrote:
I'll take a guess they are back logged - they have been working on our traffic stats since a week before that posting made it to nanog list
--- Sent via IPhone
On 2011-12-16, at 9:16 AM, "Dennis Burgess"<dmburgess@linktechs.net> wrote:
Same here.
----------------------------------------------------------- Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik& WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS"
-----Original Message----- From: Blake Hudson [mailto:blake@ispn.net] Sent: Friday, December 16, 2011 8:11 AM To: Dave Temkin Cc: nanog@nanog.org Subject: Re: Overall Netflix bandwidth usage numbers on a network?
Requests to this address appear to go unanswered?
Dave Temkin wrote the following on 12/11/2011 6:29 PM:
Feel free to contact peering@netflix<dot>com - we're happy to provide you with delivery statistics for traffic terminating on your network.
Regards, -Dave Temkin Netflix
On 12/7/11 8:57 AM, Blake Hudson wrote:
Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services).
Martin Hepworth wrote the following on 12/3/2011 2:36 AM:
Also checkout Adrian Cockcroft presentations on their architecture which describes how they use aws and CDns etc
Martin
From: Blake Hudson [mailto:blake@ispn.net]
Yeah, that's an interesting one. We currently utilize netflow for this,
but you also need to consider that netflix streaming is just port 80
www traffic. Because netflix uses CDNs, its difficult to pin down the
traffic to specific hosts in the CDN and say that this traffic was
netflix, while this traffic was the latest windows update (remember
this is often a shared hosting platform). We've done our own testing
and have come to a good solution which uses a combination of nbar,
packet marking, and netflow to come to a conclusion. On a ~160Mbps
link, netflix peaks out between 30-50Mbps around 8-10PM each evening.
The rest of the traffic is predominantly other forms of HTTP traffic
(including other video streaming services).
We (Sandvine) also have a product that does this measurement in the IP network, per CDN, per device type (e.g. how much Netflix on xbox is on Akamai vs Limelight). In addition it measures the delivered quality per CDN. Anyone can feel free to contact me off list for more information. [cid:image001.jpg@01CCBBE1.BCF573A0]
participants (21)
-
Andrew Mulholland -
Blake Hudson -
Christopher Morrow -
Dave Temkin -
David Temkin
-
Dennis Burgess -
Don Bowman -
Faisal Imtiaz -
Jason Lixfeld -
Joel jaeggli -
Joel Jaeggli
-
Jonathan Towne -
Martin Hepworth -
Matthew Petach -
Patrick W. Gilmore -
Paul Stewart -
Peter Beckman -
Raymond Dijkxhoorn -
Shaun Ewing -
Simon Lockhart -
Valdis.Kletnieks＠vt.edu