Re: Inevitable death, was Re: Verizon Public Policy on Netflix
Netflix's arrangement isn't "peeering." (They call it that, misleadingly, as a way of attempting to characterize the connection as one that doesn't require money to change hands.) ISPs peer to connect their mutual Internet customers. Netflix is not an ISP, so it cannot be said to be "peering." It's merely establishing a dedicated link to an ISP while trying to avoid paying the ISP for the resources used. But regardless of the financial arrangements, such a connection doesn't require an ASN or BGP. In fact, it doesn't even require a registered IP address at either end! A simple Ethernet connection (or a leased line of any kind, in fact; it could just as well be a virtual circuit) and a static route would work just fine. --Brett Glass At 09:35 PM 7/14/2014, Mike Lyon wrote:
So if Netflix was at 1850 Pearl, you wouldn't be able to peer with them anyways cuz u have no ASN?
So we are splitting hairs with what "peering" means? And I am sure Netflix (or any other content / network / CDN provider) would be more than happy to statically route to you? Doubtful. Dude, put your big boy pants on, get an ASN, get some IP space, I am a smaller ISP than you I am sure and I have both. It's not rocket science. How are other networks suppose to take you seriously if you don't have an ASN? -Mike On Mon, Jul 14, 2014 at 8:51 PM, Brett Glass <nanog@brettglass.com> wrote:
Netflix's arrangement isn't "peeering." (They call it that, misleadingly, as a way of attempting to characterize the connection as one that doesn't require money to change hands.)
ISPs peer to connect their mutual Internet customers. Netflix is not an ISP, so it cannot be said to be "peering." It's merely establishing a dedicated link to an ISP while trying to avoid paying the ISP for the resources used.
But regardless of the financial arrangements, such a connection doesn't require an ASN or BGP. In fact, it doesn't even require a registered IP address at either end! A simple Ethernet connection (or a leased line of any kind, in fact; it could just as well be a virtual circuit) and a static route would work just fine.
--Brett Glass
At 09:35 PM 7/14/2014, Mike Lyon wrote:
So if Netflix was at 1850 Pearl, you wouldn't be able to peer with them
anyways cuz u have no ASN?
-- Mike Lyon 408-621-4826 mike.lyon@gmail.com http://www.linkedin.com/in/mlyon
I am just guessing but you probably have not been in the service provider space. Peering in my experience has always required an ASN and BGP as a pre-requisite. That is because all service providers use BGP communities and various other mechanisms to control these connections. Sure you could do a point to point static routed circuit but do you really expect me to put in static routes for your network and then make sure I don’t announce them to the wrong places under my AS number? Oh, and I supposed I have to write ACLs for all of your netblocks to be certain that you don't use me for transit. Uhhhh, nope. Our networks are far to large and complex to manually manage like that. Just try to ask a provider to do that. When he stops laughing, let me know what he says. ISPs, by the way, peer in order to minimize the amount of transit they have to purchase (almost all ISPs smaller than a tier 1 have at least some paid transit) and to direct traffic off of congested links. If a direct connection to NetFlix saves me money on transit and helps my customers that is what I will do. The name of the game is to decongest your network for the least amount of money. That is usually done by getting the traffic directly to an efficient exit point ASAP over the least expensive transport medium. Please don’t go on and on about what might work in theory regarding interconnection, a lot of the people on here are the ones that know how things work in reality. Reality is that no one will peer with you without an AS and your own space that goes with that. If you have not reached that level of sophistication, nobody is peering with you. Steven Naslund Chicago IL On Mon, Jul 14, 2014 at 8:51 PM, Brett Glass <nanog@brettglass.com> wrote:
Netflix's arrangement isn't "peeering." (They call it that, misleadingly, as a way of attempting to characterize the connection as one that doesn't require money to change hands.)
ISPs peer to connect their mutual Internet customers. Netflix is not an ISP, so it cannot be said to be "peering." It's merely establishing a dedicated link to an ISP while trying to avoid paying the ISP for the resources used.
But regardless of the financial arrangements, such a connection doesn't require an ASN or BGP. In fact, it doesn't even require a registered IP address at either end! A simple Ethernet connection (or a leased line of any kind, in fact; it could just as well be a virtual circuit) and a static route would work just fine.
--Brett Glass
On 7/15/2014 午後 12:51, Brett Glass wrote:
But regardless of the financial arrangements, such a connection doesn't require an ASN or BGP. In fact, it doesn't even require a registered IP address at either end! A simple Ethernet connection (or a leased line of any kind, in fact; it could just as well be a virtual circuit) and a static route would work just fine.
--Brett Glass
At 09:35 PM 7/14/2014, Mike Lyon wrote:
So if Netflix was at 1850 Pearl, you wouldn't be able to peer with them anyways cuz u have no ASN?
Why would any content network (realistically) be interested in manually maintaining your prefixes in their routing table? BGP exists for a reason, you really should be using it. The fact that you don't have an ASN means that automatically creating said static routes based on data from some IRRd is likely more trouble than it's likely to be worth as well.
But regardless of the financial arrangements, such a connection doesn't require an ASN or BGP. In fact, it doesn't even require a registered IP address at either end! A simple Ethernet connection (or a leased line of any kind, in fact; it could just as well be a virtual circuit) and a static route would work just fine.
Anybody else feel a vendor t-shirt in the works? "Who needs BGP to peer, a static route would work just fine!" Time to get back into the Hot Tub Time Machine and back on point. *hangs head in shame*
On Mon, Jul 14, 2014 at 11:51 PM, Brett Glass <nanog@brettglass.com> wrote:
Netflix's arrangement isn't "peeering." (They call it that, misleadingly, as a way of attempting to characterize the connection as one that doesn't require money to change hands.)
'peering' here probably really means 'bgp peer', and it probably also means to be used in a 'mutually benefiting the two parties' way. which it seems it would be beneficial to use the pipe to pick up netflix traffic from the exchange switch, AND to pick up other peer networks' traffic at the same switch. This does mean you'd need to use an ASN and do BGP in a public sort of fashion though. You COULD just get a single link to netflix in DEN, but that seems dumb (or wasteful, or silly... or sub-optimal)... when there's a switch fabric to exploit in offloading some of your traffic and reducing hopcount between your customers and their interested content.
ISPs peer to connect their mutual Internet customers. Netflix is not an ISP, so it cannot be said to be "peering." It's merely establishing a dedicated link to an ISP while trying to avoid paying the ISP for the resources used.
ISP's peer to avoid costs, not all costs, but some costs. Hopefully the 'peering arrangement' is more beneficial than just straight transit between the two parties.... else you'd just use transit. -chris
In common ISP language, peering is a connection between equals that is mutually beneficial so no money usually changes hands, peering connections are usually AS to AS without the ability to transit through to other AS (or at least some kind of policy that prevents you from using your peer for full transit. Transit is paid for bandwidth that "transits" through an AS to the Internet at large. I can use a paid for transit link to get to the entire Internet (hopefully). I agree that it appears that Netflix should be mostly an access or transit customer rather than a peering partner, however since high bandwidth to Netflix will make the ISPs customers happy, it is probably beneficial to come to some kind of agreement that helps you get the dedicated Netflix connection running. This is kind of the arrangement that exists with Akamai, where it is a mutually beneficial arrangement. I host their server which makes my customer happy, make Akamai's customer happy, and helps lower my costs by allowing me to minimize transit traffic. I don’t see why Netflix would be treated any different. If carriers don’t like the way Netflix servers work, then don’t put them in your network and deal with the bandwidth issues. It is a technical tradeoff whichever way you decide to go. Transit is paid for bandwidth that "transits" through an AS to the Internet at large. I have the right to send anything to anywhere on a transit circuit from say Comcast. Over a peering circuit, I should only be sending traffic bound for a Comcast customer or downstream provider. Steven Naslund Chicago IL
On 15 July 2014 04:51, Brett Glass <nanog@brettglass.com> wrote:
Netflix's arrangement isn't "peeering." (They call it that, misleadingly, as a way of attempting to characterize the connection as one that doesn't require money to change hands.)
In my book (As a network operator in the UK) Netflix's proposed arrangement is peering. They have traffic they need to get onto my network. I don't want to pay transit. They don't want to pay transit. I'm happily going to connect to them for free. Why should I charge them? My (our?) customer wants the data they are sending, so I need to find some way to get it to them. This is the most cost affective, deterministic, controllable way I have.
ISPs peer to connect their mutual Internet customers. Netflix is not an ISP, so it cannot be said to be "peering." It's merely establishing a dedicated link to an ISP while trying to avoid paying the ISP for the resources used.
They may not be an ISP in the traditional sense, ie you can't buy hosting, an access circuit etc from them, however they are a provider of a service that is accessible via the Internet. Dave
participants (7)
-
Brett Glass -
Charles Gucker -
Christopher Morrow -
Dave Bell -
Mike Lyon -
Naslund, Steve -
Paul S.