Hello This is so simple.
ISP offers xxMbps and should deliver that to the customer. Dear customer. If you cannot stream full quality, upgrade . Dear ISP stop promising xxMbps if you advertise a port cap lower than theoretical port bandwidth. Basically fraud. On Jul 16, 2014 7:19 PM, "Owen DeLong" <o...@delong.com> wrote: > > On Jul 14, 2014, at 06:46 , Miles Fidelman <mfidel...@meetinghouse.net> > wrote: > > > Jay Ashworth wrote: > > > > [ As you might imagine, this is a bit of a hobby horse for me; Verizon's > behavior about municipally owned fiber, and it's attempts to convert post- > Sandy customers in NYS from regulated copper to unregulated FiOS service > leave a pretty bad taste in my mouth about VZN. ] > > > > Jay, > > Quite agree with you on this stuff. I used to spend a good part of my > time working with municipalities on planning fiber builds - so VZ's > behavior on those matters leave a pretty bad taste in my mouth too. But.. > that's kind of a different issue, wouldn't you say? > > > > Am I obtuse or does it all boil down to: > > > > 1. If both Netflix customers, and Netflix all connected to a single > network - customers would be paying for their access connections, and > Netflix would be paying for a pipe big enough to handle the aggregate > demand. > > > > 2. The issue is that customers connect to one network (actually multiple > networks, but lets stick with Verizon for now), and pay Verizon; Netflix > buys aggregate capacity into other networks; with one or more transit > networks in the middle. > > Well, there are multiple possibilities here... > > A: CUST<->ACCESS_NETWORK<->TRANSIT_A<->TRANSIT_N<->NETFLIX > B: CUST<->ACCESS_NETWORK<->TRANSIT<->NETFLIX > C: CUST<->ACCESS_NETWORK<->NETFLIX > > In case A, it's pretty obvious that CUST $->ACCESS_NETWORK$->TRANSIT_A and > NETFLIX$->TRANSIT_N > It's not entirely clear what the economics would be between > TRANSIT_A<->TRANSIT_N, but most likely settlement free peering. > > In case B, it's fairly obvious CUST $->ACCESS_NETWORK and it's less clear > wehter: > B1: ACCESS_NETWORK$->TRANSIT<-$NETFLIX (transit > double-dip) > B2: ACCESS_NETWORK$->TRANSIT and Transit is settlement free > with Netflix (Access pays transit) > B3: TRANSIT<-$NETFLIX and Access is settlement free with > Transit (Netflix pays transit) > > I'm sure in the real world there are likely examples of all three > scenarios. > > In case C, we arrive at what I think most of the argument is actually > about. Obviuosly, CUST$->ACCESS_NETWORK. > The question is whether there should also be ACCESS_NETWORK<-$NETFLIX, > which is what Brett is claiming should happen and what at least one very > large ACCESS_NETWORK has been able to achieve at least temporarily. In my > opinion, this case is a case of Access Double Dip where the access network > is being paid by both the customer and the supplier for the same delivery. > > As I said, this would be like paying for a product from $BOX_STORE and > having $BOX_STORE bill me for shipping, and pay $CARRIER for deliver only > to have $CARRIER show up at my door asking for even more money before they > will fork over my package. > > > 3. Somebody has to pay for what's in the middle (ports into transit > networks, bandwidth across them). Those are additional costs, that > wouldn't exist if everyone were connected to the same network. > > I don't think that's really part of the argument here. > > > 4. Both parties can make reasonable claims about why the other guys > should pay. > > Not really, IMHO. (See above and below) > > > 5. $LARGE_ACCESS_NETWORKs are big enough to say "Netflix pays" - with > Netflix making a visible stink about it. > > LARGE_ACCESS_NETWORK may be able to force Netflix to pay, but that's not > the same as saying Netflix _SHOULD_ pay. It's more like recognizing that > market power and a large customer base can often force an economic decision > that is contrary to what _SHOULD_ happen by any other rational evaluation. > > > 6. Netflix is important enough to end users, that Netflix can tell the > little guys "you pay." And yes, they're making it a little easier by > providing the CDN boxes. > > Perhaps, but that's not really what is happening here if you look at it in > more detail. I don't deny that Netflix _COULD_ do this, just as > $LARGE_ACCESS_NETWORKs _HAVE_ apparently done this to Netflix. However, so > far, Netflix seems to be trying as hard as they can to provide > cost-effective alternatives for ISPs to accept their bits in a variety of > ways and allowing the ISP to choose which solution works best for them. > > True, Netflix hasn't built out every single distant corner of the universe > with their peering network, but I would say that by any reasonable view of > the situation, they have aggressively built quite a network over a large > fraction of their service geography and to their credit, they are > continuing to aggressively expand that network. > > To the best of my knowledge (and I'm sure Dave will correct me if I am > wrong), Netflix would prefer to deliver bits settlement free directly to as > many ACCESS_PROVIDERS as possible, because it saves Netflix from paying > transit costs and it saves ACCESS_PROVIDERS from paying additional circuit > or transit costs and it provides a better customer experience all around. > > In cases where Netflix' network does not geographically overlap > $ACCESS_PROVIDER's network, then one or both will need to cover the cost of > bridging that distance, whether with an IP transit relationship, a circuit, > or some other mechanism. In most cases, since Netflix is in a high > percentage of the major peering centers, most $ACCESS_PROVIDERS already > have to build into one of those centers in order to reach many other > things, so it is reasonable for them to connect to Netflix at that same > point. In other cases, they use a transit provider to reach those centers > as well, and so likely they will use the same transit to reach Netflix. In > virtually every case, they're going to reach Netflix the same way they > reach the majority of other top sites on the internet. In such a case, it > makes sense that $ACCESS_PROVIDER pays for their unique geographic > situation. It doesn't make sense to expect Netflix to subsidize their > choice of geography. > > It seems to me that other than $LARGE_ACCESS_PROVIDERS' public statements > trying to extort money from $CONTENT_PROVIDERS and Brett's posts in this > conversation, the vast majority of people in this thread have > overwhelmingly agreed with this point of view. > > > 7. In the absence of some reasonably balanced formal policies and > regulations about settlements - we're going to keep seeing this kind of > stuff. > > Probably true, but I will point out that one of the main reasons that the > Internet has become such a cost-effective alternative even for voice > traffic vs. the PSTN is the lack of said formal policies and regulations > about settlements. Of course, you did say "reasonably balanced" which I > don't think is a term that could be rationally applied to the ITU > settlement rules for the PSTN. > > Owen > >