Some truth about Comcast - WikiLeaks style
George Bonser wrote: > What would any provider think if a city said "sure, you can have access > to our residents' eyeballs. It will cost you $5 per subscriber per month". > Would Comcast or anyone go for that? Dave Temkin wrote: > These are exactly what Franchise Agreements are for. Yes, cities charge > MSOs and LECs for access all the time. I've been lurking on this thread for awhile, but I feel a need to weigh in here. There are some critical distinctions between a city imposing conditions on access to its property and a telecommunications company imposing conditions on access to its network. There are also some important limitations to the cases in which cities can indeed impose any access restrictions, which prompt the question of why parallel policy limitations do not necessarily apply to last-mile companies. First, the justification for cities requiring things of companies in order to gain access to the local market are grounded in practical and policy considerations. On a very concrete level, putting wires in the ground requires permission from the city for rights-of-way (and such activities have genuine costs for the city). This permission comes in the form of the "Franchise Agreements" that Dave refers to. From a policy perspective, the city has an interest in ensuring that it gets the greatest value for its citizens out of the valuable last-mile concessions it grants to private parties. Historically, this meant that last-mile rights-of-way were a hook for enforcing customer service requirements, disciplining pricing, ensuring universal service, and supporting diversity of programming and "public access." Negotiating these terms with each municipality was the price that companies had to pay for monopoly access to local markets. What I think George's comment does not completely appreciate is that (ideally) cities are imposing such requirements at the behest of and for the benefit of the (local) public, whereas private constraints on local access are (by design) motivated by profit. Now, all of these requirements apply to providers of cable video content under the terms of the Cable Act of 1984 (which created a new Title in the Communications Act). None of them applied to LECs, which traditionally had a blanket permission to build out for their telecommunications services. The exception is for LECs that have started to offer video services. In that case, the same requirements kick in (for the video portion of those services). The exception to THAT is for states in which the LECs have successfully lobbied the state government to give them a blanket license to deploy video services statewide without negotiating locally (Michigan, for example, as opposed to Massachusetts). Whether or not you think such statewide agreements are a good thing tends to be a funciton of who you represent. In any event, the FCC has also further weakened localities' ability to impose requirements on even the video portion of these services (22 FCC Rcd. 5101 and 22 FCC Rcd. 19633). Importantly, for the NANOG crowd, none of these local controls applies to the broadband portion of such services. This all goes back to our artificially siloed Communications Act and some decisions made by the FCC almost a decade ago. The 2002 Cable Modem Order said that localities had no power to exercise authority over the broadband portion of such services. That means that they cannot demand payment for access to rights-of-way for broadband services, but it also means that they cannot impose public interest requirements on the provision of that service... for example that such service be provided universally to all citizens or that access to different types of content be provided on a non-discriminatory basis. The reasoning was that these services were not the video services envisioned in the Cable Act of 1984, but rather broadband services that the FCC was newly classifying as "deregulated." The 2002 Cable Modem Order was in fact the event that precipitated the 2005 "Brand X" Supreme Court decision that cemented the FCC's authority to reclassify last-mile broadband services not as common carriers but rather in a vaguely deregulated service. This helped lead to our modern debate about net neutrality. These jurisdictional turf wars are also at the heart of fights to allow cities to create municipally owned broadband networks that may then be leased on equal terms to all comers. It is also the reason that cities do not have the legal authority to compel "open access" or "non-discrimination" requirements on private networks within their boundaries. Broadband providers have understandably sought to gain near-exclusive control over their customers, and the legal framework helps them to avoid municipal networks and other requirements. Whether or not you believe that the local franchising regime that emerged in the 1980s makes sense for internet access today (not that it applies to broadband anyway), you must at le
Re: Alacarte Cable and Geeks
I have been trying to get NASA TV in Uruguay for a long time, obviously to no avail. Even though it's probably free / very cheap. I do believe that video over the Internet is about to change the cable business in a very deep and possibly traumatic way. Even I only have 4 megs DSL at home and have almost 250 msec delay to get to Terremark in Miami, my Apple TV plays YouTube reasonably well and I am probably near to the point where I would probably pay for premium content from YouTube or other providers to get over my crappy cable service. Cheers, Carlos On Fri, Dec 17, 2010 at 5:58 AM, Jeff Wheeler wrote: > On Fri, Dec 17, 2010 at 12:26 AM, Jay Ashworth wrote: >> the 80s when that practice got started -- having to account for each >> individual subscriber pushed the complexity up, in much the same way >> that flat rate telecom services are popular equally because customers >> prefer them, and because the *cost of keeping track* becomes >delta. > > Having personally and solely designed and written a toll billing > system from scratch that directly exchanged billing and settlement > data (and end-user data) with hundreds of ILECs, I can tell you a > number of things I learned: > 1) billing is only as hard as you (or your vendor) make it > 2) if your company can't figure out how to bill for a new product or > service, blame the billing people, not the product > 3) keeping up with taxes and fees consume a lot more resources than > calculating the net bills themselves; so adding products is really > trivial compared to dealing with every pissant local government that > decides to apply a different taxing method to your HBO (or your > telephone calls) > > This is not to say the folks that handle billing at cable companies > are equally capable, but if they had legitimate competitors, they > would figure out how to run many parts of their businesses more > efficiently. Imagine if Wal-Mart was the only game in town that had > bar code readers at the cash registers, and every other grocery chain > had to look up every item and punch in the price to check you out. > Other stores would quickly improve their technology or find themselves > out of business. > >> 2) New networks prefer it, and the fact that it happens makes the >> creation of new cable networks practical -- you don't have to go around >> and sell your idea to people retail; you sell it to CATV systems (well, > > My understanding is that networks/media giants like it because they > can force cable companies to carry 11 irrelevant channels to get the > Disney Channel that your kids want. Would enough people really ask > for G4TV to make producing and syndicating shows for that channel > cost-effective? I don't know the answer, but my suspicion is that > people who really just want CSN, E!, or the Golf Channel are > subsidizing G4 viewers. I wanted BBCA a few years ago, but my cable > provider required that I buy 30 other channels I did not want or had > never even heard of to get BBCA, so I didn't subscribe to it. > > I do not know if a la carte channel selection would be good for me, as > a consumer, or not. I do think the reasons the industry does not want > to offer that to end-users are disingenuous. > > -- > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > > -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Fwd: Your email message was blocked
I just contributed to the thread called "Cable and Geeks", and (I now realize) included the word "crappy". Then, just like that, my Friday Moment of Fun just happened, like a brilliant ball of light in the sky. I received a bounce from something called r...@bellaliant.ca who rejected my email due to "mild profanity" (sorry, i didn't know people could be so sensitive). Man, i had not had an on-the-job-laugh-out-loud in a long time. I am very tempted of probing the system. Many a question comes to mind, like for example: Does it only worry about profanity in English? I have a dictionary of "bad words" in Spanish, i am resisting the urge to craft a python script and send it word by word to r...@bellaliant.ca. Also mesmerizing is the fact that they will keep my mildly profane email in some storage for five days. Why? If its blocked, so be it, why keep it? Ahhh don't worry, I won't do it anyways. Notwithstanding the laugh and the fun, these are the times when I lose a bit of faith in mankind. Why there are always people out there pretending to know "what it's best for you" ? Well, I am clicking "send", I will probably receive another "mild profanity" warning. There it comes... cheers Carlos -- Forwarded message -- From: Date: Fri, Dec 17, 2010 at 10:55 AM Subject: Your email message was blocked To: carlosm3...@gmail.com The following email message was blocked by Bell Aliant Content Filtering Device: From: carlosm3...@gmail.com To:jeff.gallag...@bellaliant.ca Subject: Re: Alacarte Cable and Geeks Message: B4d0b5da70002.0001.0003.mml Because it may contain unacceptable language, or inappropriate material. Please remove any unacceptable or inappropriate language and resend the message. The blocked email will be automatically deleted after 5 days. Content Rule: Policy Management (Inbound) : Block Common & Mild Profanity r...@bellaliant.ca 6728 08:55:04.138 17 Dec 2010 - B4d0b5da70002.0001.0003.mml 6728 08:55:04.138 Message From , Return-path , Recipients (1) - 6728 08:55:04.138 Thread 2 Starting to unpack 6728 08:55:04.138 MimeTags::Process tag Content-Type = text/plain; charset=ISO-8859-1 6728 08:55:04.138 MimeTags::Process tag Content-Transfer-Encoding = quoted-printable 6728 08:55:04.138 Encoding 6728 08:55:04.138 Quoted-Printable encoded section consumed 3674 bytes - file D:\MailMarshal\Unpacking\T2\U2\Quoted-Printable.txt 6728 08:55:04.138 Type=MAIL, size=6512, Name=B4d0b5da70002.0001.0003.mml 6728 08:55:04.138 Type=MHDR, size=2836, Name=MsgHeader.txt 6728 08:55:04.138 Type=MBODY, size=3556, Name=Quoted-Printable.txt 6728 08:55:04.138 1 user(s) match ruleset - Connection Policies 6728 08:55:04.138 0 user(s) match rule - NSP-SEC Email Rule - BA 6728 08:55:04.138 0 user(s) match rule - Delete Postmaster messages - BA 6728 08:55:04.138 1 user(s) match ruleset - Virus & Threats (Inbound) 6728 08:55:04.138 1 user(s) match rule - Block Virus 6728 08:55:04.138 virus scanner OK file after 0 millisecs 6728 08:55:04.138 virus scanner OK file after 0 millisecs 6728 08:55:04.138 virus scanner OK file after 0 millisecs 6728 08:55:04.138 Name=U1\B4d0b5da70002.0001.0003.mml (MAIL,6512) False 6728 08:55:04.138 Name=U2\MsgHeader.txt (MHDR,2836) False 6728 08:55:04.138 Name=U2\Quoted-Printable.txt (MBODY,3556) False 6728 08:55:04.138 1 user(s) match rule - Block Known Threats 6728 08:55:04.138 Name=U1\B4d0b5da70002.0001.0003.mml (MAIL,6512) False 6728 08:55:04.138 1 user(s) match rule - Block Known Virus Attachments 6728 08:55:04.138 Name=U1\B4d0b5da70002.0001.0003.mml (MAIL,6512) False 6728 08:55:04.138 Name=U2\MsgHeader.txt (MHDR,2836) False 6728 08:55:04.138 Name=U2\Quoted-Printable.txt (MBODY,3556) False 6728 08:55:04.138 1 user(s) match rule - Block Virus - Zero Day Protection Framework 6728 08:55:04.138 Name=U1\B4d0b5da70002.0001.0003.mml (MAIL,6512) False 6728 08:55:04.138 1 user(s) match rule - Block Virus Hoaxes - BA 6728 08:55:04.138 Name=U1\B4d0b5da70002.0001.0003.mml (MAIL,6512) False 6728 08:55:04.138 Name=U2\MsgHeader.txt (MHDR,2836) False 6728 08:55:04.138 Name=U2\Quoted-Printable.txt (MBODY,3556) False 6728 08:55:04.138 0 user(s) match rule - Tony Power Rule #1 - BA 6728 08:55:04.138 1 user(s) match rule - BlockChain Letteres - BA 6728 08:55:04.154 Name=U1\B4d0b5da70002.0001.0003.mml (MAIL,6512) False 6728 08:55:04.154 Name=U2\MsgHeader.txt (MHDR,2836) False 6728 08:55:04.154 Name=U2\Quoted-Printable.txt (MBODY,3556) False 6728 08:55:04.154 0 user(s) match ruleset - Virus & Threats (Outbound) 6728 08:55:04.154 1 user(s) match ruleset - Spam - BA 6728 08:55:04.154 0 user(s) match rule - SkepticML - BA 6728 08:55:04.154 1 user(s) match rule - Invalid From - BA 6728 08:55:04.154 Name=U1\B4d0b5da70002.0001.0003.mml (MAIL,6512) False 6728
Re: Some truth about Comcast - WikiLeaks style
On Wed, Dec 15, 2010 at 07:14:01PM -0500, Jon Lewis wrote: > On Wed, 15 Dec 2010, Rich Kulawiec wrote: > >That's rich, given the enormous quantity of spam sourced from Comcast's > >network over the last decade. (And yes, it's ongoing: 162 unique sources > >in the last hour noted at one small observation point.) > > Spam is irrelevant. In this context, abuse = sending large amounts > of data to Comcast customers (at their request) without paying at > the Comcast toll booth. Yes, I know; I did read that in context and understand the point the original author was making. I probably should have made that clear. > >Now I realize that SMTP abuse isn't exactly the most bandwidth-chewing > >problem. However, it's a surface indicator of underlying security issues, > >which in this particular case can be summarized as "one heck of a lot > >of zombies". Given that those systems are known-hostile and under the > >control of adversaries, it's certain that they're doing all kinds of > >other things that chew up a lot more bandwidth than the spam does. > > It might even "improve" their ratios if they stopped those zombies > from sendig spam, participating in DDoS's, etc. After all, that's > outgoing traffic, and the less they send, the worse the ratio gets > for networks sending data to Comcast. True enough. But its continued presence, *seven years* after it was well-known to be a serious problem, tells us that Comcast either (a) can't or (b) won't run its network properly. So given this prima facie evidence of either (a) systemic, chronic incompetence or (b) systemic, chronic negligence, I think it's reasonable to wonder how many other aspects of their operation are just as horribly broken, and what the impact of that on their ability to carry steadily-increasing traffic might be. ---rsk
OSPF convergence - WAN links
Hi all, I have a network with a lot of FastEthernet WAN connections (some metro-ethernet), and using the OSPF as IGP. Today, the OSPF timers are the defaults (hello 10s, dead 40s, SPF initial timer 5s, etc). When a link comes down, the convergence time takes ~45s (ok, it's right). There are a lot of documents explaining about tuning OSPF convergence time, but on LAN environments. I didn't find any references about this OSPF tuning on WAN ethernet links (just serial, frame-relay, etc) and things related to it (such as packet loss, rtt, 'never lost of carrier', etc). I think that, if the timers are aggressive, any flap on the ISP network can cause a re-convergence... if the timers are high, the convergence time on down links is high too. What factors are you considering when tuning this OSPF timers on this type of link? What 'tecnologies' are you using (such as Fast Hellos, incremental SPF, etc) ? Thanks, Rafael
RE: OSPF convergence - WAN links
If your routers support Bidirectional Forwarding Detection (BFD), then I would suggest using that. It doesn't actually modify the hello timers or any other timers of any protocol; it merely acts as a supplementary protocol running under (or alongside, I guess) the main routing protocol, and its specialty is detecting failure along MAN circuits, virtual circuits, Ethernet VLANs, and other kinds of circuits in which you don't actually see a Link Down when the circuit is interrupted. http://en.wikipedia.org/wiki/Bidirectional_Forwarding_Detection http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/fs_bfd.html The nice thing about BFD is that it's optional on a per-interface and per-peer basis, so you don't have to tune the hellos aggressively for the other 10 peers who are on simple, local, or serial links just to get quicker failure detection for that one guy who's off on a virtual circuit. So in your case, on a Cisco for example, it might be as simple as interface Gig0/0/2 bfd interval 800 min_rx 50 multiplier 7 ip ospf bfd (You'd have to do this on both sides of the link.) Now when the OSPF neighbor is established, it will also try to establish a back-and-forth-packet BFD session to the same OSPF neighbor, and if it does successfully establish it, then it will keep sending packets every 800 milliseconds. Then if the BFD packets stop coming for 800ms*7=5.6 seconds, then BFD will inform OSPF that the neighbor is down, even if OSPF hasn't "naturally" discovered that yet. "show bfd neighbors" to see whether it's working. You can tune BFD very aggressively if you want... 50ms intervals and multiplier of maybe 5 or 3 I think, so you can make a failure occur in 250ms or less, if the application is that sensitive. In my experience it works great and does exactly what it's designed for. I use it for BGP peers within my AS and with some customers. -- Jeff Saxe Blue Ridge InternetWorks Charlottesville, VA From: Rafael Ganascim [rganas...@gmail.com] Sent: Friday, December 17, 2010 8:33 AM To: nanog@nanog.org Subject: OSPF convergence - WAN links Hi all, I have a network with a lot of FastEthernet WAN connections (some metro-ethernet), and using the OSPF as IGP. Today, the OSPF timers are the defaults (hello 10s, dead 40s, SPF initial timer 5s, etc). When a link comes down, the convergence time takes ~45s (ok, it's right). There are a lot of documents explaining about tuning OSPF convergence time, but on LAN environments. I didn't find any references about this OSPF tuning on WAN ethernet links (just serial, frame-relay, etc) and things related to it (such as packet loss, rtt, 'never lost of carrier', etc). I think that, if the timers are aggressive, any flap on the ISP network can cause a re-convergence... if the timers are high, the convergence time on down links is high too. What factors are you considering when tuning this OSPF timers on this type of link? What 'tecnologies' are you using (such as Fast Hellos, incremental SPF, etc) ? Thanks, Rafael
off topic "Help"
Hello, I have a misconfigured postfix installation, I inherited. Does anybody know of anyone who would consider reconfiguring/fixing it. It seems that all mail presented to it appears to be from "localhost", when i reject unautorized destinations, it rejects all mail. Thanks in advance. Bill Kruchas
Re: off topic "Help"
That's not postfix as such - you probably have a proxy of some sort (or a non transparent hardware NAT / port forwarder) in front The postfix faq should fix that for you. On Fri, Dec 17, 2010 at 7:16 PM, wrote: > Hello, > > I have a misconfigured postfix installation, I inherited. Does > anybody know of anyone who would consider reconfiguring/fixing it. > > It seems that all mail presented to it appears to be from > "localhost", when i reject unautorized destinations, it rejects all > mail. > > Thanks in advance. > > Bill Kruchas > -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Alacarte Cable and Geeks
On 17/12/10 4:54 AM, Carlos Martinez-Cagnazzo wrote: I do believe that video over the Internet is about to change the cable business in a very deep and possibly traumatic way. +1 It's clear that this is a major driving factor in the Comcast/L3/Netflix peering/transit issue. Comcast is obviously looking for ways to fill the looming hole in their revenue chart as consumers turn off Cable and get their TV/video entertainment delivered via the internet. jc
Re: Some truth about Comcast - WikiLeaks style
On 12/17/2010 2:51 AM, Steve Schultze wrote: Negotiating these terms with each municipality was the price that companies had to pay for monopoly access to local markets. I've seen it apply to CLEC access into a market as well; running as a true CLEC and not just borrowing LEC lines. Deals can include anything, including profit sharing, free service to the municipality, etc (and can be very bad if your negotiator is poor). Jack
Re: Fwd: Your email message was blocked
On 12/17/2010 7:11 AM, Carlos Martinez-Cagnazzo wrote: Notwithstanding the laugh and the fun, these are the times when I lose a bit of faith in mankind. Why there are always people out there pretending to know "what it's best for you" ? The keep for 5 days often means that they have a quarantine release for the recipient. It is also very possible that they have rule selection options on a recipient basis, which is not "what is best for you" but "you chose this". I'm not saying it is the case here, but there is a high probability, as their customers would scream otherwise. Exceptions are if it's corporate mail, but I'm not sure that is the corp mail server. Jack
"potential new and different architectural approach" to solve the Comcast - L3 dispute
Since it is Friday, maybe some of peering experts have some time to speculate what this new approach proposed by Comcast might be, as they assert it would represent "a significant shift of Internet infrastructure." http://www.lightreading.com/document.asp?doc_id=202121 http://blog.comcast.com/2010/12/comcast-continues-discussions-with-level-3offers-to-trial-new-solutions.html Well, their previous proposal was already representing quite a significant shift, and not in a good way, but I wonder what the new offer could be so that they figured it would be more acceptable to Level 3. I hope due to the speculative nature of the question it will not be considered off-topic. -Lorand Jakab
RE: Some truth about Comcast - WikiLeaks style
> What I think George's > comment > does not completely appreciate is that (ideally) cities are imposing > such requirements at the behest of and for the benefit of the (local) > public, whereas private constraints on local access are (by design) > motivated by profit. I wasn't really talking about franchise agreements as those are different and in many cases stipulate things like there can be no monopoly, etc. What I was talking about was what if a city simply decided to charge an Internet provider an "access fee" to the city's people. An "eyeball fee". The city says, "hey, you are making millions selling ads that these people view and the more eyeballs you have the more money you make, so we are going to charge you for those eyeballs". Which is basically what Comcast is doing ... charging content networks for access to eyeballs. What if they themselves got charged for the same thing. Would they think that is "fair"? And what if the city had its own community high speed internet that paid no such charge? > > Regards, > Steve Thanks, Steve.
Re: Some truth about Comcast - WikiLeaks style
George Bonser wrote: What I think George's comment does not completely appreciate is that (ideally) cities are imposing such requirements at the behest of and for the benefit of the (local) public, whereas private constraints on local access are (by design) motivated by profit. I wasn't really talking about franchise agreements as those are different and in many cases stipulate things like there can be no monopoly, etc. What I was talking about was what if a city simply decided to charge an Internet provider an "access fee" to the city's people. An "eyeball fee". The city says, "hey, you are making millions selling ads that these people view and the more eyeballs you have the more money you make, so we are going to charge you for those eyeballs". Which is basically what Comcast is doing ... charging content networks for access to eyeballs. What if they themselves got charged for the same thing. Would they think that is "fair"? And what if the city had its own community high speed internet that paid no such charge? They do already. It's called HBO, Showtime, HDNet Sports, etc. - they get charged per eyeball for those networks, and so they pass the charge on per eyeball to the customer. Nothing is new here.
RE: Some truth about Comcast - WikiLeaks style
> They do already. It's called HBO, Showtime, HDNet Sports, etc. - they > get charged per eyeball for those networks, and so they pass the charge > on per eyeball to the customer. > > Nothing is new here. The municipality charges the cable company per HBO subscriber?
Re: Some truth about Comcast - WikiLeaks style
On Dec 17, 2010, at 11:46 AM, Dave Temkin wrote: > George Bonser wrote: >>> What I think George's >>> comment >>> does not completely appreciate is that (ideally) cities are imposing >>> such requirements at the behest of and for the benefit of the (local) >>> public, whereas private constraints on local access are (by design) >>> motivated by profit. >>> >> >> I wasn't really talking about franchise agreements as those are >> different and in many cases stipulate things like there can be no >> monopoly, etc. >> >> What I was talking about was what if a city simply decided to charge an >> Internet provider an "access fee" to the city's people. An "eyeball >> fee". The city says, "hey, you are making millions selling ads that >> these people view and the more eyeballs you have the more money you >> make, so we are going to charge you for those eyeballs". Which is >> basically what Comcast is doing ... charging content networks for access >> to eyeballs. What if they themselves got charged for the same thing. >> Would they think that is "fair"? And what if the city had its own >> community high speed internet that paid no such charge? >> > > They do already. It's called HBO, Showtime, HDNet Sports, etc. - they get > charged per eyeball for those networks, and so they pass the charge on per > eyeball to the customer. > > Nothing is new here. Sure, the content providers charge Comcast per eyeball, but localities do not. Part of nearly every franchise agreement is a percentage of gross revenue from video services that is paid to the city. In recent years the FCC has capped this at 5% and subsequently introduced further constraints on what counts and how it is collected. Cities typically use these funds to support public resources related to video (public, educational, and governmental video channels, equipment, and networks). However, I think they have the freedom to use it to fill potholes if they so choose. None of this implicates the revenues from broadband service, because the 2002 Cable Modem Order removed those from the purview of localities. What about bundled "triple-play" style services? This is a mess, and I believe someone has to arbitrate what the percentages are. What about people playing video over their internet connection? Not included. As you can see, if the regulatory dichotomy between video and broadband services ever made sense, it clearly doesn't today. George's concern about a last-mile provider competing with municipal broadband parallels the most common argument made against such efforts: Although private companies do not have to pay any local fees that municipal broadband does not have to pay, the companies argue that municipal efforts have the unfair advantage of being built on taxpayer support and existing outside of the competitive marketplace. Of course if the "competitive marketplace" is a natural near-monopoly, these arguments are less compelling.
Re: Some truth about Comcast - WikiLeaks style
George Bonser wrote: They do already. It's called HBO, Showtime, HDNet Sports, etc. - they get charged per eyeball for those networks, and so they pass the charge on per eyeball to the customer. Nothing is new here. The municipality charges the cable company per HBO subscriber? The municipality gets a cut of that in a profit sharing agreement. The point was, everyone gets their tax or toll along the way. -Dave
Level 3 petitions FCC for conditions on Comcast/NBCU merger
http://fjallfoss.fcc.gov/ecfs/comment/view?id=6016064625
Re: "potential new and different architectural approach" to solve the Comcast - L3 dispute
On Dec 17, 2010, at 9:57 AM, Loránd Jakab wrote: > Since it is Friday, maybe some of peering experts have some time to > speculate what this new approach proposed by Comcast might be, as they > assert it would represent "a significant shift of Internet infrastructure." > > http://www.lightreading.com/document.asp?doc_id=202121 > http://blog.comcast.com/2010/12/comcast-continues-discussions-with-level-3offers-to-trial-new-solutions.html I have no direct knowledge of the situation, but my guess: I suspect the proposal was along the lines of longest-path / best-exit routing by Level(3). In other words, if L(3) carries the traffic (most of the way) to the customer, then Comcast has no complaint--the costs can be more fairly distributed. The "modest investment" is probably in tools to evaluate traffic and routing metrics, to make this work. This isn't really *new* to the peering community, but it isn't normal either. If anybody knows for sure, I'd be interested to hear. Cheers, -Benson
Re: "potential new and different architectural approach" to solve the
> On Dec 17, 2010, at 9:57 AM, Lor=E1nd Jakab wrote: > > Since it is Friday, maybe some of peering experts have some time to > > speculate what this new approach proposed by Comcast might be, as they > > assert it would represent "a significant shift of Internet = > infrastructure." > >=20 > > http://www.lightreading.com/document.asp?doc_id=3D202121 > > = > http://blog.comcast.com/2010/12/comcast-continues-discussions-with-level-3= > offers-to-trial-new-solutions.html > > I have no direct knowledge of the situation, but my guess: I suspect = > the proposal was along the lines of longest-path / best-exit routing by = > Level(3). In other words, if L(3) carries the traffic (most of the way) = > to the customer, then Comcast has no complaint--the costs can be more = > fairly distributed. The "modest investment" is probably in tools to = > evaluate traffic and routing metrics, to make this work. This isn't = > really *new* to the peering community, but it isn't normal either. > > If anybody knows for sure, I'd be interested to hear. How effective have variations on hot potato routing been, historically? I seem to recall Cogent made lots of noises early on about how they could do hot potato routing to encourage peering, but over the years that didn't seem to pan out that way. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: "potential new and different architectural approach" to solve the
On Dec 17, 2010, at 11:23 AM, Joe Greco wrote: > How effective have variations on hot potato routing been, historically? > I seem to recall Cogent made lots of noises early on about how they > could do hot potato routing to encourage peering, but over the years > that didn't seem to pan out that way. I can't comment on Cogent... But, in general: hot-potato reduces network costs but doesn't eliminate them--more capacity is still required to carry more traffic. The goal is to balance out the cost, assuming the traffic is of adequate value (or equal value, ideally) to both networks. Cheers, -Benson
Re: "potential new and different architectural approach" to solve the Comcast - L3 dispute
On Fri, Dec 17, 2010 at 12:15 PM, Benson Schliesser wrote: > I have no direct knowledge of the situation, but my guess: I suspect the > proposal was along the lines of longest-path / best-exit routing by Level(3). > In other words, if L(3) carries the traffic (most of the way) to the > customer, then Comcast has no complaint--the costs can be more fairly > distributed. The "modest investment" is probably in tools to evaluate > traffic and routing metrics, to make this work. This isn't really *new* to > the peering community, but it isn't normal either. That is a reasonable guess, but Level3's FCC filing yesterday spells out with certainty that Level3 did offer to "cold potato" traffic onto Comcast (it does not mention the technical means e.g. MED honoring, CDN smarts, or otherwise) and that Comcast refused. I agree that the proposed Comcast solution may not be truly "new" but instead unusual, but unless "Backdoor Santa" tells us what they really have in mind, I suppose we won't know. If I were Comcast, I would want to move the significant cost of detailed netflow collection and analysis infrastructure onto backbone providers by wrapping that accounting mechanism up into my settlement agreements with peers, as well as the expense of a cost-ineffective network, and demand that Level3 and Comcast really calculate how much each network spends on each bit, and share in that cost. In theory, this is what happens when an ILEC opens a rate case with its state regulator; and it is how settlements for POTS calls work (at a very basic level.) Actually, if I were Comcast, I would focus on running my business more efficiently, as Level3 has thrown down the gauntlet with the FCC and requested that the FCC dictate to Comcast specifically, and explicitly all other broadband access providers, how they will interconnect with peers and transit suppliers. Level3 must think that their business would be better off with regulatory oversight of peering, or they would not have taken this action. Comcast should realize that, of the three potential motives for their recent actions I have previously outlined, #1 and #3 are not just highly unlikely, but would be practically impossible in a regulated environment. As such, they should further realize that their peering committee is driven by motive #2, ego, and find the best way to change their position without losing too much credibility. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts
Re: "potential new and different architectural approach" to solve the Comcast - L3 dispute
On Fri, Dec 17, 2010 at 11:15:14AM -0600, Benson Schliesser wrote: > > I have no direct knowledge of the situation, but my guess: I suspect > the proposal was along the lines of longest-path / best-exit routing > by Level(3). In other words, if L(3) carries the traffic (most of the > way) to the customer, then Comcast has no complaint--the costs can be > more fairly distributed. The "modest investment" is probably in tools > to evaluate traffic and routing metrics, to make this work. This > isn't really *new* to the peering community, but it isn't normal > either. Nah, you're still thinking about this like it was a classic peering dispute over ratios, when nothing could be further from the truth. First off, by the very nature of a CDN, all of the Netflix/etc traffic is going to be delivered to the best exit on the long-haul network already. Second, Comcast is a FULL TRANSIT CUSTOMER of Level 3. Typically the customer gets to dictate the handoff point to the provider, by either advertising MEDs, or by sending inconsistent routes. The fact that the existing Level3/Comcast routing DOESN'T make Level 3 haul all of the bits to the best exit mean it's highly likely that Comcast agreeing to haul the bits was part of their commercial transit agreement, probably in exchange for lower transit prices. -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
RE: "potential new and different architectural approach" to solve theComcast - L3 dispute
> Level3 must think that their business > would be better off with regulatory oversight of peering, or they > would not have taken this action. Comcast should realize that, of the > three potential motives for their recent actions I have previously > outlined, #1 and #3 are not just highly unlikely, but would be > practically impossible in a regulated environment. As such, they > should further realize that their peering committee is driven by > motive #2, ego, and find the best way to change their position without > losing too much credibility. > > -- > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts Or maybe Level(3) thinks the entire game could potentially change and are attempting to head that off at the pass. What if instead of the end users paying for Internet service, the content providers did. Sort of like broadcast TV where the broadcasters pay the freight and the user simply turns on their device and they get content. In that model, the providers of the traffic pay the delivery costs of the content. So you would have "consumer" access that is mainly paid for by the content providers and "business" access which would be paid by the end users but would have less "consumer" traffic such as Netflix, Hulu, Facebook, Twitter, etc. If you look at the revenues being reported by some of these content providers, someone might be looking at those numbers saying "why *shouldn't* they pay? They are making money from the end users via ad sales just like broadcasters do, why shouldn't the model be the same?". I am not making any statement of my opinion, simply looking at a possibility. If there were such a sea change, Level3 now being a major content provider might find its long range plans have had a wrench thrown in them.
Re: "potential new and different architectural approach" to solve the Comcast - L3 dispute
On Dec 17, 2010, at 11:35 AM, Jeff Wheeler wrote: > ... Level3 must think that their business > would be better off with regulatory oversight of peering, or they > would not have taken this action. And they might be correct in thinking that, if we assume the peering ecosystem is changing i.e. such that traditional "backbones" are being bypassed. Regulatory oversight might have the effect of locking-in today's interconnect regime, which would be ideal for Level(3). Cheers, -Benson
Re: Alacarte Cable and Geeks
Original Message - > From: "JC Dill" > On 17/12/10 4:54 AM, Carlos Martinez-Cagnazzo wrote: > > I do believe that video over the Internet is about to change the > > cable business in a very deep and possibly traumatic way. > > +1 > > It's clear that this is a major driving factor in the Comcast/L3/Netflix > peering/transit issue. Comcast is obviously looking for ways to fill > the looming hole in their revenue chart as consumers turn off Cable > and get their TV/video entertainment delivered via the internet. The more I look at this, the more it looks like "pharmaceuticals bought from Canada are cheaper than ones purchased in America -- and they will be *just as long* as only a minority of Americans buy them there. As soon as *everyone* in America is buying their drugs cross-border, the prices will go right back up to what they were paying here." This is what's gonna happen with Comcast, too; if their customers drop CATV, then they're going to have to raise their prices -- and the cable networks themselves will have *no* way to collect revenue; the cable systems being their collection agent network. This Can't End Well. Cheers, -- jra
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 18 Dec, 2010 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 338766 Prefixes after maximum aggregation: 153020 Deaggregation factor: 2.21 Unique aggregates announced to Internet: 166625 Total ASes present in the Internet Routing Table: 35498 Prefixes per ASN: 9.54 Origin-only ASes present in the Internet Routing Table: 30573 Origin ASes announcing only one prefix: 14921 Transit ASes present in the Internet Routing Table:4925 Transit-only ASes present in the Internet Routing Table:119 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 31 Max AS path prepend of ASN (36992) 29 Prefixes from unregistered ASNs in the Routing Table: 325 Unregistered ASNs in the Routing Table: 127 Number of 32-bit ASNs allocated by the RIRs:960 Prefixes from 32-bit ASNs in the Routing Table: 4 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:191 Number of addresses announced to Internet: 2341188448 Equivalent to 139 /8s, 139 /16s and 179 /24s Percentage of available address space announced: 63.2 Percentage of allocated address space announced: 65.2 Percentage of available address space allocated: 96.8 Percentage of address space in use by end-sites: 86.7 Total number of prefixes smaller than registry allocations: 139416 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:83366 Total APNIC prefixes after maximum aggregation: 28387 APNIC Deaggregation factor:2.94 Prefixes being announced from the APNIC address blocks: 80309 Unique aggregates announced from the APNIC address blocks:34993 APNIC Region origin ASes present in the Internet Routing Table:4272 APNIC Prefixes per ASN: 18.80 APNIC Region origin ASes announcing only one prefix: 1204 APNIC Region transit ASes present in the Internet Routing Table:693 Average APNIC Region AS path length visible:4.4 Max APNIC Region AS path length visible: 20 Number of APNIC addresses announced to Internet: 575398688 Equivalent to 34 /8s, 75 /16s and 227 /24s Percentage of available APNIC address space announced: 77.9 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:136919 Total ARIN prefixes after maximum aggregation:6 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 108053 Unique aggregates announced from the ARIN address blocks: 43916 ARIN Region origin ASes present in the Internet Routing Table:14079 ARIN Prefixes per ASN: 7.67 ARIN Region origin ASes announcing only one prefix:5392 ARIN Region transit ASes present in the Internet Routing Table:1489 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible:
Re: Alacarte Cable and Geeks
On Fri, 17 Dec 2010, Jay Ashworth wrote: The more I look at this, the more it looks like "pharmaceuticals bought from Canada are cheaper than ones purchased in America -- and they will be *just as long* as only a minority of Americans buy them there. As soon as *everyone* in America is buying their drugs cross-border, the prices will go right back up to what they were paying here." This is what's gonna happen with Comcast, too; if their customers drop CATV, then they're going to have to raise their prices -- and the cable networks themselves will have *no* way to collect revenue; the cable systems being their collection agent network. This Can't End Well. Why not? As people shift from watching broadcast channels to streaming content and look to shut off their cable TV service, but keep internet, the cable co's are just going to have to raise internet prices to compensate. I can see a future where you buy internet from the cable co and they give you the basic cable TV channel lineup at "no charge" but in reality, you're paying for the cable internet what you used to pay for both cable internet and TV. The people I see this being a problem for are HBO/Showtime/Stars etc. unless they can hop on with the streaming providers or make that move themselves. -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: "potential new and different architectural approach" to solve theComcast - L3 dispute
On Friday, December 17, 2010 12:51:02 pm George Bonser wrote: > What if instead of the end users paying for Internet service, the content > providers did. I've been following these threads with some interest, and even replying in a couple of places, but now it hits me that a sea change has already occurred, and it's the whole content provider / end user *thing* versus the original 'a host is a host is a host' IP *thing*. But content providers already pay more for their 'service' than the typical asymmetric-towards-the-customer bandwidth user does.
Re: Alacarte Cable and Geeks
On Friday, December 17, 2010 01:27:44 pm Jon Lewis wrote: > On Fri, 17 Dec 2010, Jay Ashworth wrote: > > and the cable > > networks themselves will have *no* way to collect revenue; > The people I see this being a problem for are > HBO/Showtime/Stars etc. HBO, et al == the cable networks themselves.
RE: "potential new and different architectural approach" to solve theComcast - L3 dispute
On Fri, 17 Dec 2010, George Bonser wrote: What if instead of the end users paying for Internet service, the content providers did. Sort of like broadcast TV where the broadcasters Um. I'm a content provider. I pay a -lot- for internet service already. That's how my bits and bytes arrive in the tubes for those end users to recieve... -- david raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@icantclick.org http://www.expita.com/nomime.html
Re: Alacarte Cable and Geeks
Jay Ashworth wrote: individual subscriber pushed the complexity up, in much the same way that flat rate telecom services are popular equally because customers prefer them, and because the *cost of keeping track* becomes >delta. Can someone then please explain me why the hell in many other countries flatrate telecom service (I refer to flatrate local calls) does not exist or has been phased out. In the Netherlands they phased it out in the mid to late 80s. I am sure the then government owned telecom rats saw increased revenue coming real soon now due to increased modem usage. (still pissed at ridiculously and unnecessarily high phonebills...) It seems to me that at least in that case the cost of keeping track was far less than the increased revenue that metered (if that's the right word) local calls would provide. Regards, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
Re: "potential new and different architectural approach" to solve the Comcast - L3 dispute
On Fri, Dec 17, 2010 at 12:48 PM, Richard A Steenbergen wrote: > advertising MEDs, or by sending inconsistent routes. The fact that the > existing Level3/Comcast routing DOESN'T make Level 3 haul all of the > bits to the best exit mean it's highly likely that Comcast agreeing to > haul the bits was part of their commercial transit agreement, probably > in exchange for lower transit prices. It's worth asking why Comcast did not accept Level3's suggestion that they use MED as a face-saving maneuver, which would have allowed both sides to declare victory. A) Comcast may already have the contractual right to use MED but chooses not to. I agree with you that this is unlikely, not for pure reasons of economics, but because Comcast has some of the same set of motives not to send MED to their transit provider as every other network: prefix aggregation, quality control, and ego. I'll discount geography, marketing, and inability to calculate useful MED values. For argument's sake, let's say they currently can start sending MEDs to Level3 whenever they want. This being the case, Level3's "offer" would have amounted to Level3 telling Comcast upper management that Comcast's engineering people are leaving a huge amount of money on the table, that Level3 is far more cost-effective at running its long-haul network than Comcast, and that they should leave the big networking to the big boys. Comcast management could either react badly to this, or go back to their network folks and ask why they can't be as cost-effective as Level3. B) Comcast may not be able to use MED today. In this case, management may be asking themselves why. An essentially similar scenario can play out; they can either react badly to Level3, or ask their own staff why they are wasting money. C) Comcast doesn't care about MED or the actual cost of doing business. They are boldly moving towards a future that is opposite the one "net neutrality" folks advocate, one that looks like my "Comcast Motive #3." D) Comcast does not think that beginning to use MED (whether currently enabled or not) is enough to satisfy the federal regulators and legislators who are now taking interest in this game of interconnection brinkmanship, involving 17 million households, between a major IP carrier delivering traffic from everyone including a household name like Netflix, and a major cable company that is waiting for government approval to purchase NBC. They feel they must demand something very concrete to demonstrate that they are looking out for consumers' best interest, which means they must make Level3 and/or Netflix look like the bad guy. E) Comcast thinks that a system of accounting for the cost of bearing traffic and dividing it among the involved parties will actually be good for their business, because they can over-build their infrastructure as much as they like, perhaps even improving quality for end-users, and only have to pay for about half of it. The cost of being inefficient, stupid, or committing purchasing or forecasting errors drops by half. This looks very much like my "Comcast Motive #1." E1) Comcast may also know a thing or two about Hollywood Accounting. If you do not understand this reference, simply look it up on Wikipedia. It suffices to say that cost/revenue sharing agreements of this nature can be manipulated in gross ways to the advantage of the party doing the bulk of the book-keeping. F) Management has the same case of ego-driven decision-making that their technical staff have demonstrated. I find this unlikely but still possible. We all know this has been the case at the CEO level in some major interconnection disputes of the past. I believe this outlines the reasonable scenarios for Comcast avoiding a face-saving maneuver with Level3. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts
Re: "potential new and different architectural approach" to solve theComcast - L3 dispute
On Dec 17, 2010, at 1:59 PM, david raistrick wrote: > On Fri, 17 Dec 2010, George Bonser wrote: > >> What if instead of the end users paying for Internet service, the content >> providers did. Sort of like broadcast TV where the broadcasters > > Um. > > I'm a content provider. > > I pay a -lot- for internet service already. That's how my bits and bytes > arrive in the tubes for those end users to recieve... > > +1 from here. Regards Marshall Eubanks AmericaFree.TV > > -- > david raistrickhttp://www.netmeister.org/news/learn2quote.html > dr...@icantclick.org http://www.expita.com/nomime.html > > >
Comcast routes seen from the cheap seats
I apologize in advance if this information is uninteresting. Since there was talk about Comcast I thought I might share what I have been looking at for the last couple weeks with how I see Comcast route announcements from my network. On November 22nd (early morning US/Pacific time) we noticed a significant increase in traffic over our backup transit connection. Looking at the traffic, I found it was mostly to Comcast. The announced prefixes from Comcast on our backup were more specific (smaller prefix length) than those from our main link. So x.x/16 from our main link might be x.x/16 but also x.x.m/17 and x.x.z/17 from our backup. This probably isn't too strange. It's a pretty effective way to control inbound traffic. What I don't recall ever seeing is using different source AS numbers for the more specific prefixes. The routes kind of all end up looking like this for a given network: x.x/16 from source-as foo on main AS path ends with foo x.x/16 from source-as foo on backup AS path ends with foo x.x.m/17 from source-as bar on backup AS path ends with foo bar x.x.z/17 from source-as bar on backup AS path ends with foo bar foo is AS7922 in every case. bar is any one of at least 24 AS numbers assigned to Comcast, many of which are in sequential blocks (they don't look like customer reassignments to me, in other words) and combine to advertise all of Comcast in smaller prefixes (or so it seems). I didn't see any advertisements from the "bar" AS numbers on our main link (well VERY few, and they were redundant). That single point of data would be pretty easy to filter (by design?) which would leave you with the more equitable distribution comprised of something like the first two routes above. Maybe this isn't that weird; I don't usually look this closely at it. The built-in, single data point is handy... Well, single point per network; I tested a single filter rule with all 24 AS #'s I found. -- TimH
Re: Comcast routes seen from the cheap seats
This is part of normal cleaning up of more-specifics (lessening our routing table footprint). Apologies for any downstream effects. Please feel free to contact me if there’s a problem you’re seeing and need help with. Thanks, Tony (speaking on behalf of AS7922) On Fri, Dec 17, 2010 at 3:07 PM, Tim Howe wrote: > I apologize in advance if this information is uninteresting. Since > there was talk about Comcast I thought I might share what I have been > looking at for the last couple weeks with how I see Comcast route > announcements from my network. > > On November 22nd (early morning US/Pacific time) we noticed a > significant increase in traffic over our backup transit connection. > > Looking at the traffic, I found it was mostly to Comcast. The announced > prefixes from Comcast on our backup were more specific (smaller prefix > length) than those from our main link. So x.x/16 from our main link > might be x.x/16 but also x.x.m/17 and x.x.z/17 from our backup. > > This probably isn't too strange. It's a pretty effective way to > control inbound traffic. What I don't recall ever seeing is using > different source AS numbers for the more specific prefixes. > > The routes kind of all end up looking like this for a given network: > > x.x/16 from source-as foo on main AS path ends with foo > > x.x/16 from source-as foo on backup AS path ends with foo > > x.x.m/17 from source-as bar on backup AS path ends with foo bar > x.x.z/17 from source-as bar on backup AS path ends with foo bar > >foo is AS7922 in every case. bar is any one of at least 24 AS > numbers assigned to Comcast, many of which are in sequential blocks > (they don't look like customer reassignments to me, in other words) and > combine to advertise all of Comcast in smaller prefixes (or so it > seems). > >I didn't see any advertisements from the "bar" AS numbers on > our main link (well VERY few, and they were redundant). That single > point of data would be pretty easy to filter (by design?) which would > leave you with the more equitable distribution comprised of something > like the first two routes above. > >Maybe this isn't that weird; I don't usually look this closely > at it. The built-in, single data point is handy... Well, single point > per network; I tested a single filter rule with all 24 AS #'s I found. > > -- > TimH > >
Re: "potential new and different architectural approach" to solve the Comcast - L3 dispute
On Dec 17, 2010, at 12:35 PM, Jeff Wheeler wrote: > On Fri, Dec 17, 2010 at 12:15 PM, Benson Schliesser > wrote: >> I have no direct knowledge of the situation, but my guess: I suspect the >> proposal was along the lines of longest-path / best-exit routing by >> Level(3). In other words, if L(3) carries the traffic (most of the way) to >> the customer, then Comcast has no complaint--the costs can be more fairly >> distributed. The "modest investment" is probably in tools to evaluate >> traffic and routing metrics, to make this work. This isn't really *new* to >> the peering community, but it isn't normal either. > > That is a reasonable guess, but Level3's FCC filing yesterday spells > out with certainty that Level3 did offer to "cold potato" traffic onto > Comcast (it does not mention the technical means e.g. MED honoring, > CDN smarts, or otherwise) and that Comcast refused. > [...] Comcast's latest: http://fjallfoss.fcc.gov/ecfs/comment/view?id=6016064677
Bogons
With the holiday freezes approaching, it might be worth making sure that the recently allocated /8s are not in your bogon list 23/8 100/8 5/8 37/8 Just sayin'
BGP Update Report
BGP Update Report Interval: 09-Dec-10 -to- 16-Dec-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS17974 48255 2.9% 54.5 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 2 - AS845233167 2.0% 20.2 -- TE-AS TE-AS 3 - AS24863 30418 1.8% 30.0 -- LINKdotNET-AS 4 - AS453824132 1.4% 4.6 -- ERX-CERNET-BKB China Education and Research Network Center 5 - AS32528 22609 1.3%3768.2 -- ROSS-LABS - ROSS PRODUCTS DIVISION 6 - AS191615731 0.9% 253.7 -- Rede Nacional de Ensino e Pesquisa 7 - AS27064 13996 0.8% 37.8 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 8 - AS35931 13793 0.8%4597.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 9 - AS28573 11635 0.7% 16.4 -- NET Servicos de Comunicao S.A. 10 - AS178511074 0.7% 9.3 -- AS-PAETEC-NET - PaeTec Communications, Inc. 11 - AS982910826 0.6% 18.7 -- BSNL-NIB National Internet Backbone 12 - AS949810304 0.6% 29.2 -- BBIL-AP BHARTI Airtel Ltd. 13 - AS31148 10015 0.6% 30.3 -- FREENET-AS FreeNet ISP 14 - AS101139931 0.6% 115.5 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 15 - AS7552 9349 0.6% 16.1 -- VIETEL-AS-AP Vietel Corporation 16 - AS3816 9334 0.6% 23.3 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 17 - AS7011 8784 0.5% 7.5 -- FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. 18 - AS279478626 0.5% 36.6 -- Telconet S.A 19 - AS174888562 0.5% 7.7 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 20 - AS6316 8511 0.5% 95.6 -- AS-PAETEC-NET - PaeTec Communications, Inc. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS35931 13793 0.8%4597.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 2 - AS32528 22609 1.3%3768.2 -- ROSS-LABS - ROSS PRODUCTS DIVISION 3 - AS496002264 0.1%2264.0 -- 4 - AS281752644 0.2%1322.0 -- 5 - AS342391106 0.1%1106.0 -- INTERAMERICAN General Insurance Company 6 - AS15984 989 0.1% 989.0 -- The Joint-Stock Commercial Bank CentroCredit. 7 - AS19347 960 0.1% 960.0 -- INDYMACBANK - IndyMacBank 8 - AS435342333 0.1% 777.7 -- 9 - AS3 713 0.0% 134.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology 10 - AS17874 680 0.0% 680.0 -- NPC-AS-KR National Pension Corporation 11 - AS121906142 0.4% 511.8 -- OOCL-NET - OOCL (USA), Inc. 12 - AS190 3069 0.2% 511.5 -- NSYPTSMH-POE-AS - Navy Network Information Center (NNIC) 13 - AS44025 455 0.0% 455.0 -- 14 - AS46167 445 0.0% 445.0 -- LANDSERVICESUSA - Land Services USA, Inc 15 - AS37025 421 0.0% 421.0 -- BANKPHB 16 - AS210174125 0.2% 412.5 -- VSI-AS VSI AS 17 - AS319661513 0.1% 378.2 -- CSAA - CSAA 18 - AS13168 364 0.0% 364.0 -- 19 - AS39200 358 0.0% 358.0 -- 20 - AS495714124 0.2% 343.7 -- TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 130.36.35.0/2411300 0.6% AS32528 -- ROSS-LABS - ROSS PRODUCTS DIVISION 2 - 130.36.34.0/2411299 0.6% AS32528 -- ROSS-LABS - ROSS PRODUCTS DIVISION 3 - 202.182.78.0/239676 0.5% AS10113 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 4 - 202.92.235.0/248889 0.5% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 5 - 63.211.68.0/22 8670 0.5% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - 216.126.136.0/22 7975 0.4% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 7 - 190.65.228.0/226066 0.3% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 8 - 198.140.43.0/245092 0.3% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 9 - 189.1.173.0/24 4853 0.3% AS28666 -- HOSTLOCATION LTDA 10 - 208.54.82.0/24 4510 0.2% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 11 - 68.65.152.0/22 3507 0.2% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 12 - 206.184.16.0/243467 0.2% AS174 -- COGENT Cogent/PSI 13 - 189.85.51.0/24 2642 0.1% AS28175 -- 14 - 212.215.128.0/18 2550 0.1% AS25019 -- SAUDINETSTC-AS Autonomus System Number for SaudiNet AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 15 - 192.122.247.0/24 2474 0.1% AS2828 -- XO-AS15 - XO Communications 16 - 192.122.246.0/24 2470 0.1% AS2828 -- XO-AS15 - XO Communications 17 - 144.243.215.0/24 2274 0.1% AS22773
The Cidr Report
This report has been generated at Fri Dec 17 21:11:44 2010 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
10-12-10338660 208206
11-12-10338800 207920
12-12-10338619 207908
13-12-10338585 207984
14-12-10338814 207984
15-12-10338758 207506
16-12-10339240 208029
17-12-10339290 208204
AS Summary
36270 Number of ASes in routing system
15444 Number of ASes announcing only one prefix
3733 Largest number of prefixes announced by an AS
AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
105846528 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 17Dec10 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 339436 208249 13118738.6% All ASes
AS6389 3733 589 314484.2% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS4323 2629 673 195674.4% TWTC - tw telecom holdings,
inc.
AS19262 1835 418 141777.2% VZGNI-TRANSIT - Verizon Online
LLC
AS4766 1744 641 110363.2% KIXS-AS-KR Korea Telecom
AS6503 1187 290 89775.6% Axtel, S.A.B. de C.V.
AS28573 1221 327 89473.2% NET Servicos de Comunicao S.A.
AS10620 1319 452 86765.7% Telmex Colombia S.A.
AS4755 1406 554 85260.6% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS7545 1559 722 83753.7% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS18101 907 149 75883.6% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI
AS8151 1356 680 67649.9% Uninet S.A. de C.V.
AS8452 1105 430 67561.1% TE-AS TE-AS
AS24560 1042 380 66263.5% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS17488 954 301 65368.4% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS4808 951 325 62665.8% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS6478 1437 815 62243.3% ATT-INTERNET3 - AT&T Services,
Inc.
AS17676 642 67 57589.6% GIGAINFRA Softbank BB Corp.
AS855628 55 57391.2% CANET-ASN-4 - Bell Aliant
Regional Communications, Inc.
AS7303 833 264 56968.3% Telecom Argentina S.A.
AS11492 1271 713 55843.9% CABLEONE - CABLE ONE, INC.
AS22773 1257 703 55444.1% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS22047 565 31 53494.5% VTR BANDA ANCHA S.A.
AS7552 625 117 50881.3% VIETEL-AS-AP Vietel
Corporation
AS9443 571 75 49686.9% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS4804 571 77 49486.5% MPX-AS Microplex PTY LTD
AS14420 584 91 49384.4% CORPORACION NACIONAL DE
TELECOMUNICACIONES - CNT EP
AS7011 1174 683 49141.8% FRONTIER-AND-CITIZENS -
Frontier Communications of
America, Inc.
AS36992 658 190 46871.1% ETISALAT-MISR
AS1785 1791 1325 46626.0% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS7738 478 39 43991.8% Telecomunicacoes da Bahia S.A.
Total 36033121762385766.2% Top 30 total
OT: used / refurb voip phones?
A little off topic but anyone have any recommendations for vendors selling used voip handsets, especially Polycom? Looking for some IP335 or better. There are only a couple used gear resellers I trust and none seem to carry Polycom, only Cisco and even those only seem to have low end handsets. -shac
Re: Comcast routes seen from the cheap seats
On Fri, 17 Dec 2010 15:40:56 -0500 Tony Tauber wrote: > This is part of normal cleaning up of more-specifics (lessening our routing > table footprint). > > Apologies for any downstream effects. > > Please feel free to contact me if there’s a problem you’re seeing and need > help with. > > Thanks, > Tony > > (speaking on behalf of AS7922) Thanks for responding, Tony. I will do that. -- Tim Howe ti...@bendtel.com Data Processing541-389-8252 BendTelGPG pubkey id: 302D210B
Re: Bogons
Also the 105/8 which was recently allocated to AfriNIC. -manish On Dec 17, 2010, at 5:01 PM, nanog-requ...@nanog.org wrote: Message: 1 Date: Fri, 17 Dec 2010 16:06:45 -0500 From: John Payne Subject: Bogons To: NANOG list Message-ID: Content-Type: text/plain; charset=us-ascii With the holiday freezes approaching, it might be worth making sure that the recently allocated /8s are not in your bogon list 23/8 100/8 5/8 37/8 Just sayin'
Re: Bogons
On 17/12/2010 22:51, mkarir wrote: Also the 105/8 which was recently allocated to AfriNIC. all things considered, it's almost time to declare the bogons list dead. Unless there are active updates installed, any new filtering should take place on the basis of the smaller martians list. Nick
Google/Deja backup
This is entirely off topic, except that this is the audience who will know off hand. Now that 2TB costs $100, has anyone solicited Google for a copy of the Historical Usenet Archives that were assembled by they and Dejanews, such that this history lives in someplace... less commercial? Like the IA, perhaps? I'm pretty certain that entire archive fits on one drive now. I would set reply-to to me, but Zimbra is even less manageable than GGroups' interface. Cheers, -- jra
Re: "potential new and different architectural approach" to solve theComcast - L3 dispute
On 12/17/2010 12:45 PM, Lamar Owen wrote: But content providers already pay more for their 'service' than the typical asymmetric-towards-the-customer bandwidth user does. Agreed, though I think they pay less than most eyeball networks pay (the ISP, not the user), depending on where they host it (we have a lot of hauling we have to do). I'd also note, that the Internet is continuing to push more towards blurring the lines of content provider/eyeball, as p2p continues to be deployed with more technologies and for more uses. As households are constantly on, there is benefit in the household hosting content which can be reached directly by those you are sharing it to. As the market shifts to containing a larger market share of households with symmetric bandwidth, we can expect to see this improve (asymmetric last miles has hindered many innovations). Jack
Comcast vs Level 3 - This time with video
A simplified explanation of the situation between Level 3 and Comcast, from the perspective of a Comcast customer who is asking for the same thing Comcast is asking for. :) http://www.xtranormal.com/watch/8124137/ -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Comcast vs Level 3 - This time with video
On 12/17/2010 6:38 PM, Richard A Steenbergen wrote: A simplified explanation of the situation between Level 3 and Comcast, from the perspective of a Comcast customer who is asking for the same thing Comcast is asking for. :) http://www.xtranormal.com/watch/8124137/ lol, now that's the way to start a weekend off. :) Jack
Re: "potential new and different architectural approach" to solve the Comcast - L3 dispute
http://fcc.gov/ NOTICE: The FCC website and related electronic filing systems and documents (except for NORS) will be unavailable beginning 6:00 p.m. (EST) Friday, December 17 through 6:00 a.m. (EST) Monday, December 20 for scheduled maintenance. :( On Fri, Dec 17, 2010 at 3:42 PM, Steve Schultze wrote: > > > That is a reasonable guess, but Level3's FCC filing yesterday spells > > out with certainty that Level3 did offer to "cold potato" traffic onto > > Comcast (it does not mention the technical means e.g. MED honoring, > > CDN smarts, or otherwise) and that Comcast refused. > > [...] > > Comcast's latest: > http://fjallfoss.fcc.gov/ecfs/comment/view?id=6016064677 > -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org ---
Re: Alacarte Cable and Geeks
On 17/12/2010, at 1:17 PM, Jay Ashworth wrote: > Original Message - >> From: "JC Dill" > >> On 17/12/10 4:54 AM, Carlos Martinez-Cagnazzo wrote: >>> I do believe that video over the Internet is about to change the >>> cable business in a very deep and possibly traumatic way. >> >> +1 >> >> It's clear that this is a major driving factor in the Comcast/L3/Netflix >> peering/transit issue. Comcast is obviously looking for ways to fill >> the looming hole in their revenue chart as consumers turn off Cable >> and get their TV/video entertainment delivered via the internet. > > The more I look at this, the more it looks like "pharmaceuticals bought > from Canada are cheaper than ones purchased in America -- and they will be > *just as long* as only a minority of Americans buy them there. As soon as > *everyone* in America is buying their drugs cross-border, the prices will > go right back up to what they were paying here." > > This is what's gonna happen with Comcast, too; if their customers drop > CATV, then they're going to have to raise their prices -- and the cable > networks themselves will have *no* way to collect revenue; the cable > systems being their collection agent network. > > This Can't End Well. > > Cheers, > -- jra > > if the retail price of the content is inflated to support the distribution mechanism (e.g. cable, dsl, fios) and the provider doesn't own the content the result is inevitable. content owners could care less about how the content reaches eyeballs as long as it does so reliably. Comcast/NBC merger in the face of comcast/L3-Netflix fight gets interesting. jy
Re: "potential new and different architectural approach" to solve the Comcast - L3 dispute
http://blog.comcast.com/2010/12/comcasts-responds-to-level-3s-fcc-filing.html On Dec 17, 2010, at 10:25 PM, Joly MacFie wrote: > http://fcc.gov/ > > NOTICE: The FCC website and related electronic filing systems and documents > (except for NORS) will be unavailable beginning 6:00 p.m. (EST) Friday, > December 17 through 6:00 a.m. (EST) Monday, December 20 for scheduled > maintenance. > > > :( > > > On Fri, Dec 17, 2010 at 3:42 PM, Steve Schultze wrote: > > > That is a reasonable guess, but Level3's FCC filing yesterday spells > > out with certainty that Level3 did offer to "cold potato" traffic onto > > Comcast (it does not mention the technical means e.g. MED honoring, > > CDN smarts, or otherwise) and that Comcast refused. > > [...] > > Comcast's latest: > http://fjallfoss.fcc.gov/ecfs/comment/view?id=6016064677 > > > > -- > --- > Joly MacFie 218 565 9365 Skype:punkcast > WWWhatsup NYC - http://wwwhatsup.com > http://pinstand.com - http://punkcast.com > VP (Admin) - ISOC-NY - http://isoc-ny.org > ---
Re: "potential new and different architectural approach" to solve the Comcast - L3 dispute
On 12/18/2010 12:38 AM, Steve Schultze wrote: > http://blog.comcast.com/2010/12/comcasts-responds-to-level-3s-fcc-filing.html > I very much doubt whether my comment on the blog will survive their moderation process, so here it is: === I am a Comcast residential HSI customer, and have many clients who are business HSI Comcast customers. At the same time, I do maintain servers in my own racks at a datacenter. What is not mentioned in this letter, is that Comcast is already being paid - by me, and by every other customer, for access to the content. Note that Comcast has never said that the Level3/Netflix issue is about users exceeding their allotted bandwidth (currently at about 250GB/month for residential); presumably, were a Comcast user to use 249GB of bandwidth downloading cute pictures of cats, Comcast would have no objection. It appears to be the specific issue that Netflix is a possible competitor to Comcast's TV business, that somehow causes Comcast to decide that there is a problem. Understand this: every Netflix video to be streamed, is specifically requested by a Comcast user, operating under the Comcast-advertised "High Speed Internet" service and presumably within the bandwidth caps that Comcast's own contract allows. That Comcast presumes to have the right to limit, modify, or decide for me which pieces of the Internet I can have access to, removes Comcast's common carrier protections, calls into question the truth of your advertisements for the HSI service, and raises the issue of whether Comcast is dealing in bad faith with each and every Comcast HSI subscriber. --Patrick
Re: "potential new and different architectural approach" to solve the Comcast - L3 dispute
On Sat, Dec 18, 2010 at 01:07:15AM -0500, Patrick Giagnocavo wrote: > > Note that Comcast has never said that the Level3/Netflix issue is > about users exceeding their allotted bandwidth (currently at about > 250GB/month for residential); presumably, were a Comcast user to use > 249GB of bandwidth downloading cute pictures of cats, Comcast would > have no objection. I believe they want the cat people to pay too, it's just easier to go after Netflix first. Lets say for a moment that Comcast's overall ratio with its customers is approximately the same as their ratio in the leaked Tata graphs (yes I know that this proves nothing, but lets just assume it for a moment), i.e. 5:1. They then ask that every network who sends them traffic, even their transit providers (in the case of Level 3) be under 2:1. What is the point of insisting on a ratio that is not supported by the traffic their customers actually request? Because it gives them a convenient excuse to demand payment from nearly everyone on the Internet for being out of ratio, and to restrict capacity to those who do not pay. With so many transit ports running hot, and even peering ports running hot as in the recent example where they intentionally turned down Global Crossing capacity (which they claim is settlement free) and CAUSED congestion, the ISP who hosts the cute cat pictures may have little choice but to pay Comcast for access, or risk losing their cute cat hosting business to someone else who is willing to do so. I've also seen Comcast ignore several offers to honor MEDs or accept more-specifics from networks who DO meet their published peering requirements in every way except ratios, so I don't think they're interested in technical solutions a potential transport cost imbalance either. If it was about anything other than trying to extract a toll from content providers, one of these technical solutions would clearly have been better for them then continuing to force the traffic into their congested transit ports, which they not only pay for, but then also do the backhaul for across their own network. BTW, they rejected my very nice comment on their blog asking if they would be willing to share the graphs of their transit provider interfaces (which are NOT peering relationships, and not under NDA) to back up their claims that the published graphs are false, so I'm positive yours isn't going to get through. :) -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
