RE: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
True net-neutrality means no provider can have a better service than another. This statement is not true - or at least, I am not convinced of its truth. True net neutrality means no provider will artificially de-neutralize their service by introducing destination based priority on congested links. This totally screws with private peering and the variety of requirements, as well as special services (such as akamai nodes). Many of these cases aren't about saturation, but better connectivity between content provider and ISP. Adding money or QOS to the equation is just icing on the cake. From a false assumption follows false conclusions. Why do you feel it's true that net-neutrality treads on private (or even public) peering, or content delivery platforms? In my understanding, they are two separate topics: Net (non)-neutrality is literally about prioritizing different packets on the *same* wire based on whether the destination or source is from an ACL of IPs. IE this link is congested, Netflix sends me a check every month, send their packets before the ones from Hulu and Youtube. The act of sending traffic down a different link directly to a peers' network does not affect the neutrality of either party one iota - in fact, it works to solve the congested link problem (Look! Adding capacity fixed it!). The ethics of path distances, peering relationships and vector routing, while interesting, are out of scope in a discussion of neutrality. An argument which makes this a larger issue encompassing peering and vector routing is, in my opinion, either a straw man or a red herring (depending on how well it's presented) attempt to generate a second technoethical issue in order to defeat the first one. Nathan
Re: Did Internet Founders Actually Anticipate Paid, Prioritized
On Fri, 17 Sep 2010 09:13:48 CDT, Joe Greco said: Rather than allowing service providers to pick and choose who subscribers can communicate with, we're much more likely to see regulation intervene to enforce reasonable rules. We are indeed likely to see regulation intervene to enforce rules. Whether they're reasonable will likely depend on who wins the My lobbyist can beat up your lobbyist battle - and of course, the winning lobbyist will declare the rules reasonable, and the losing lobbyist will issue a press release stating how totally unreasonable the rules are. pgpfVbSTLHGpM.pgp Description: PGP signature
Re: Did Internet Founders Actually Anticipate Paid,
On 9/16/2010 2:28 PM, sth...@nethelp.no wrote: If you want control: Don't buy the cheapest commodity product. +1 -1 Next we'll be arguing that akamai nodes are evil because they can have better service levels than other sites. The p2p guys are also getting special treatment, as they can grab files faster than the direct download guy. Oh, and provider met google's bandwidth requirements for peering, so their peering with google gives better service to google than yahoo/hotmail; which was unfair to the provider who didn't meet the requirements and has to go the long way around. :P Provider may also have met ll's requirements, so peering accepted there, and here come the better netflix streams. Of course, anywhere a provider has a direct peer, they'll want to prioritize that traffic over any other. True net-neutrality means no provider can have a better service than another. This totally screws with private peering and the variety of requirements, as well as special services (such as akamai nodes). Many of these cases aren't about saturation, but better connectivity between content provider and ISP. Adding money or QOS to the equation is just icing on the cake. There are some excellent points in this, but I disagree as to the conclusions you seem to be drawing. One could look at peering as an opportunity to do some backdoor prioritization, and there's some legitimacy to that fear. My basic expectation as a customer is that you can provide me with some level of service. Since most service providers are unwilling to actually commit to a level of service, I might take the numbers attached to the service tier you sold me. So if I'm now downloading my latest FreeBSD via BitTorrent, my basic expectation is ultimately that I'll get fair treatment. What's fair treatment though? I think at the end of the day, it means that I've got to have reasonable access to the Internet. That means that if I can get packets in and out of your transit without fuss, that's probably good enough. If you've short-circuited things with peering that gives me faster access, that's great too. However, if your transit is 100% saturated for 20% of the day, every day, that's NOT good enough. ... 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: Did Internet Founders Actually Anticipate Paid,
On 9/17/2010 9:49 AM, Joe Greco wrote: So if I'm now downloading my latest FreeBSD via BitTorrent, my basic expectation is ultimately that I'll get fair treatment. And this is always a debate. You might say letting someone with voice or video have queue priority during saturation as being unfair, yet your p2p will work when it's running slower, where as their voice or video might fail and be completely unusable. If a provider has to deal with saturation, they have to make such decisions. Their goal, ideally would be to have a majority of the customers able to do what they need to do during saturation, allowing traffic to slow down that can afford to, and giving priority to traffic that to be usable must maintain certain QOS. What's fair treatment though? I think at the end of the day, it means that I've got to have reasonable access to the Internet. That means that if I can get packets in and out of your transit without fuss, that's probably good enough. If you've short-circuited things with peering that gives me faster access, that's great too. However, if your transit is 100% saturated for 20% of the day, every day, that's NOT good enough. I'm all for rules to limit saturation levels. This has nothing to do with neutrality, but to me it is the more important point. Consider telco world and voice communications. I could be wrong, but I seem to recall there be rules as to how long or often or what percentage of customers could experience issues with getting a line out. I'm also a strong believer in enforcing honest business practices. If you sell prioritization to one company, you should offer it to all others. The practice itself doesn't scale, so given an all or nothing, it is a business model that will burn out. The short-circuits and QOS applications are just methods of improving service for a majority of customers (those who use those destinations/services). This means, of course, p2p will usually be the loser. As an ISP, p2p means little to me. The QOS to the sites that hold a majority of my customers captive is the issue. Even without saturation, I have an obligation to see how I can improve video and voice quality in an erratic environment. This includes dealing with things such as microbursts and last mile saturation (which for me isn't shared, but customer's run multiple applications and the goal is to allow that with a smooth policy to assist in keeping one application from butchering the performance of another, ie, p2p killing their video streams from netflix/hulu/cbs/etc). Jack
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
In a message written on Thu, Sep 16, 2010 at 09:28:21PM +0200, sth...@nethelp.no wrote: If you want control: Don't buy the cheapest commodity product. Steinar Haug, Nethelp consulting, sth...@nethelp.no It may be hard for those in Europe to understand the situation in the US, so let me explain in real numbers. I live in an upper-middle class suburb of a tier 2 city, large enough it has everything but not a primary market for anyone. Due to a combination of geography, legacy, and government regulations (how licences are granted, specifically) I have two wireline providers, the local Cable Company which is Comcast, and the local Telephone Company, which is ATT (ex SBC territory, if it matters). There are no land-based wireless (WiFi, LTE, etc) providers in my area. I am not considering satellite viable for a number of reasons, but if you care there are two providers that cover the whole US, as far as I know. I'd link directly to the pages with prices, but due to the fact that the price and service varies with your ZIP code here I can't do that, you have to fill out a set of forms to even see what you can buy. Here are my choices: Comcast: Performance: 12 down, 2 up with Powerboost. Norton Security Suite 7 e-mails, each with 10GB. $42.95 per month. Performance PLUS: 16 down, 2 up with Powerboost. Norton Security Suite 7 e-mails, each with 10GB. $52.95 per month. Both include a single IP assigned via DHCP, you bring your own CPE or you can rent from them for a few dollars a month. ATT U-Verse: Pro: 3 down $41 Elite: 6 down $46 Max: 12 down $48 Max Plus: 18 down $58 Max Turbo: 24 down $68 Note that the only change with each product is speed. These all require the use of ATT CPE (and thus I added in the $3 they charge you for it), and come with the same features the ATT box presents you a private IP space network and does the NAT for you with a single outside IP. Same number of e-mail accounts (but I can't find the number listed anywhere). Also note they don't list upload speeds on the web site at all. NOTE: Both providers offer discounts for bundling with TV or Phone service, and both offer discounts for the first few months for new customers, I have left off all of these, comparing regular price to regular price for Internet only service. That's it, a total list of my consumer package choices. Comcast will offer business service, which is the exact same service over the exact same modems and network, except you can have static IP's and get priority support for about $25-30 extra. ATT won't sell me business service as I live in a residential neighborhood. Beyond that my choice is to order a T1, 1.5 symmetric from a real provider. I can get all the static IP's I want, a real SLA, priority support, and so on. I'll have to supply my own CPE, and it will run somewhere between $700 and $900 a month. I hope that helps folks outside the US understand the situation here. There really isn't a lot of choice, 2 providers, and some minor choice in how much speed you want to pay for with each one. I hear rumors of how good it is in Japan, or Korea, or Sweeden, I would love for folks from those places to post their options. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpzN5eRLHCo0.pgp Description: PGP signature
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
On Sep 17, 2010, at 6:48 02AM, Jack Bates wrote: On 9/17/2010 4:52 AM, Nathan Eisenberg wrote: True net-neutrality means no provider can have a better service than another. This statement is not true - or at least, I am not convinced of its truth. True net neutrality means no provider will artificially de-neutralize their service by introducing destination based priority on congested links. This is what you want it to mean. If I create a private peer to google, I have de-neutralized their service(destination based priority, even though in both cases, it's the source of the packets we care about) by allowing dedicated bandwidth and lower latency to their cloud. Practically, this is not the case. These days, most congestion tends to happen at the customer edge - the cable head-end or the DSL DSLAM, not the backbone or peering points. Also, Google, Yahoo, et al tend to base their peering decisions on technical, not business, standards, which makes sense because peering, above all other interconnect types, is mutually beneficial to both parties. More to the point, even the likes of Comcast won't shut down their peers to Yahoo because Google sends them a check. Also, let's not forget that the design of many p2p programs were specifically designed to ignore and bypass congestion controls... ie, screw other apps, I will take every bit of bandwidth I can get. This type of behavior causes p2p to have higher priority than other apps in a network that has no traffic prioritized. While I agree that traffic type prioritization would be preferred over destination based priorities, it often isn't feasible with hardware. Understanding the amount of traffic between your customers and a content provider helps you decide which content providers might be prioritized to give an overall service increase to your customer base. The fact that a content provider would even pay an ISP, is a high indicator that the content provider is sending a high load of traffic to the ISP, and bandwidth constraints are an issue with the service. Video and voice, in particular, should always try and have precedence over p2p, as they completely break and become unusable, where p2p will just be forced to move slower. From a false assumption follows false conclusions. Not really. It's not a neutral world. Private peering is by no means neutral. The provider that does enough traffic with google to warrant a private peering will have better service levels than the smaller guy who has to take the public paths. You view net neutrality as customers within an ISP, while I view it as a provider within a network of providers. It may not be neutral, but it's hardly discrinatory in the ways that I've seen many of the Non-net-neutrality schemes play out, which seems to be all about *deliberately* - either proactively or via actively deciding to not upgrade capacity - creating congestion in order to create a financial incentive for content providers to have their traffic prioritized. And I do agree, a private peer is definitely one technical means by which this prioritization could happen, but that's not the practice today. The levels of service and pricing I can maintain as a rural ISP can't be compared to the metropolitan ISPs. A west coast ISP won't have the same level of service as an east coast ISP when dealing with geographical based content. We could take it to the international scale, where countries don't have equal service levels to content. Why do you feel it's true that net-neutrality treads on private (or even public) peering, or content delivery platforms? In my understanding, they are two separate topics: Net (non)-neutrality is literally about prioritizing different packets on the *same* wire based on whether the destination or source is from an ACL of IPs. IE this link is congested, Netflix sends me a check every month, send their packets before the ones from Hulu and Youtube. The act of sending traffic down a different link directly to a peers' network does not affect the neutrality of either party one iota - in fact, it works to solve the congested link problem (Look! Adding capacity fixed it!). So you are saying, it's perfectly okay to improve one service over another by adding bandwidth directly to that service, but it's unacceptable to prioritize it's traffic on congested links (which effectively adds more bandwidth for that service). It's the same thing, using two different methods. If we consider all bandwidth available between the customer and content (and consider latency as well, as it has an effect on the traffic, especially during congestion), a private peer dedicates bandwidth to content the same as prioritizing it's traffic. If anything, the private peer provides even more bandwidth. ISP has 2xDS3 available for bandwidth total. Netflix traffic is 20mb/s. Bandwidth is considered
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
So you are saying, it's perfectly okay to improve one service over another by adding bandwidth directly to that service, but it's unacceptable to prioritize it's traffic on congested links (which effectively adds more bandwidth for that service). It's the same thing, using two different methods. On TCP/IP networks you cannot prioritize a service and you certainly cannot add bandwidth unless you have an underlying ATM or Frame Relay that has bandwidth in reserve. On a TCP/IP network, QOS features work by deprioritising traffic, either by delaying the traffic or by dropping packets. Many ISPs do deprioritise P2P traffic to prevent it from creating congestion, but that is not something that you can productize. At best you can use it as a feature to encourage customers to use your network. Are you suggesting that ISPs who receive protection money from one service provider, should then deprioritise all the other traffic on their network? ISP has 2xDS3 available for bandwidth total. Netflix traffic is 20mb/s. Bandwidth is considered saturated. Now you are talking about circuit capacities well below what ISPs typically use. In fact, two 45Mbps DS3 circuits are less than the 100Mbps Ethernet broadband service that many consumers now use. --Michael Dillon
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
On 9/17/2010 10:22 AM, Michael Dillon wrote: On a TCP/IP network, QOS features work by deprioritising traffic, either by delaying the traffic or by dropping packets. Many ISPs do deprioritise P2P traffic to prevent it from creating congestion, but that is not something that you can productize. At best you can use it as a feature to encourage customers to use your network. It's not just that. Many p2p apps don't play fair, and their nature causes them to exceed other applications in cases of congestion. You adjust priorities to give a better overall experience on average. Are you suggesting that ISPs who receive protection money from one service provider, should then deprioritise all the other traffic on their network? Is consumer grade bandwidth not deprioritised to business grade bandwidth? The provider is running a reverse business model, charging the content provider as well for better class of service. It doesn't scale, so it is heavily limited, but so long as the provider offers the same service to anyone (ie, anyone can play in this class of service), it seems to be a fair business practice. What should be illegal is the ability to hurt competitors of services offered by the provider (ie, provider offers voip, so they destroy traffic to other voip carriers). In fact, I think it was considered illegal years ago, though I admit that I didn't follow the case to it's conclusion. ISP has 2xDS3 available for bandwidth total. Netflix traffic is 20mb/s. Bandwidth is considered saturated. Now you are talking about circuit capacities well below what ISPs typically use. In fact, two 45Mbps DS3 circuits are less than the 100Mbps Ethernet broadband service that many consumers now use. 1) My logic scales, so I saw no reason to use larger numbers. 2) You must live in the City and are making a bad assumption on available capacities. 3) It's easier for those who don't have 100Mb, 1G, 10G, to grasp smaller numbers. Jack
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
On 9/17/2010 10:17 AM, Chris Woodfield wrote: Also, Google, Yahoo, et al tend to base their peering decisions on technical, not business, standards, which makes sense because peering, above all other interconnect types, is mutually beneficial to both parties. More to the point, even the likes of Comcast won't shut down their peers to Yahoo because Google sends them a check. I disagree. Minimum throughput for wasting a port on a router is a business reason, not technical. Peering is all about business and equal equity. Not to say that technical reasons don't play a part. Limitations of throughput requires some peering, but there is definitely a business model attached to it to determine the equity of the peers. And I do agree, a private peer is definitely one technical means by which this prioritization could happen, but that's not the practice today. Penny saved is a penny earned. Peering is generally cheaper than transit. In addition, it usually provides higher class of service. Money doesn't have to change hands for there to be value attached to the action. At the same time, when money does change hands, the paying party feels they are getting something of value. Is it unfair that I pay streaming sites to get more/earlier video feeds over the free users? I still have to deal with advertisements in some cases, which generates the primary revenue for the streaming site. Why shouldn't a content provider be able to pay for a higher class of service, so long as others are equally allowed to pay for it? Jack
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
On Sep 17, 2010, at 9:23 09AM, Jack Bates wrote: Is it unfair that I pay streaming sites to get more/earlier video feeds over the free users? I still have to deal with advertisements in some cases, which generates the primary revenue for the streaming site. Why shouldn't a content provider be able to pay for a higher class of service, so long as others are equally allowed to pay for it? No, it is definitely not, because *you* are the one paying for priority access for the content *you* feel is worth paying extra for faster access to. This is not the same thing as a content provider paying the carrier for priority access to your DSL line to the detriment of other sites you are interested it. How would you feel if you paid for priority access to hulu.com via this means, only to see your carrier de-prioritize that traffic because they're getting a check from Netflix? Jack
RE: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
How would you feel if you paid for priority access to hulu.com via this means, only to see your carrier de-prioritize that traffic because they're getting a check from Netflix? Isn't this where competition/may the best provider win comes into play? -Drew
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
Leo Bicknell bickn...@ufp.org wrote: There really isn't a lot of choice, 2 providers, and some minor choice in how much speed you want to pay for with each one. Does that mean no CLECs like Covad or DSL.net who colocate in the ATT CO, rent unbundled dry copper pairs and take it up from there themselves? Does that mean no ISPs who buy/rent last+middle mile transport from ATT ADSL network at Layer 2 (ATM) and provide their own IP layer? MS
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
On 9/17/2010 11:27 AM, Chris Woodfield wrote: How would you feel if you paid for priority access to hulu.com http://hulu.com via this means, only to see your carrier de-prioritize that traffic because they're getting a check from Netflix? The same as I'd feel if netflix paid them for pop transit which bypassed the congestion (even if it was via mpls-te or dedicated circuit instead of just priorities on a congested link). Netflix apparently felt that there was value in having a higher class of service and paid for it. Of course, I'd be against congested links in my ISP to begin with. I'd move and get a new ISP if I could. If I was stuck, then I'd be stuck. My distaste for my ISP having congested links wouldn't equate to distaste that a content provider paid to have better class of service due to the ISP having poor overall service. If said class of service completely wiped out the bandwidth and caused all normal traffic to be unusable, then the ISP most likely is in violation of their agreement with me (ie, not providing access, as it is unusable). This would be no different than selling off bandwidth to commercial grade customers to the point that consumer grade didn't work at all. Jack
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
On 9/17/2010 11:43 AM, Drew Weaver wrote: How would you feel if you paid for priority access to hulu.com via this means, only to seeyour carrier de-prioritize that traffic because they're getting a check from Netflix? Isn't this where competition/may the best provider win comes into play? That argument may not work, as there are many non-competitive jurisdictions. Of course, the non-compete areas aren't necessarily where a content provider would pay for such a service. Content provider must see value in the higher class service, which generally means they send a lot of traffic to where they are paying, which implies a lot of customers on the ISP side, which implies a high probability that we are talking metropolitan areas where there is more competition (or a massive NSP which will have a mix of rural and metro). Jack
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
In a message written on Fri, Sep 17, 2010 at 04:44:04PM +, Michael Sokolov wrote: Does that mean no CLECs like Covad or DSL.net who colocate in the ATT CO, rent unbundled dry copper pairs and take it up from there themselves? Does that mean no ISPs who buy/rent last+middle mile transport from ATT ADSL network at Layer 2 (ATM) and provide their own IP layer? In my area, from the research I have done, no. Part of the reason for this is U-Verse is FTTN, Fiber to the Node. ATT has run fiber to my neighborhood, I believe the node in my case is about 1000 feet away (I drive past it on the way out). The electronics sit there, so the old model of colocating in the CO and getting the dry pair is no longer possible, the copper stops at the node and it's a largeish (6' wide, 3' deep, 5' tall) cabinet, so there's no colo. The other model of the last mile being done by ATT and handed off over PPoE or ATM is still possible with this design, but to my knowledge there are no local CLEC's that do that here, and I do not know why. Just to be sure I just went to www.megapath.com (they bought DSL.net and Covad) and put in my address. I got back: Available Services for: address redacted Available broadband type(s): T1 , IDSL , DDSL , Cable , ADSL Duet Voice and Data service is available at this location My experience is when they can't give you prices online they don't actually offer any consumer services and are simply going to try and sell you a T1 for $750 a month. If enough people care I might call, or if there is a Megapath person on here who can contact me off list I can give them my address and they can tell me/us what is really possible. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpuODAL9mtU0.pgp Description: PGP signature
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
Leo Bicknell bickn...@ufp.org wrote: Part of the reason for this is U-Verse is FTTN, Fiber to the Node. ATT has run fiber to my neighborhood, I believe the node in my case is about 1000 feet away (I drive past it on the way out). The electronics sit there, so the old model of colocating in the CO and getting the dry pair is no longer possible, the copper stops at the node and it's a largeish (6' wide, 3' deep, 5' tall) cabinet, so there's no colo. We have that exact same stuff in my area too: I've actually talked to the ATT tech who was setting that cabinet up on one of our streets. The explanation he gave me was that even though they want everyone to go to this new-fangled fiber thing, they still have to maintain a small number of copper pairs running all the way to the real CO like it used to be. The reason is that if some kooky customer like me wants a service like ISDN that's only available from the real Class 5 switch and not from the U-Verse remote terminal, they are still required to provide that as a regulated telco. Ditto with CLECs like Covad-now-MegaPath: even though they don't get access to the FTTN infrastructure, no telco is evicting their legacy CO presence. Therefore, if a kooky customer like me wishes to forego fiber speeds and prefers the slower all-copper solution, I can still get SDSL from the CLEC, and the ILEC (ATT) will be required to provide a direct copper pair from that CLEC's cage inside the CO to the customer premise, no matter how much they wish for these copper pairs to die. Long live copper! MS
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
On Sep 17, 2010, at 2:52 AM, Nathan Eisenberg wrote: True net-neutrality means no provider can have a better service than another. This statement is not true - or at least, I am not convinced of its truth. True net neutrality means no provider will artificially de-neutralize their service by introducing destination based priority on congested links. This totally screws with private peering and the variety of requirements, as well as special services (such as akamai nodes). Many of these cases aren't about saturation, but better connectivity between content provider and ISP. Adding money or QOS to the equation is just icing on the cake. From a false assumption follows false conclusions. Why do you feel it's true that net-neutrality treads on private (or even public) peering, or content delivery platforms? In my understanding, they are two separate topics: Net (non)-neutrality is literally about prioritizing different packets on the *same* wire based on whether the destination or source is from an ACL of IPs. IE this link is congested, Netflix sends me a check every month, send their packets before the ones from Hulu and Youtube. The act of sending traffic down a different link directly to a peers' network does not affect the neutrality of either party one iota - in fact, it works to solve the congested link problem (Look! Adding capacity fixed it!). The ethics of path distances, peering relationships and vector routing, while interesting, are out of scope in a discussion of neutrality. An argument which makes this a larger issue encompassing peering and vector routing is, in my opinion, either a straw man or a red herring (depending on how well it's presented) attempt to generate a second technoethical issue in order to defeat the first one. Nathan A big part of the problem here is that net neutrality has been given a variety of definitions, some of which I agree with, some of which I don't... Here are my understanding of some of the definitions (along with my basic opinion of each): 1. All potential peers are treated equally. (As much as I'd like to see this happen, it isn't realistic to expect it will happen and any imaginable attempt at legislating it will do more harm than good). 2. Traffic is not artificially prioritized on congested links due to subsidies from the source or destination. Note: This does not include prioritization requested by the link customer. (I think that it is important to have this for the internet to continue as a tool for the democratization of communication. I think that this will require legislative protection). 3. Net neutrality requires an open peering policy. (Personally, I am a fan of open peering policies. However, a network should have the freedom of choice to implement whatever peering policy they wish.) I'm sure there are more definitions floating around. People are welcome to comment on them. These are the ones I have seen take hold amongst various community stakeholders. Owen
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.apnic.net. If you have any comments please contact Philip Smith p...@cisco.com. Routing Table Report 04:00 +10GMT Sat 18 Sep, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 331135 Prefixes after maximum aggregation: 152252 Deaggregation factor: 2.17 Unique aggregates announced to Internet: 162663 Total ASes present in the Internet Routing Table: 34823 Prefixes per ASN: 9.51 Origin-only ASes present in the Internet Routing Table: 30197 Origin ASes announcing only one prefix: 14661 Transit ASes present in the Internet Routing Table:4626 Transit-only ASes present in the Internet Routing Table:101 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (41664) 21 Prefixes from unregistered ASNs in the Routing Table: 2711 Unregistered ASNs in the Routing Table:1247 Number of 32-bit ASNs allocated by the RIRs:777 Prefixes from 32-bit ASNs in the Routing Table:1013 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:195 Number of addresses announced to Internet: 2269815744 Equivalent to 135 /8s, 74 /16s and 163 /24s Percentage of available address space announced: 61.2 Percentage of allocated address space announced: 65.4 Percentage of available address space allocated: 93.7 Percentage of address space in use by end-sites: 84.8 Total number of prefixes smaller than registry allocations: 156540 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:80501 Total APNIC prefixes after maximum aggregation: 27663 APNIC Deaggregation factor:2.91 Prefixes being announced from the APNIC address blocks: 77482 Unique aggregates announced from the APNIC address blocks:34148 APNIC Region origin ASes present in the Internet Routing Table:4193 APNIC Prefixes per ASN: 18.48 APNIC Region origin ASes announcing only one prefix: 1170 APNIC Region transit ASes present in the Internet Routing Table:649 Average APNIC Region AS path length visible:3.7 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 548634656 Equivalent to 32 /8s, 179 /16s and 128 /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, 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:135830 Total ARIN prefixes after maximum aggregation:70008 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 108483 Unique aggregates announced from the ARIN address blocks: 42882 ARIN Region origin ASes present in the Internet Routing Table:13915 ARIN Prefixes per ASN: 7.80 ARIN Region origin ASes announcing only one prefix:5331 ARIN Region transit ASes present in the Internet Routing Table:1382 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22
Netflow Tool
Anyone out there using a good netflow collector that has the capability data to export to CSV? Open Source would be best, but any suggestions are welcome. Thanks, =+=+=+=+=+=+=+=+=+=+=+=+= Michael Gatti cell.703.347.4412 ekim.it...@gmail.com =+=+=+=+=+=+=+=+=+=+=+=+=
Re: Netflow Tool
argus, www.qosient.com/argus On Fri, 2010-09-17 at 14:49 -0400, Mike Gatti wrote: Anyone out there using a good netflow collector that has the capability data to export to CSV? Open Source would be best, but any suggestions are welcome. Thanks, =+=+=+=+=+=+=+=+=+=+=+=+= Michael Gatti cell.703.347.4412 ekim.it...@gmail.com =+=+=+=+=+=+=+=+=+=+=+=+=
RE: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
It's a matter of viewpoint. It's convenient to talk about net-neutrality when it's scoped, but not when we widen the scope. Customer A gets better service than Customer B because he want to a site that had prioritization. Never mind that while they fight over the saturated link, Customer C beat both of them because he was on a separate segment that wasn't saturated. All 3 paid the same amount of money. C A B, yet C doesn't fall into this net-neutrality discussion, and the provider, who wants to keep customers, has more C customers than A, and more A customers than B, so B is the most expendable. It's convenient to talk about NN when we're talking about NN, and not about the ethical implications of peering with Comcast but not with ATT. There are things that NN is, and there are things that it isn't. There are a good deal of ethical and emotional issues involved, and while they're interesting to opine about, they're difficult to successfully argue. However, from a purely technical perspective, your above example illustrates my point. Customer A and B both lose. Why? Because prioritization and destination based discrimination are not real solutions. Capacity is. Customer A and B have saturation and discrimination. Customer C has capacity. Want to keep A and B (and your reputation)? Add capacity. My viewpoint is that of an ISP, and as such, I think of net-neutrality at a level above some last mile that's saturated at some other ISP. I have the same point of view but it appears that we disagree anyways. It must be the case that the perspective does not define the opinion. Appreciated the thinly veiled appeal to authority, though. Capacity is cheap. Discriminatory traffic management for-profit is a fantastically expensive way of killing off your customer base in exchange for short-term revenue opportunities. You MUST construct additional pylons, or the guy that does WILL take your customers. Nathan
Re: Netflow Tool
On Fri, Sep 17, 2010 at 3:49 PM, Mike Gatti ekim.it...@gmail.com wrote: Anyone out there using a good netflow collector that has the capability data to export to CSV? Open Source would be best, but any suggestions are welcome. nfdump with custom output. Custom output format: -o fmt:.. This is the most flexibel format, as you can specify yourself how the output looks like. The output format is defined using element tags as well as plain ascii text. http://nfdump.sourceforge.net/ Everton
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
On Sep 17, 2010, at 6:48 AM, Jack Bates wrote: On 9/17/2010 4:52 AM, Nathan Eisenberg wrote: True net-neutrality means no provider can have a better service than another. This statement is not true - or at least, I am not convinced of its truth. True net neutrality means no provider will artificially de-neutralize their service by introducing destination based priority on congested links. This is what you want it to mean. If I create a private peer to google, I have de-neutralized their service(destination based priority, even though in both cases, it's the source of the packets we care about) by allowing dedicated bandwidth and lower latency to their cloud. No, you have not de-neutralized their service. You have improved access asymmetrically. You haven't de-neutralized their service until you REFUSE to create a private peer with Yahoo on the same terms as Google, even assuming we stick to your rather byzantine definition of neutrality. There is a difference between neutrality and symmetry. Also, let's not forget that the design of many p2p programs were specifically designed to ignore and bypass congestion controls... ie, screw other apps, I will take every bit of bandwidth I can get. This type of behavior causes p2p to have higher priority than other apps in a network that has no traffic prioritized. Again, this is not part of the neutrality debate, it is a separate operational concern. Network neutrality is not about making sure every user gets a fair shake from every protocol. It's about making sure that source/destination pairs are not subject to divergent priorities on shared links. While I agree that traffic type prioritization would be preferred over destination based priorities, it often isn't feasible with hardware. Understanding the amount of traffic between your customers and a content provider helps you decide which content providers might be prioritized to give an overall service increase to your customer base. You're talking about different kinds of prioritization. Nobody is objecting to the idea of building out capacity and peering to places it makes sense. What people are objecting to is the idea that their upstream provider could take a bribe from a content provider in order to reduce the quality of service to their customers trying to reach other content providers. The fact that a content provider would even pay an ISP, is a high indicator that the content provider is sending a high load of traffic to the ISP, and bandwidth constraints are an issue with the service. Video and voice, in particular, should always try and have precedence over p2p, as they completely break and become unusable, where p2p will just be forced to move slower. Not necessarily. It might just mean that the traffic they are sending is sufficiently lucrative that it is worth subsidizing. It might mean that the content provider believes they can gain an (anti-)competitive advantage by reducing the quality of the user experience for subscribers that are going to their competitors. You keep coming back to this anti-p2p-centric rant, but, that's got almost nothing to do with the issue everyone else is attempting to discuss. From a false assumption follows false conclusions. Not really. It's not a neutral world. Private peering is by no means neutral. The provider that does enough traffic with google to warrant a private peering will have better service levels than the smaller guy who has to take the public paths. You view net neutrality as customers within an ISP, while I view it as a provider within a network of providers. Private peering is completely neutral IF it is available on identical terms and conditions to all players. It won't be symmetrical, but, it is neutral. Again, there is a difference between symmetry and neutrality. The world is not symmetrical. There is no reason it cannot or should not be neutral. In fact, there is good argument that being non-neutral is a violation of the Sherman anti-trust act. The levels of service and pricing I can maintain as a rural ISP can't be compared to the metropolitan ISPs. A west coast ISP won't have the same level of service as an east coast ISP when dealing with geographical based content. We could take it to the international scale, where countries don't have equal service levels to content. Again, you are talking about symmetry and mistaking that for neutrality. Neutrality is about whether or not everyone faces a consistent set of terms and conditions, not identical service or traffic levels. Neutrality is about letting the customer decide which content they want, not the ISP and expecting the ISP to be a fair broker in connecting customers to content. Why do you feel it's true that net-neutrality treads on private (or even public) peering, or content delivery platforms? In my understanding, they are two separate topics: Net (non)-neutrality
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
Jack Bates wrote: Is consumer grade bandwidth not deprioritised to business grade bandwidth? No. Today a provider doesn't move packets *within their network* faster or slower based on if the recipient is a consumer or business customer. Today, all providers move all packets as fast as they can be moved on the links each customer has contracted for service on. (If you know of an exception to this practice, today, I'd love to see cites.) The usual congestion point is the end-user customer's line, and the customer can only receive packets as fast as their line allows but all packets are allowed over the customer's line with equal priority. There may also be congestion on backbone ingress lines, but again all packets are allowed over each of those lines with equal priority. Rarely, there is congestion within the network - not by design but (usually) due to equipment failure. Even then, all traffic is (usually) allowed thru with equal priority. I don't know of any networks that intentionally design their networks with interior systems that prioritize traffic thru their network. It doesn't pay. In the long run it's cheaper and easier to simply upgrade capacity than to figure out some way to delay some packets while letting others thru. Prioritization necessarily involves moving some traffic slower (because you can't move traffic faster) than some link (within the provider's network) allows, to allow priority traffic to more fully utilize the link while the other (non-priority) traffic is slowed. It effectively creates congestion points within the provider's network, if none existed prior to implementing the prioritization scheme. I encourage all my competitors to do that. jc
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
On Sep 17, 2010, at 9:44 AM, Michael Sokolov wrote: Leo Bicknell bickn...@ufp.org wrote: There really isn't a lot of choice, 2 providers, and some minor choice in how much speed you want to pay for with each one. Does that mean no CLECs like Covad or DSL.net who colocate in the ATT CO, rent unbundled dry copper pairs and take it up from there themselves? Does that mean no ISPs who buy/rent last+middle mile transport from ATT ADSL network at Layer 2 (ATM) and provide their own IP layer? MS In many metros, yes. Owen
Re: Netflow Tool
Always liked Luca Deri's set of solutions: http://www.ntop.org/news.php (not necessarily for netflow, exclusiovely) ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius On Fri, Sep 17, 2010 at 1:49 PM, Mike Gatti ekim.it...@gmail.com wrote: Anyone out there using a good netflow collector that has the capability data to export to CSV? Open Source would be best, but any suggestions are welcome. Thanks, =+=+=+=+=+=+=+=+=+=+=+=+= Michael Gatti cell.703.347.4412 ekim.it...@gmail.com =+=+=+=+=+=+=+=+=+=+=+=+=
Re: Netflow Tool
On 17/09/2010, at 21.06, Everton Marques everton.marq...@gmail.com wrote: nfdump with custom output. Custom output format: -o fmt:.. This is the most flexibel format, as you can specify yourself how the output looks like. The output format is defined using element tags as well as plain ascii text. http://nfdump.sourceforge.net/ Everton And to complement that: - nfsen - netflow dashboard - pmGraph The first one relies on nfdump, and offers a nice drill down web based analysis tool with the nifty feature that it shows the nfdump commands to be run on the cli to obtain the data output used to represent the current interval Haven't tried the second one yet, but it uses postgresql to store samples. Might be easy to dump csv from that. Beware though of table growth. Pmgraph is developed by aptivate.org and I'm sure Chris Wilson will have something good to say about it :) Sorry for no URLs, using big fingers on small Iphone.
RE: Netflow Tool
If you want something scalable and commercial (read: with support) check out these guys, I have been using it for a while and it has tons of features and very flexible reporting (including exports to PDF, CSV, etc): http://www.netflowauditor.com/ They have a free version as well with limits. -Scott -Original Message- From: Mike Gatti [mailto:ekim.it...@gmail.com] Sent: Friday, September 17, 2010 2:50 PM To: nanog@nanog.org Subject: Netflow Tool Anyone out there using a good netflow collector that has the capability data to export to CSV? Open Source would be best, but any suggestions are welcome. Thanks, =+=+=+=+=+=+=+=+=+=+=+=+= Michael Gatti cell.703.347.4412 ekim.it...@gmail.com =+=+=+=+=+=+=+=+=+=+=+=+=
Re: Netflow Tool
If you want yours to come with rap videos look at scrutinizer (no I've not ever used it) http://www.youtube.com/watch?v=uUPkGvdXDIM http://www.youtube.com/watch?v=ilxknbKJ0Pc On Fri, Sep 17, 2010 at 12:45 PM, Scott Berkman sc...@sberkman.net wrote: If you want something scalable and commercial (read: with support) check out these guys, I have been using it for a while and it has tons of features and very flexible reporting (including exports to PDF, CSV, etc): http://www.netflowauditor.com/ They have a free version as well with limits. -Scott -Original Message- From: Mike Gatti [mailto:ekim.it...@gmail.com] Sent: Friday, September 17, 2010 2:50 PM To: nanog@nanog.org Subject: Netflow Tool Anyone out there using a good netflow collector that has the capability data to export to CSV? Open Source would be best, but any suggestions are welcome. Thanks, =+=+=+=+=+=+=+=+=+=+=+=+= Michael Gatti cell.703.347.4412 ekim.it...@gmail.com =+=+=+=+=+=+=+=+=+=+=+=+=
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
George Bonser wrote: I believe a network should be able to sell priotitization at the edge, but not in the core. I have no problem with Y!, for example, paying a network to be prioritized ahead of bit torrent on the segment to the end Considering yahoo (as any other big freemailer) is (unwillingly for the most part) facilitating a lot of spam traffic this would mean a lot of spam traffic gets prioritised. I can see that as an undesirable and unfortunate side effect. Regards, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
On 9/17/2010 2:08 PM, Owen DeLong wrote: Again, you are talking about symmetry and mistaking that for neutrality. Neutrality is about whether or not everyone faces a consistent set of terms and conditions, not identical service or traffic levels. Charging content providers for higher class service is perfectly neutral by your definition. So long as you offered the same class of service to all content providers who wished to pay. Neutrality is about letting the customer decide which content they want, not the ISP and expecting the ISP to be a fair broker in connecting customers to content. Offering better options to content providers would be perfectly acceptable here, as well, so long as you offer it to all. The former is adding capacity to meet demand. The latter is not effectively adding bandwidth, it is reducing bandwidth for one to reward the other. Which is fine, so long as you offer that class of service to all. The way this would work in the real world (and what people are objecting to) is that the ISP would transition from 1) 90mb public with no prioritization to 2) 90mb public with N mb prioritized via destination where N is the number of mbps that the destination wanted to pay for. Except my fictional account follows real world saturation experience historically. What you are giving is considered ideal compared to breaking the 90mb up to allow separate throughput for the service, which I guarantee a provider would do for enough money; given restriction of total available bandwidth. More importantly, it's not the 90mb public circuits where this is the real concern. The real concern is on the shared customer infrastructure side closer to the end-user where it's, say, 45mbps to the DSLAM going form 45mbps public to 45mbps public with 20mbps prioritized for content-provider-A while users trying to use content-provider-B get a degraded experience compared to A if their neighbors are using A. (Hence my belief that this is already a Sherman Anti-Trust issue). I think that only qualifies if content-provider-B doesn't care to pay for such a service, but it is available to them. Neutrality means everyone faces the same odds and the same terms and conditions. It means that amongst the other customers sharing the same ISP infrastructure we are all treated fairly and consistently. All customers can access the premium and non-premium content the same. ISP based licensing by content providers seems like a bigger scam. Apparently not an ISP that I would subscribe to. Nope. You'd probably stick with a saturated bandwidth ISP and gripe about net-neutrality because your service is slightly more piss poor than your neighbors when your neighbor happens to go to a premium site and you don't. I'll stick with not having saturation on shared links. Jack
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
On 9/17/2010 2:18 PM, JC Dill wrote: Jack Bates wrote: Is consumer grade bandwidth not deprioritised to business grade bandwidth? Prioritization necessarily involves moving some traffic slower (because you can't move traffic faster) than some link (within the provider's network) allows, to allow priority traffic to more fully utilize the link while the other (non-priority) traffic is slowed. It effectively creates congestion points within the provider's network, if none existed prior to implementing the prioritization scheme. I encourage all my competitors to do that. And yet, I'm pretty sure there are providers that have different pipes for business than they do for consumer, and probably riding some of the same physical medium. This creates saturated and unsaturated pipes, which is just as bad or worse than using QOS. The reason I'm pretty sure about it, is business circuits generally are guaranteed, while consumer are not. Jack
Re: Netflow Tool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Gatti wrote: Anyone out there using a good netflow collector that has the capability data to export to CSV? Open Source would be best, but any suggestions are welcome. There are so many ways to do it. Once you capture the flow data and store it in raw files, it's just a matter of filtering and converting the data to whatever format you want. The flow-tools suite has everything you'd need if you wanted to write some scripts of your own. For example, flow-export takes a raw flow file as input and can output in various formats, including ASCII CSV. See `man flow-tools` for more information on flow-export and other useful flow tools. That said, I'm using a variation of this setup, from Robert S. Galloway: http://www.dynamicnetworks.us/netflow/ If you set it up as documented by Mr. Galloway, you'll end up with your netflow data (IIRC, just networks, octets, and packets) organized into various RRD files, depending on how you set up CUFlow.cf. For example, one RRD file per customer. By default, flowscan will delete the raw flow files after it parses them into RRDs. Optionally, you can retain your raw flow files by creating a saved directory in your flows path (see flowscan docs). For visualization, I import the RRD files into Cacti. For CSV output I wrote a perl script. It pulls data from the resulting RRD files, computes the 95th percentile(s), among other things, and e-mails the CSV(s) to the appropriate people at the appropriate times. Like I said, though, there are so many ways to do it. The way you need to do it will depend on what you're trying to get out of the netflow data. Regards, Michael Hertrick Neovera, Inc. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkyT05oACgkQcJVdtfpkLb85lQCfTBLcpfZMxqszfHNFUV7opFVj 1DQAoI0wGv9NgefnwDpTv5e2+BDoMQbV =Hzrs -END PGP SIGNATURE-
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
On Tue, Sep 14, 2010 at 6:51 PM, Steven Bellovin s...@cs.columbia.edu wrote: No, they bought ATT, which [...] But yes, SBC is the controlling piece of the new ATT. As for the two /8s -- not quite. Back in the 1980s, ATT got 12/8. We soon learned that we couldn't make good use of it, since multiple levels of subnetting didn't exist. We offered it back to Postel in exchange for 135/8 -- i.e., the equivalent in class B space -- but Postel said to keep 12/8 since no one else could use it, either. This was all long before addresses were tight. When ATT decided to go into the ISP business, circa 1995, 12/8 was still lying around, unused except for a security experiment I was running.* However, a good chunk of 135/8 went to Lucent (now Alcatel-Lucent) in 1996, though I don't know how much. Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
Sorry, fat-fingered something when I was trying to edit. On Fri, Sep 17, 2010 at 2:12 PM, Bill Stewart nonobvi...@gmail.com wrote: On Tue, Sep 14, 2010 at 6:51 PM, Steven Bellovin s...@cs.columbia.edu wrote: No, they bought ATT, which [...] But yes, SBC is the controlling piece of the new ATT. Most of the wide-area ISP network is the old ATT, while much of the consumer broadband grew out of the SBC DSL side. As for the two /8s -- not quite. Back in the 1980s, ATT got 12/8. We soon learned that we couldn't make good use of it, since multiple levels of subnetting didn't exist. We offered it back to Postel in exchange for 135/8 -- i.e., the equivalent in class B space -- but Postel said to keep 12/8 since no one else could use it, either. This was all long before addresses were tight. When ATT decided to go into the ISP business, circa 1995, 12/8 was still lying around, unused except for a security experiment I was running.* However, a good chunk of 135/8 went to Lucent (now Alcatel-Lucent) in 1996, though I don't know how much. The ATT bits kept some fraction of 135; I don't know how much without dredging through ARIN Whois, but at least 135.63/16 is on my desktop. If I remember correctly, which is unlikely at this point, 12/8 was the Murray Hill Cray's Hyperchannel network, which I'd heard didn't know how to do subnetting except on classful boundaries, so it could happily handle 16M hosts on its Class A, and in fact only had two or three. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
RE: Netflow Tool
We've ran Scrutizer and also Netflow Auditor (also a few others) ... they are ok for smaller traffic levels (depending of course on sampling rates). None of them held up though to our expectations and we ended up going with Arbor Peakflow and been extremely happy ever since. I'd definitely suggest a trial of anything you are considering - we ran out and bought package after package and it didn't work out for us ;) Paul -Original Message- From: Bryan Irvine [mailto:sparcta...@gmail.com] Sent: September-17-10 3:56 PM To: Scott Berkman Cc: nanog@nanog.org Subject: Re: Netflow Tool If you want yours to come with rap videos look at scrutinizer (no I've not ever used it) http://www.youtube.com/watch?v=uUPkGvdXDIM http://www.youtube.com/watch?v=ilxknbKJ0Pc On Fri, Sep 17, 2010 at 12:45 PM, Scott Berkman sc...@sberkman.net wrote: If you want something scalable and commercial (read: with support) check out these guys, I have been using it for a while and it has tons of features and very flexible reporting (including exports to PDF, CSV, etc): http://www.netflowauditor.com/ They have a free version as well with limits. -Scott -Original Message- From: Mike Gatti [mailto:ekim.it...@gmail.com] Sent: Friday, September 17, 2010 2:50 PM To: nanog@nanog.org Subject: Netflow Tool Anyone out there using a good netflow collector that has the capability data to export to CSV? Open Source would be best, but any suggestions are welcome. Thanks, =+=+=+=+=+=+=+=+=+=+=+=+= Michael Gatti cell.703.347.4412 ekim.it...@gmail.com =+=+=+=+=+=+=+=+=+=+=+=+=
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
On Sep 17, 2010, at 1:21 PM, Jack Bates wrote: On 9/17/2010 2:08 PM, Owen DeLong wrote: Again, you are talking about symmetry and mistaking that for neutrality. Neutrality is about whether or not everyone faces a consistent set of terms and conditions, not identical service or traffic levels. Charging content providers for higher class service is perfectly neutral by your definition. So long as you offered the same class of service to all content providers who wished to pay. Charging them for higher class service on the circuits which connect directly to them is neutral. Charging them to effect the profile of the circuits directly connected to your other customers is non-neutral. Neutrality is about letting the customer decide which content they want, not the ISP and expecting the ISP to be a fair broker in connecting customers to content. Offering better options to content providers would be perfectly acceptable here, as well, so long as you offer it to all. Again, nobody is opposing offering better connectivity to content providers. What they are opposing is selling content providers the right to screw your customers that choose to use said content providers competitors. The former is adding capacity to meet demand. The latter is not effectively adding bandwidth, it is reducing bandwidth for one to reward the other. Which is fine, so long as you offer that class of service to all. You can't offer that class of service to all, and, even if you do, no, it's no neutral when you do it that way. The way this would work in the real world (and what people are objecting to) is that the ISP would transition from 1) 90mb public with no prioritization to 2) 90mb public with N mb prioritized via destination where N is the number of mbps that the destination wanted to pay for. Except my fictional account follows real world saturation experience historically. What you are giving is considered ideal compared to breaking the 90mb up to allow separate throughput for the service, which I guarantee a provider would do for enough money; given restriction of total available bandwidth. Total available bandwidth isn't what ATT is pushing the FCC to allow them to carve up this way. ATT is pushing for the right to sell (or select) content providers prioritized bandwidth closer to the consumer tail-circuit. More importantly, it's not the 90mb public circuits where this is the real concern. The real concern is on the shared customer infrastructure side closer to the end-user where it's, say, 45mbps to the DSLAM going form 45mbps public to 45mbps public with 20mbps prioritized for content-provider-A while users trying to use content-provider-B get a degraded experience compared to A if their neighbors are using A. (Hence my belief that this is already a Sherman Anti-Trust issue). I think that only qualifies if content-provider-B doesn't care to pay for such a service, but it is available to them. What if the service simply isn't available to content-provider-B because content-provider-A is a relater party to said ISP or said ISP simply chooses not to offer it on a neutral basis? (Which is exactly what ATT has stated they want to do.) Neutrality means everyone faces the same odds and the same terms and conditions. It means that amongst the other customers sharing the same ISP infrastructure we are all treated fairly and consistently. All customers can access the premium and non-premium content the same. ISP based licensing by content providers seems like a bigger scam. I'm not sure what you mean by ISP based licensing by content providers. Apparently not an ISP that I would subscribe to. Nope. You'd probably stick with a saturated bandwidth ISP and gripe about net-neutrality because your service is slightly more piss poor than your neighbors when your neighbor happens to go to a premium site and you don't. I'll stick with not having saturation on shared links. Actually, no. I've got good unsaturated service from both of the ISPs providing circuits into my house and from the upstreams that I use their circuits to reach for my real routing. (I'm unusual... I use Comcast and DSL to provide layer 2 transport to colo facilities where I have routers. I then use the routers in the colo facilties to advertise my addresses into BGP and trade my real packets. As far as Comcast and my DSL provider are concerned, I'm just running a whole lot of protocol 43 traffic to a very small set of destinations.) I use the two providers in question because they are, generally, neutral in their approach and do not play funky QoS games with my traffic. Owen
BGP Update Report
BGP Update Report Interval: 09-Sep-10 -to- 16-Sep-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS34984 31696 1.3% 84.7 -- TELLCOM-AS Tellcom Iletisim Hizmetleri 2 - AS346423020 0.9% 511.6 -- ASC-NET - Alabama Supercomputer Network 3 - AS553622242 0.9% 200.4 -- Internet-Egypt 4 - AS32528 17289 0.7%2161.1 -- ABBOTT Abbot Labs 5 - AS815116120 0.6% 9.0 -- Uninet S.A. de C.V. 6 - AS638915537 0.6% 4.1 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 7 - AS35931 15308 0.6%2551.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 8 - AS432314972 0.6% 3.3 -- TWTC - tw telecom holdings, inc. 9 - AS886613592 0.5% 33.6 -- BTC-AS Bulgarian Telecommunication Company Plc. 10 - AS754512945 0.5% 9.3 -- TPG-INTERNET-AP TPG Internet Pty Ltd 11 - AS566812042 0.5% 10.6 -- AS-5668 - CenturyTel Internet Holdings, Inc. 12 - AS42910 11748 0.5% 107.8 -- SADECEHOSTING-COM Sadecehosting-Com 13 - AS982911678 0.5% 14.2 -- BSNL-NIB National Internet Backbone 14 - AS16718 11004 0.4% 393.0 -- EMBARQ-HMBL - Embarq Corporation 15 - AS381610912 0.4% 22.6 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 16 - AS17488 10679 0.4% 7.5 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 17 - AS24560 10496 0.4% 10.2 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 18 - AS17974 10315 0.4% 8.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 19 - AS845210159 0.4% 8.7 -- TE-AS TE-AS 20 - AS5800 9783 0.4% 46.1 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS35931 15308 0.6%2551.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 2 - AS32528 17289 0.7%2161.1 -- ABBOTT Abbot Labs 3 - AS372048943 0.4% 894.3 -- TELONE 4 - AS1959 4246 0.2% 849.2 -- DMSLABNET - DoD Network Information Center 5 - AS15984 830 0.0% 830.0 -- The Joint-Stock Commercial Bank CentroCredit. 6 - AS210176570 0.3% 657.0 -- VSI-AS VSI AS 7 - AS11384 653 0.0% 653.0 -- 8 - AS50150 653 0.0% 653.0 -- LONGLINE-AS LongLine SRL 9 - AS11613 584 0.0% 584.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 10 - AS170291125 0.0% 562.5 -- CHP-NET - California Highway Patrol 11 - AS27859 555 0.0% 555.0 -- Internet Systems Consortium 12 - AS181632158 0.1% 539.5 -- JINJU18163-AS-KR jinju national university 13 - AS346423020 0.9% 511.6 -- ASC-NET - Alabama Supercomputer Network 14 - AS6755 2037 0.1% 509.2 -- ASN - TURNET 15 - AS16861 480 0.0% 480.0 -- REVELEX - Revelex.com 16 - AS49879 472 0.0% 472.0 -- HOSTHANE ISIK Bilgisayar Internet ve Yayincilik Hizmetleri 17 - AS138807173 0.3% 421.9 -- ACI-AS - american century investments 18 - AS45600 394 0.0% 394.0 -- UPM-AS-AP University of the Philippines, Manila 19 - AS16718 11004 0.4% 393.0 -- EMBARQ-HMBL - Embarq Corporation 20 - AS51361 383 0.0% 383.0 -- ALARMNET-ASN Alarmnet Guvenlik Hizmetleri A.S TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 129.66.128.0/17 11412 0.4% AS3464 -- ASC-NET - Alabama Supercomputer Network 2 - 129.66.0.0/17 11402 0.4% AS3464 -- ASC-NET - Alabama Supercomputer Network 3 - 63.211.68.0/22 9483 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 4 - 130.36.34.0/24 8633 0.3% AS32528 -- ABBOTT Abbot Labs 5 - 130.36.35.0/24 8630 0.3% AS32528 -- ABBOTT Abbot Labs 6 - 195.39.181.0/248295 0.3% AS6755 -- ASN - TURNET AS9155 -- QNET QualityNet AS number 7 - 198.140.43.0/245774 0.2% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 8 - 190.65.228.0/225534 0.2% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 9 - 64.86.26.0/23 4479 0.2% AS37204 -- TELONE 10 - 95.32.192.0/18 3589 0.1% AS21017 -- VSI-AS VSI AS 11 - 216.126.136.0/22 3287 0.1% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 12 - 148.204.141.0/24 3280 0.1% AS8151 -- Uninet S.A. de C.V. 13 - 196.29.32.0/21 3150 0.1% AS37204 -- TELONE 14 - 206.184.16.0/243008 0.1% AS174 -- COGENT Cogent/PSI 15 - 95.32.128.0/18 2941 0.1% AS21017 -- VSI-AS VSI AS 16 - 216.118.245.0/24 2330 0.1% AS22150 -- CARRIERHOUSE - Carrierhouse Corp.
The Cidr Report
This report has been generated at Fri Sep 17 21:11:58 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-09-10335938 207551
11-09-10336408 207230
12-09-10336564 206952
13-09-10336191 208106
14-09-10336372 207484
15-09-10336810 207396
16-09-10336289 207762
17-09-10336284 207815
AS Summary
35426 Number of ASes in routing system
15084 Number of ASes announcing only one prefix
4460 Largest number of prefixes announced by an AS
AS4323 : TWTC - tw telecom holdings, inc.
97386240 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').
--- 17Sep10 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 336388 207735 12865338.2% All ASes
AS6389 3793 282 351192.6% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS4323 4460 1927 253356.8% TWTC - tw telecom holdings,
inc.
AS19262 1816 286 153084.3% VZGNI-TRANSIT - Verizon Online
LLC
AS4766 1860 515 134572.3% KIXS-AS-KR Korea Telecom
AS22773 1193 66 112794.5% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS17488 1346 285 106178.8% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS4755 1346 301 104577.6% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS5668 1131 89 104292.1% AS-5668 - CenturyTel Internet
Holdings, Inc.
AS18566 1087 63 102494.2% COVAD - Covad Communications
Co.
AS10620 1319 343 97674.0% Telmex Colombia S.A.
AS6478 1340 412 92869.3% ATT-INTERNET3 - ATT WorldNet
Services
AS13343 1510 610 90059.6% SCRR-13343 - Road Runner
HoldCo LLC
AS1785 1793 959 83446.5% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS8452 1154 434 72062.4% TE-AS TE-AS
AS8151 1381 670 71151.5% Uninet S.A. de C.V.
AS7545 1381 692 68949.9% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS7303 793 114 67985.6% Telecom Argentina S.A.
AS18101 879 242 63772.5% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS4808 931 303 62867.5% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS4804 677 73 60489.2% MPX-AS Microplex PTY LTD
AS7552 644 97 54784.9% VIETEL-AS-AP Vietel
Corporation
AS4780 700 166 53476.3% SEEDNET Digital United Inc.
AS17676 605 76 52987.4% GIGAINFRA Softbank BB Corp.
AS7018 1458 949 50934.9% ATT-INTERNET4 - ATT WorldNet
Services
AS28573 1095 591 50446.0% NET Servicos de Comunicao S.A.
AS9443 572 76 49686.7% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS14420 578 87 49184.9% CORPORACION NACIONAL DE
TELECOMUNICACIONES - CNT EP
AS7011 1153 664 48942.4% FRONTIER-AND-CITIZENS -
Frontier Communications of
America, Inc.
AS22047 559 80 47985.7% VTR BANDA ANCHA S.A.
AS24560 1029 553 47646.3% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
In a message written on Fri, Sep 17, 2010 at 04:44:04PM +, Michael Sokolov wrote: Does that mean no CLECs like Covad or DSL.net who colocate in the ATT CO, rent unbundled dry copper pairs and take it up from there themselves? I found someone off list with access to Megapath's Partner Portal where they can get the real scoop, and did that for my specific location. Short form: They can resell ATT's lower speed ADSL (but not their top speeds) at a markup. They can resell Comcast's cable modem service at a markup. They can offer IDSL (ISDN Speeds) or SDSL from the actual CO, which they claim is 19k feet away, my google maps says 23k feet away. The estimate is I could get 768k symmetric at that distance, which would mean 1/10th the bandwidth I have now at approximately 5 times the cost I have now. So I'm sure if you're a government bean counter or ATT lobbyest there is competition out of my CO, and I have options. As a consumer looking at the practical side of it I see no options, I have a Telco or Cable company, with basically the same offerings at the same speed at the same prices. YMMV, likely a lot with where you live. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpTgEva3J0eS.pgp Description: PGP signature
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
I have the same problem getting decent fiber out here. They keep wanting to do a loop clear back to the other side of the state. I will jsut keep building out my towers to towns where I know I can co-lo or get QMOE at least. On Fri, Sep 17, 2010 at 4:24 PM, Leo Bicknell bickn...@ufp.org wrote: In a message written on Fri, Sep 17, 2010 at 04:44:04PM +, Michael Sokolov wrote: Does that mean no CLECs like Covad or DSL.net who colocate in the ATT CO, rent unbundled dry copper pairs and take it up from there themselves? I found someone off list with access to Megapath's Partner Portal where they can get the real scoop, and did that for my specific location. Short form: They can resell ATT's lower speed ADSL (but not their top speeds) at a markup. They can resell Comcast's cable modem service at a markup. They can offer IDSL (ISDN Speeds) or SDSL from the actual CO, which they claim is 19k feet away, my google maps says 23k feet away. The estimate is I could get 768k symmetric at that distance, which would mean 1/10th the bandwidth I have now at approximately 5 times the cost I have now. So I'm sure if you're a government bean counter or ATT lobbyest there is competition out of my CO, and I have options. As a consumer looking at the practical side of it I see no options, I have a Telco or Cable company, with basically the same offerings at the same speed at the same prices. YMMV, likely a lot with where you live. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Troubleshooting TCP performance tutorial
Greetings, This past week I have been trying to find the root cause of tcp performance problems of a few clients that are using a third party metro Ethernet for transport. RFC2544 tests (Layer 2) and iperf using UDP give good symmetric performance almost 100% the speed of the circuit. However all kind of TCP tests result in some kind of asymmetrical deficiency, either the upstream or downstream of the client is hugely different. The latency is not a huge factor since all the metro Ethernet connections have less than 2 ms. So the question basically if is there a good tutorial or white paper for troubleshooting tcp with emphasis of using tools like Wireshark to debug and track this kind of problems. Regards, Abel.
Re: Troubleshooting TCP performance tutorial
In a situation like yours I found Internet Core Protocols: The Definitive Guide by Eric Hall an easy to read guide to insuring that what you are seeing via wireshark. I was able to find an issue with the DF bit in a load balancer that was causing confounding headaches in a network using wireshark and this book. Walk it through the syn-ack dance and don't trust that the devices are handling it correctly. Start at one end and work your way through and insure to YOUR satisfaction that every device proscribes to the protocol. Don't rush, don't jump to conclusions. Just follow the packet. That's the best advice I can give you. http://oreilly.com/catalog/9781565925724/ -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Fri, Sep 17, 2010 at 5:06 PM, Abel Alejandro aalejan...@worldnetpr.com wrote: Greetings, This past week I have been trying to find the root cause of tcp performance problems of a few clients that are using a third party metro Ethernet for transport. RFC2544 tests (Layer 2) and iperf using UDP give good symmetric performance almost 100% the speed of the circuit. However all kind of TCP tests result in some kind of asymmetrical deficiency, either the upstream or downstream of the client is hugely different. The latency is not a huge factor since all the metro Ethernet connections have less than 2 ms. So the question basically if is there a good tutorial or white paper for troubleshooting tcp with emphasis of using tools like Wireshark to debug and track this kind of problems. Regards, Abel.
Re: Troubleshooting TCP performance tutorial
To add on to that. Recently Wireshark Network Analysis was released. It's an excellent book covering wireshark and reading packet captures in general by Laura Chappell. I just finished reading it and I have to say it's an excellent book. Highly recommended. Between those two books I think you'll be very close to being a wireshark/packet capture guru. I hope this helps, -Tim Eberhard On Fri, Sep 17, 2010 at 7:33 PM, Joe Hamelin j...@nethead.com wrote: In a situation like yours I found Internet Core Protocols: The Definitive Guide by Eric Hall an easy to read guide to insuring that what you are seeing via wireshark. I was able to find an issue with the DF bit in a load balancer that was causing confounding headaches in a network using wireshark and this book. Walk it through the syn-ack dance and don't trust that the devices are handling it correctly. Start at one end and work your way through and insure to YOUR satisfaction that every device proscribes to the protocol. Don't rush, don't jump to conclusions. Just follow the packet. That's the best advice I can give you. http://oreilly.com/catalog/9781565925724/ -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Fri, Sep 17, 2010 at 5:06 PM, Abel Alejandro aalejan...@worldnetpr.com wrote: Greetings, This past week I have been trying to find the root cause of tcp performance problems of a few clients that are using a third party metro Ethernet for transport. RFC2544 tests (Layer 2) and iperf using UDP give good symmetric performance almost 100% the speed of the circuit. However all kind of TCP tests result in some kind of asymmetrical deficiency, either the upstream or downstream of the client is hugely different. The latency is not a huge factor since all the metro Ethernet connections have less than 2 ms. So the question basically if is there a good tutorial or white paper for troubleshooting tcp with emphasis of using tools like Wireshark to debug and track this kind of problems. Regards, Abel.
Re: Troubleshooting TCP performance tutorial
http://www.amazon.com/Wireshark-Network-Analysis-Official-Certified/dp/1893939995 Spendy but looks good. I'll have to pick it up when the next consulting check comes in. Thanks! I was sad to see that Eric Hall's book was out of print. At least cheap used copies are available. I forgot my copy a few jobs ago... I'm sure someone is getting help from it. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Fri, Sep 17, 2010 at 6:00 PM, Tim Eberhard xmi...@gmail.com wrote: To add on to that. Recently Wireshark Network Analysis was released. It's an excellent book covering wireshark and reading packet captures in general by Laura Chappell. I just finished reading it and I have to say it's an excellent book. Highly recommended. Between those two books I think you'll be very close to being a wireshark/packet capture guru. I hope this helps, -Tim Eberhard On Fri, Sep 17, 2010 at 7:33 PM, Joe Hamelin j...@nethead.com wrote: In a situation like yours I found Internet Core Protocols: The Definitive Guide by Eric Hall an easy to read guide to insuring that what you are seeing via wireshark. I was able to find an issue with the DF bit in a load balancer that was causing confounding headaches in a network using wireshark and this book. Walk it through the syn-ack dance and don't trust that the devices are handling it correctly. Start at one end and work your way through and insure to YOUR satisfaction that every device proscribes to the protocol. Don't rush, don't jump to conclusions. Just follow the packet. That's the best advice I can give you. http://oreilly.com/catalog/9781565925724/ -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Fri, Sep 17, 2010 at 5:06 PM, Abel Alejandro aalejan...@worldnetpr.com wrote: Greetings, This past week I have been trying to find the root cause of tcp performance problems of a few clients that are using a third party metro Ethernet for transport. RFC2544 tests (Layer 2) and iperf using UDP give good symmetric performance almost 100% the speed of the circuit. However all kind of TCP tests result in some kind of asymmetrical deficiency, either the upstream or downstream of the client is hugely different. The latency is not a huge factor since all the metro Ethernet connections have less than 2 ms. So the question basically if is there a good tutorial or white paper for troubleshooting tcp with emphasis of using tools like Wireshark to debug and track this kind of problems. Regards, Abel.
RE: Netflow Tool
I have to agree. Scales very well, open source, more options than you are likely to ever use. --Dave -Original Message- From: Harry Hoffman [mailto:hhoff...@ip-solutions.net] Sent: Friday, September 17, 2010 3:02 PM To: Mike Gatti Cc: nanog@nanog.org Subject: Re: Netflow Tool argus, www.qosient.com/argus On Fri, 2010-09-17 at 14:49 -0400, Mike Gatti wrote: Anyone out there using a good netflow collector that has the capability data to export to CSV? Open Source would be best, but any suggestions are welcome. Thanks, =+=+=+=+=+=+=+=+=+=+=+=+= Michael Gatti cell.703.347.4412 ekim.it...@gmail.com =+=+=+=+=+=+=+=+=+=+=+=+=
Re: Troubleshooting TCP performance tutorial
Date: Fri, 17 Sep 2010 20:06:09 -0400 From: Abel Alejandro aalejan...@worldnetpr.com Greetings, This past week I have been trying to find the root cause of tcp performance problems of a few clients that are using a third party metro Ethernet for transport. RFC2544 tests (Layer 2) and iperf using UDP give good symmetric performance almost 100% the speed of the circuit. However all kind of TCP tests result in some kind of asymmetrical deficiency, either the upstream or downstream of the client is hugely different. The latency is not a huge factor since all the metro Ethernet connections have less than 2 ms. So the question basically if is there a good tutorial or white paper for troubleshooting tcp with emphasis of using tools like Wireshark to debug and track this kind of problems. Regards, Abel. You might look at http://fasterdata.es.net. A lot of it is aimed at very large volume data transfers, but quite a bit is relevant to all TCP issues. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
