Re: Can P2P applications learn to play fair on networks?
On Fri, Oct 26, 2007, Paul Ferguson wrote: If I'm sitting at the end of 8Mb/768k cable modem link, and paying for it, I should damned well be able to use it anytime I want. 24x7. As a consumer/customer, I say Don't sell it it if you can't deliver it. And not just sometimes or only during foo time. All the time. Regardless of my applications. I'm paying for it. What I don't quite get is this, and this is probably skirting operational and more into capacity planning : * You aren't guaranteed 24/7 landline calls on a residential line; and everyone here should understand why. * You aren't guaranteed 24/7 cellular calls on a cell phone; and again, everyone here should understand why. So please remind me again why the internet is particuarly different? The only reason I can think of is your landline isn't marketed as unlimited but your internet is .. Adrian (Who has actually, from time to time, received congested signals on the PSTN and can distinguish that from busy.)
Re: ARPANet Co-Founder Predicts An Internet Crisis (slashdot)
This sounds like the latest noise about global warming and how we are all going to disappear if we do not go green soon. Not to trivialize the issue but its getting to the point where it sounds like fear mongering. The crisis of the internet scenario mentioned here sounds the same Sounds like box pushing to me. Raymond Leigh Porter wrote: A friend of mine who is a Jehova's Witness read something about the Internet and the end of the world in Watchtower recently. Could it be the same thing do you think? Perhaps they got it right this time? -- Leigh Porter Andrew Odlyzko wrote: Isn't this same Dr. Larry Roberts who 5 years ago was claiming, based on data from the 19 largest ISPs, or something like that, that Internet traffic was growing 4x each year, and so the world should rush to order his latest toys (from Caspian Networks, at that time)? http://www.dtc.umn.edu/~odlyzko/doc/roberts.caspian.txt All the evidence points to the growth rate at that time being around 2x per year. And now Larry Roberts claims that current Internet traffic is around 2x per year, while there is quite a bit of evidence that the correct figure is closer to 1.5x per year, http://www.dtc.umn.edu/mints Andrew Odlyzko On Thu Oct 25, Alex Pilosov wrote: On Thu, 25 Oct 2007, Paul Vixie wrote: Dr. Larry Roberts, co-founder of the ARPANET and inventor of packet switching, predicts the Internet is headed for a major crisis in an article published on the Internet Evolution web site today. Internet traffic is now growing much more quickly than the rate at which router cost is decreasing, Roberts says. At current growth levels, the cost of deploying Internet capacity to handle new services like social networking, gaming, video, VOIP, and digital entertainment will double every three years, he predicts, creating an economic crisis. Of course, Roberts has an agenda. He's now CEO of Anagran Inc., which makes a technology called flow-based routing that, Roberts claims, will solve all of the world's routing problems in one go. http://slashdot.org/article.pl?sid=07/10/25/1643248 I don't know, this is mildly offtopic (aka, not very operational) but the article made me giggle a few times. a) It resembles too much of Bob Metcalfe predicting the death of the Internet. We all remember how that went (wasn't there NANOG tshirt with Bob eating his hat?) b) In the words of Randy Bush, We tried this 10 years ago, and it didn't work then. Everyone was doing flow-based routing back in '90-95 (cat6k sup1, gsr e0, first riverstoned devices, foundry ironcore, etc). Then, everyone figured out that it does not scale (tm Vijay Gill) and went to tcam-based architectures (for hardware platforms) or cef-like based architectures for software platforms. In either case, performance doesn't depend on flows/second, but only packets/second. Huge problem with flow-based routing is susceptibility to ddos (or abnormal traffic patterns). It doesn't matter that your device can route 1mpps of normal traffic if it croaks under 10kpps of ddos (or codered/nimda/etc). -alex [not mlc anything] [mlc]
Re: Can P2P applications learn to play fair on networks?
On Fri, 26 Oct 2007, Paul Ferguson wrote: As a consumer/customer, I say Don't sell it it if you can't deliver it. And not just sometimes or only during foo time. All the time. Regardless of my applications. I'm paying for it. I think you have confused a circuit switch network with a packet switched network. If you want a specific capacity 24x7x365 buy a circuit, i.e. T1, T3, OCx. It costs more, but it will be your capacity 100% of the time. There is a reason why shared capacity costs less than dedicated capacity.
Re: Can P2P applications learn to play fair on networks?
On Fri, 26 Oct 2007, Sean Donelan wrote: When 5% of the users don't play nicely with the rest of the 95% of the users; how can network operators manage the network so every user receives a fair share of the network capacity? By making sure that the 5% of users upstream capacity doesn't cause the distribution and core to be full. If the 5% causes 90% of the traffic and at peak the core is 98% full, the 95% of the users that cause 10% of the traffic couldn't tell the different from if the core/distribution was only used at 10%. If your access media doesn't support what's needed (it might be a shared media like cable) then your original bad engineering decision of choosing a shared media without fairness implemented from the beginning is something you have to live with, and you have to keep making bad decisions and implementations to patch what's already broken to begin with. You can't rely on end user applications to play fair when it comes to ISP network being full, and if they don't play fair and it's filling up the end user access, then it's that single end user that gets affected by it, not their neighbors. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Can P2P applications learn to play fair on networks?
On Fri, Oct 26, 2007, Paul Ferguson wrote: If I'm sitting at the end of 8Mb/768k cable modem link, and paying for it, I should damned well be able to use it anytime I want. 24x7. As a consumer/customer, I say Don't sell it it if you can't deliver it. And not just sometimes or only during foo time. All the time. Regardless of my applications. I'm paying for it. No you're not, it would be considerably more expensive if you were paying for what you think you're buying. You're being sold something less, the small print usually tells you. Broadband may not be so popular if it was provided at the 20kbit/s or so the ISP is budgeting for you using. What I don't quite get is this, and this is probably skirting operational and more into capacity planning : * You aren't guaranteed 24/7 landline calls on a residential line; and everyone here should understand why. * You aren't guaranteed 24/7 cellular calls on a cell phone; and again, everyone here should understand why. So please remind me again why the internet is particuarly different? Because we can. That's the packet vs circuit switched difference, we no longer need to contend on time. That's a major benefit but there's always someone who'll abuse it spoiling it for others. The only reason I can think of is your landline isn't marketed as unlimited but your internet is .. Marketing... brandon
Re: Can P2P applications learn to play fair on networks?
On 25-okt-2007, at 18:50, Sean Donelan wrote: Comcast's network is QOS DSCP enabled, as are many other large provider networks. Enterprise customers use QOS DSCP all the time. However, the net neutrality battles last year made it politically impossible for providers to say they use QOS in their consumer networks. And generating packets with false address information is more acceptable? I don't buy it. The problem is that ISPs work under the assumption that users only use a certain percentage of their available bandwidth, while (some) users work under the assumption that they get to use all their available bandwidth 24/7 if they choose to do so. Obviously the two are fundamentally incompatible, which becomes apparent if the number of high usage users starts to fill up available capacity to the detriment of other users. I don't see any way around instituting some kind of traffic limit. Obviously that can't be a peak bandwidth limit because that way ISPs would have to go back to selling 56k connections. (Still enough to generate 15 GB or so per month in one direction.) So it has to be a traffic limit. But then what happens when a customer goes over the limit? I think in the mobile broadband business such customers are harassed to leave. That's a good business practice if you can get away with it, but the Verizon case shows that you probably can't in the long run. So after a customer goes over the traffic limit, you still need to give them SOME service but it must be a reduced one for some time so the customer doesn't keep using up more than their share of available bandwidth. One approach is to limt bandwidth. The other is dumping that user in a lower traffic class. If there is a reasonable amount of bandwidth available for that traffic class, then the user still gets to burst (a little) so this gives them a better service level. I don't see how this logic violates net neutrality principles. Until P2P applications figure out how to play nicely with non-P2P network uses, its going to be a network wreck. And how exactly do you propose that they do that? My answer is: set a different DSCP. As I said before, at least one popular BitTorrent client can already do that. And if ISPs like Comcast already have diffserv-enabled networks, this seems like a no- brainer to me. Don't forget that the first victim of an overloaded last mile link is the user of that link themselves: if they let their torrents rip at max speed, they get in the way of their own interactive traffic.
Re: Can P2P applications learn to play fair on networks?
The problem is that ISPs work under the assumption that users only use a certain percentage of their available bandwidth, while (some) users work under the assumption that they get to use all their available bandwidth 24/7 if they choose to do so. My home dsl is 6mb/384k, so what exactly is the true cost of a dedicated 384K of bandwidth? I mean what you say would be true if we were talking download but for most dsl up speed is so insignificant compared to downspeed I have trouble believing that the true cost for 24x7 isn't being paid. It's just that some of the cable services are offering more up speed (1mb plus) and so are getting a disproportionate amount of fileshare upload traffic (if a download takes X minutes more is upload by a source on a 1mb upload pipe compared to a 384k upload pipe so the upload totals are greater for the cable isp). Geo. George Roettger Netlink Services
Re: Can P2P applications learn to play fair on networks?
Sean Donelan wrote: When 5% of the users don't play nicely with the rest of the 95% of the users; how can network operators manage the network so every user receives a fair share of the network capacity? This question keeps getting asked in this thread. What is there about a scavenger class (based either on monthly volume or actual traffic rate) that doesn't solve this? Sam
Re: Can P2P applications learn to play fair on networks?
Rep. Boucher's solution: more capacity, even though it has been
demonstrated many times more capacity doesn't actually solve this
particular problem.
That would seem to be an inaccurate statement.
Is there something in humans that makes it difficult to understand
the difference between circuit-switch networks, which allocated a fixed
amount of bandwidth during a session, and packet-switched networks, which
vary the available bandwidth depending on overall demand throughout a
session?
Packet switch networks are darn cheap because you share capacity with lots
of other uses; Circuit switch networks are more expensive because you get
dedicated capacity for your sole use.
So, what happens when you add sufficient capacity to the packet switch
network that it is able to deliver committed bandwidth to all users?
Answer: by adding capacity, you've created a packet switched network where
you actually get dedicated capacity for your sole use.
If you're on a packet network with a finite amount of shared capacity,
there *IS* an ultimate amount of capacity that you can add to eliminate
any bottlenecks. Period! At that point, it behaves (more or less) like
a circuit switched network.
The reasons not to build your packet switched network with that much
capacity are more financial and technical than they are impossible. We
know that the average user will not use all their bandwidth. It's also
more expensive to install more equipment; it is nice when you can fit
more subscribers on the same amount of equipment.
However, at the point where capacity becomes a problem, you actually do
have several choices:
1) Block certain types of traffic,
2) Limit {certain types of, all} traffic,
3) Change user behaviours, or
4) Add some more capacity
Come to mind as being the major available options. ALL of these can be
effective. EACH of them has specific downsides.
... 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.
BGP Update Report
BGP Update Report Interval: 24-Sep-07 -to- 25-Oct-07 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS9583 467986 5.1% 400.0 -- SIFY-AS-IN Sify Limited 2 - AS16637 159019 1.7%3614.1 -- MTNNS-AS 3 - AS9498 124404 1.4% 118.1 -- BBIL-AP BHARTI BT INTERNET LTD. 4 - AS462176855 0.8% 519.3 -- UNSPECIFIED UNINET-TH 5 - AS815176667 0.8% 46.4 -- Uninet S.A. de C.V. 6 - AS43403 63301 0.7% 31650.5 -- SVIAZ-PLUS-AS LLC Sviaz Plus 7 - AS15611 61361 0.7% 632.6 -- Iranian Research Organisation 8 - AS475052462 0.6% 237.4 -- CSLOXINFO-ISP-AS-AP CSLOXINFO Public Company Limited. 9 - AS10275 46671 0.5% 23335.5 -- AS-UNITEDNETWORK - ABS-CBN International 10 - AS14390 45483 0.5% 827.0 -- CORENET - Coretel America, Inc. 11 - AS886644740 0.5% 159.8 -- BTC-AS Bulgarian Telecommunication Company Plc. 12 - AS983544360 0.5% 349.3 -- GITS-TH-AS-AP Government Information Technology Services 13 - AS17974 43882 0.5% 114.6 -- TELKOMNET-AS2-AP PT TELEKOMUNIKASI INDONESIA 14 - AS702 42559 0.5% 66.4 -- AS702 Verizon Business EMEA - Commercial IP service provider in Europe 15 - AS12975 42004 0.5% 531.7 -- PALTEL-AS PALTEL Autonomous System 16 - AS24731 41743 0.5% 869.6 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 17 - AS413441407 0.5% 36.9 -- CHINANET-BACKBONE No.31,Jin-rong Street 18 - AS701840908 0.5% 26.3 -- ATT-INTERNET4 - ATT WorldNet Services 19 - AS453839484 0.4% 19.0 -- ERX-CERNET-BKB China Education and Research Network Center 20 - AS647839427 0.4% 33.9 -- ATT-INTERNET3 - ATT WorldNet Services TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS26829 33544 0.4% 33544.0 -- YKK-USA - YKK USA,INC 2 - AS43403 63301 0.7% 31650.5 -- SVIAZ-PLUS-AS LLC Sviaz Plus 3 - AS10275 46671 0.5% 23335.5 -- AS-UNITEDNETWORK - ABS-CBN International 4 - AS17540 21670 0.2% 21670.0 -- MTL-AP Modern Terminals Limited 5 - AS34382 12266 0.1% 12266.0 -- ASSYRUS-SRL-AS Assyrus Srl Maintainer 6 - AS43830 13523 0.1%6761.5 -- ADECCO-ASN Adecco IT Services 7 - AS36011 11375 0.1%5687.5 -- AHSYS-ASN - Atlantic Health System 8 - AS30707 14606 0.2%4868.7 -- 9 - AS16637 159019 1.7%3614.1 -- MTNNS-AS 10 - AS382403366 0.0%3366.0 -- CALYONFINANCIAL-AS-JP Calyon Financial, Inc. 11 - AS200073293 0.0%3293.0 -- AS-ALOGI - ALOGIENT INC. 12 - AS288133043 0.0%3043.0 -- VECERNJI-AS Vecernji list d.d. 13 - AS316712843 0.0%2843.0 -- AKTINFOSYS AKT Informationssysteme AG 14 - AS287338208 0.1%2736.0 -- AVIGAL-AS IT master LLC 15 - AS6174 5099 0.1%2549.5 -- SPRINTLINK8 - Sprint 16 - AS382422359 0.0%2359.0 -- FORTIS-AU-AS Fortis Clearing Sydney 17 - AS31596 14052 0.1%2342.0 -- WPPS-AS WPP Service GmbH Co. KG Frankfurt AS 18 - AS333564518 0.1%2259.0 -- EAGLE-TECH - Eagle-Tech Systems 19 - AS319491879 0.0%1879.0 -- APEXDIGITAL - Apex Digital 20 - AS172167471 0.1%1867.8 -- VERITECT-EAST - Veritect TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.96.14.0/2479070 0.8% AS16637 -- MTNNS-AS 2 - 192.96.13.0/2479037 0.8% AS16637 -- MTNNS-AS 3 - 221.135.22.0/24 56272 0.6% AS9583 -- SIFY-AS-IN Sify Limited 4 - 221.135.113.0/24 54909 0.6% AS9583 -- SIFY-AS-IN Sify Limited 5 - 210.18.10.0/2454005 0.6% AS9583 -- SIFY-AS-IN Sify Limited 6 - 203.101.87.0/24 49240 0.5% AS9498 -- BBIL-AP BHARTI BT INTERNET LTD. 7 - 209.163.125.0/24 43953 0.5% AS14390 -- CORENET - Coretel America, Inc. 8 - 83.228.103.0/24 36854 0.4% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 9 - 12.108.254.0/24 33544 0.3% AS26829 -- YKK-USA - YKK USA,INC 10 - 202.56.250.0/24 33287 0.3% AS9498 -- BBIL-AP BHARTI BT INTERNET LTD. 11 - 193.46.60.0/2431768 0.3% AS43403 -- SVIAZ-PLUS-AS LLC Sviaz Plus 12 - 91.194.244.0/24 31533 0.3% AS43403 -- SVIAZ-PLUS-AS LLC Sviaz Plus 13 - 210.214.173.0/24 28528 0.3% AS9583 -- SIFY-AS-IN Sify Limited 14 - 210.214.177.0/24 25334 0.3% AS9583 -- SIFY-AS-IN Sify Limited 15 - 221.135.77.0/24 24937 0.2% AS9583 -- SIFY-AS-IN Sify Limited 16 - 210.214.211.0/24 24930 0.2% AS9583 -- SIFY-AS-IN Sify Limited 17 - 210.214.172.0/24 24912 0.2% AS9583 -- SIFY-AS-IN Sify Limited 18 - 210.214.210.0/24 24892 0.2%
The Cidr Report
This report has been generated at Fri Oct 26 21:14:13 2007 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
19-10-07240292 153438
20-10-07240374 154309
21-10-07240830 154305
22-10-07240521 155215
23-10-07240800 157397
24-10-07240838 157638
25-10-07240710 157689
26-10-07241073 158134
AS Summary
26674 Number of ASes in routing system
11258 Number of ASes announcing only one prefix
1959 Largest number of prefixes announced by an AS
AS4538 : ERX-CERNET-BKB China Education and Research Network
Center
89037056 Largest address span announced by an AS (/32s)
AS721 : DISA-ASNBLK - DoD Network Information Center
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').
--- 26Oct07 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 241338 1581178322134.5% All ASes
AS4538 1959 717 124263.4% ERX-CERNET-BKB China Education
and Research Network Center
AS9498 1012 73 93992.8% BBIL-AP BHARTI BT INTERNET
LTD.
AS4755 1471 542 92963.2% VSNL-AS Videsh Sanchar Nigam
Ltd. Autonomous System
AS11492 1153 416 73763.9% CABLEONE - CABLE ONE
AS22773 799 71 72891.1% CCINET-2 - Cox Communications
Inc.
AS6478 1114 400 71464.1% ATT-INTERNET3 - ATT WorldNet
Services
AS4134 1098 414 68462.3% CHINANET-BACKBONE
No.31,Jin-rong Street
AS18566 1028 357 67165.3% COVAD - Covad Communications
Co.
AS4323 1342 693 64948.4% TWTC - Time Warner Telecom,
Inc.
AS8151 1058 417 64160.6% Uninet S.A. de C.V.
AS17488 855 266 58968.9% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS19262 792 218 57472.5% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS18101 608 81 52786.7% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS15270 599 88 51185.3% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS7545 723 228 49568.5% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS7018 1510 1020 49032.5% ATT-INTERNET4 - ATT WorldNet
Services
AS2386 1241 765 47638.4% INS-AS - ATT Data
Communications Services
AS6197 1025 583 44243.1% BATI-ATL - BellSouth Network
Solutions, Inc
AS4812 523 92 43182.4% CHINANET-SH-AP China Telecom
(Group)
AS4766 816 387 42952.6% KIXS-AS-KR Korea Telecom
AS4808 497 123 37475.3% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS9443 451 78 37382.7% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS17676 502 136 36672.9% GIGAINFRA BB TECHNOLOGY Corp.
AS19916 569 204 36564.1% ASTRUM-0001 - OLM LLC
AS9583 1127 772 35531.5% SIFY-AS-IN Sify Limited
AS3602 432 78 35481.9% AS3602-RTI - Rogers Telecom
Inc.
AS4668 518 169 34967.4% LGNET-AS-KR LG CNS
AS5668 659 319 34051.6% AS-5668 - CenturyTel Internet
Holdings, Inc.
AS577599 267 33255.4% BACOM - Bell Canada
AS4802 487 155 33268.2% ASN-IINET iiNet Limited
Total 26567101291643861.9% Top 30 total
Re: Can P2P applications learn to play fair on networks?
From: Geo. [EMAIL PROTECTED] To: nanog@merit.edu Subject: Re: Can P2P applications learn to play fair on networks? Date: Fri, 26 Oct 2007 06:18:01 -0400 The problem is that ISPs work under the assumption that users only use a certain percentage of their available bandwidth, while (some) users work under the assumption that they get to use all their available bandwidth 24/7 if they choose to do so. My home dsl is 6mb/384k, so what exactly is the true cost of a dedicated 384K of bandwidth? I mean what you say would be true if we were talking Dunno, but I've got a 3m/384k line for about DSL business class for $105/month. Don't think I can do better pricewise, but... download but for most dsl up speed is so insignificant compared to downspeed I have trouble believing that the true cost for 24x7 isn't being paid. It's just that some of the cable services are offering more up speed (1mb plus) and so are getting a disproportionate amount of fileshare upload traffic (if a download takes X minutes more is upload by a source on a 1mb upload pipe compared to a 384k upload pipe so the upload totals are greater for the cable isp). Geo. George Roettger Netlink Services - Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 9B1 San Jose, CA 95134 I am perfectly capable of learning from my mistakes. I will surely learn a great deal today. A democracy is a sheep and two wolves deciding on what to have for lunch. Freedom is a well armed sheep contesting the results of the decision. The best we can hope for concerning the people at large is that they be properly armed. --Alexander Hamilton
RE: Can P2P applications learn to play fair on networks?
It would seem that the state of NY agrees with you: http://www.networkworld.com/community/node/20981 The settlement follows a nine-month investigation into the marketing of NationalAccess and BroadbandAccess plans for wireless access to the internet for laptop computer users. Attorney General's investigation found that Verizon Wireless prominently marketed these plans as Unlimited, without disclosing that common usages such as downloading movies or playing games online were prohibited. The company also cut off heavy internet users for exceeding an undisclosed cap of usage per month. As a result, customers misled by the company's claims, enrolled in its Unlimited plans, only to have their accounts abruptly terminated for excessive use, leaving them without internet services and unable to obtain refunds. Jamie Bowden -- It was half way to Rivendell when the drugs began to take hold Hunter S Tolkien Fear and Loathing in Barad Dur Iain Bowen [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Ferguson Sent: Friday, October 26, 2007 1:19 AM To: [EMAIL PROTECTED] Cc: nanog@merit.edu Subject: Re: Can P2P applications learn to play fair on networks? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Sean Donelan [EMAIL PROTECTED] wrote: When 5% of the users don't play nicely with the rest of the 95% of the users; how can network operators manage the network so every user receives a fair share of the network capacity? I don't know if that's a fair argument. If I'm sitting at the end of 8Mb/768k cable modem link, and paying for it, I should damned well be able to use it anytime I want. 24x7. As a consumer/customer, I say Don't sell it it if you can't deliver it. And not just sometimes or only during foo time. All the time. Regardless of my applications. I'm paying for it. - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHIXiYq1pz9mNUZTMRAnpdAJ98sZm5SfK+7ToVei4Ttt8OocNPRQCgheRL lq9rqTBscFmo8I4Y8r1ZG0Q= =HoIx -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: ARPANet Co-Founder Predicts An Internet Crisis (slashdot)
On Thu, Oct 25, 2007 at 05:36:11PM -0400, Scott Brim wrote: On 25 Oct 2007 at 17:02 -0400, Jason Frisvold allegedly wrote: Anyone have any experience with these Anagran flow routers? Are they that much of a departure from traditional routing that it makes a big difference? There's no difference in routing per se. Rather it's in-band signaling of QoS parameters to provide feedback to queue management. I read over the vendor's site when that article was sent, and I'll be honest, a lot of what they are trumpeting are steps backwards in router performance. While the site is pretty light on the details, Anagram's Fast Flow Routing Architecture sounds very similar to dated multilayer switching approaches. CEF-like adjacency certainly provides higher routing throughput with less overhead. So if it's a win, it must be a win because the cost of going back to a flow-caching is offset by a gain in better QoS. Their QoS details are a bit sketchy, but this would worry me: BTC basically 'watches every flow. By constantly comparing each flow's behavior over time against a simple set of operator-defined rules per flow class, BTC can identify suspect flows that by virtue of their duration, byte count, source/destination, or other criteria, require some form of corrective or policing action. So now there's a flow table that in the forwarding plane. What happens when the flow table overflows? How does the router decide when to age-out a flow? I have yet to see a flow-centric filtering device save the network when it's flow/session table is what's under attack. -- Ross Vandegrift [EMAIL PROTECTED] The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell. --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
RE: Can P2P applications learn to play fair on networks?
Ah, but the reality is that you *think* you're paying for something, but the operator never really intended to deliver it to you. If anything, we need better full-disclosure, preferably voluntarily, and if not that way, legislatively required. Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Ferguson Sent: Friday, October 26, 2007 12:19 AM To: [EMAIL PROTECTED] Cc: nanog@merit.edu Subject: Re: Can P2P applications learn to play fair on networks? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Sean Donelan [EMAIL PROTECTED] wrote: When 5% of the users don't play nicely with the rest of the 95% of the users; how can network operators manage the network so every user receives a fair share of the network capacity? I don't know if that's a fair argument. If I'm sitting at the end of 8Mb/768k cable modem link, and paying for it, I should damned well be able to use it anytime I want. 24x7. As a consumer/customer, I say Don't sell it it if you can't deliver it. And not just sometimes or only during foo time. All the time. Regardless of my applications. I'm paying for it. - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHIXiYq1pz9mNUZTMRAnpdAJ98sZm5SfK+7ToVei4Ttt8OocNPRQCgheRL lq9rqTBscFmo8I4Y8r1ZG0Q= =HoIx -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: Can P2P applications learn to play fair on networks?
On Fri, 26 Oct 2007, Joe Greco wrote: So, what happens when you add sufficient capacity to the packet switch network that it is able to deliver committed bandwidth to all users? Answer: by adding capacity, you've created a packet switched network where you actually get dedicated capacity for your sole use. Changing the capacity at different points in the network merely moves the congestion points around the network. There will still be congestion points in any packet network. The problem is not bandwidth, its shared congestion points. Don't share congestion points: bandwidth irrelevant. Shared congestion points: bandwidth irrelevant. A 56Kbps network with no shared congestion points: not a problem A 1,000 Terabit network with shared congestion points: a problem The difference is if there is shared congestion points, not the bandwidth. If you think adjusting capacity is the solution, and hosts don't voluntarily adjust their demand on their own, then you should be *REDUCING* your access capacity which will move the congestion point closer to the host. However, I think a better idea instead of trying to eliminate all shared congestion points everywhere in a packet network would be for the TCP protocol magicians to develop a TCP-multi-flow congestion avoidance which would share the available capacity better between all of the demand at the various shared congestion points in the network. Isn't the Internet supposed be a dumb network with smart hosts? If the hosts act dumb, is the network forced to act smart?
Re: Can P2P applications learn to play fair on networks?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Sean Donelan [EMAIL PROTECTED] wrote: On Fri, 26 Oct 2007, Paul Ferguson wrote: As a consumer/customer, I say Don't sell it it if you can't deliver it. And not just sometimes or only during foo time. All the time. Regardless of my applications. I'm paying for it. I think you have confused a circuit switch network with a packet switched network. No, I'm talking about deceptive marketing practices, consumer expectations, and customer retention. But I digress. - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHIhboq1pz9mNUZTMRAsrnAKDrIbVLODdt2bdi2pmk8/Occ3IxjgCgy7pD pTw+fiSpjYm+DoJ/xVdb9Jc= =MOR+ -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
RE: Can P2P applications learn to play fair on networks?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Jamie Bowden [EMAIL PROTECTED] wrote: It would seem that the state of NY agrees with you: http://www.networkworld.com/community/node/20981 The part of this discussion that really infuriates me (and Joe Greco has hit most of the salient points) is the deceptiveness in how ISPs underwrite the service their customers subscribe to. For instance, in our data centers, we have 1Gb uplinks to our ISPs, but guaranteed service subscription (a la CIR) to a certain rate which we engineer (based on average traffic volume, say, 400Mb), but burstable to full line rate -- if the bandwidth is available. Now, we _know_ this, because it's in the contract. :-) As a consumer, my subscription is based on language that doesn't say you can only have the bandwidth you're paying for when we are congested, because we oversubscribed our network capacity. That's the issue here. I know full well the technical arguments of both sides of the issues, the economic issues, and the difference between a circuit switched network and a pcekt network, thank you. :-) $.02, - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHIhwoq1pz9mNUZTMRAlheAJ9KlFY73/+1dxQ7Q898reknG/MxHwCcDURl i0ARgqsvoxpPQkXFVCe9ons= =NGAf -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: Can P2P applications learn to play fair on networks?
On Fri, 26 Oct 2007, Paul Ferguson wrote: No, I'm talking about deceptive marketing practices, consumer expectations, and customer retention. From the Comcast order page: Actual speeds may vary and are not guaranteed. Many factors affect download speed. From the Trend Micro order page: With no effort on your part, Trend Micro Internet Security Pro automatically and continuously guards your computer, personal identity and online transactions from cybercriminals. Whether you are at home or away, you can protect your personal information from future and present threats with sophisticated identity protection features. Glass houses are everywhere.
Re: Can P2P applications learn to play fair on networks?
On Fri, 26 Oct 2007, Iljitsch van Beijnum wrote: And generating packets with false address information is more acceptable? I don't buy it. When a network is congested, someone is going to be upset about any possible response. Within the limitations the network operator has, using a TCP RST to cause applications to back-off network use is an interesting hack (in the original sense of the word: quick, elaborate and/or jerry rigged solution). Using a TCP RST is probably more transparent than using some other clever active queue management technique to drop particular packets from the network. Comcast's publicity problem seems to be that they used a more visible technique instead of a harder to detect technique to respond to network congestion. If Comcast had used Sandvine's other capabilities to inspect and drop particular packets, would that have been more acceptable? Please re-read my first post about some of the alternatives, and people griping about all of them. Dropping random packets (i.e. FIFO queue, RED, not good on multiple-flows) Dropping particular packets (i.e. AQM, WRED, etc, difficult for multiple flows) Dropping DSCP marked packets first (i.e. scavenger class requires voluntary marking) Dropping particular protocols (i.e. ACLs, difficult for dynamic protocols) Sending an ICMP Source quench (i.e. ignored by many IP stacks) Sending a TCP RST (i.e. most application protocols respond, easy for out-of-band devices) Changing IP headers (i.e. ECN bits, not implemented widely, requires inline device) Changing TCP headers (i.e. decrease windowsize, requires inline device) Changing access speed (i.e. dropping user down to 64Kbps, crushes every application) Charging for overuse (i.e. more than X Gbps data transferred per time period, complaints about extra charges) Terminate customers using too much capacity (i.e. move the problem to a different provider) and of course Do nothing (i.e. let the applications grab whatever they can, even if that results in incredibly bad performance for many users) Add more capacity (i.e. what do you do in the mean time, people want something now) Raise prices (i.e. discourage additional use) People are going to gripe no matter what. One week they are griping about ISPs not doing anything, the next week they are griping about ISPs doing something.
Re: Can P2P applications learn to play fair on networks?
On Fri, 26 Oct 2007, Sean Donelan wrote: If Comcast had used Sandvine's other capabilities to inspect and drop particular packets, would that have been more acceptable? Yes, definately. Dropping random packets (i.e. FIFO queue, RED, not good on multiple-flows) Dropping particular packets (i.e. AQM, WRED, etc, difficult for multiple flows) Dropping DSCP marked packets first (i.e. scavenger class requires voluntary marking) Dropping particular protocols (i.e. ACLs, difficult for dynamic protocols) Dropping a limited ratio of the packets is acceptable at least to me. Sending a TCP RST (i.e. most application protocols respond, easy for out-of-band devices) ... but terminating the connection is not. Spoofing packets is not something an ISP should do. Ever. Dropping and/or delaying packets, yes, spoofing, no. Changing IP headers (i.e. ECN bits, not implemented widely, requires inline device) Changing TCP headers (i.e. decrease windowsize, requires inline device) Changing access speed (i.e. dropping user down to 64Kbps, crushes every application) Charging for overuse (i.e. more than X Gbps data transferred per time period, complaints about extra charges) Terminate customers using too much capacity (i.e. move the problem to a different provider) These are all acceptable, where I think the adjust MSS is bordering on intrusion in customer traffic. An ISP should be in the market of forwarding packets, not changing them. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Can P2P applications learn to play fair on networks?
On Fri, 26 Oct 2007, Mikael Abrahamsson wrote: If Comcast had used Sandvine's other capabilities to inspect and drop particular packets, would that have been more acceptable? Yes, definately. So another in-line device is better than an out-of-band device. ... but terminating the connection is not. Spoofing packets is not something an ISP should do. Ever. Dropping and/or delaying packets, yes, spoofing, no. So ISPs should not do any NAT, transparent accelerators, transparent web caches, walled gardens for infected computers, etc. We seem to agree that ISPs can intefere with network traffic, the debate is only how they do it.
RE: BitTorrent swarms have a deadly bite on broadband nets
Back in the dawn of the public internet this same sort of thing was argued fiercely on lists like com-priv (commercialization and privatization of the internet.) It was usually around flat rate vs bandwidth charging. My take was that bandwidth pricing lets you buy as much pipe as you might ever need, like 100mb/s or more SOHO, but only pay for what you use, which seemed rational if the technology supported that. Flat-rate pricing encourages you to guess the most bandwidth you'll ever need in advance and only pay for that. In theory hybrid models could exist (variable, on-demand bandwidth shaping and all that, it's pretty easy in the p-p wireless world.) What's happened is the worst of both worlds where vendors are selling end-users flat-rate pipes (think, for example, 20mb/s FTTH for under $100/mo) but wishing customers would use it as if it were priced per bit. This is a business model dislocation. It reminds me of the time, back in my heartier young man days, when I'd frequent an all you could eat buffet nearby and finally the owner tossed me out after I overstayed my welcome one day, I'd sit there doing school work and make trips to the buffet every so often, saying yes, that's ALL you can eat, now get OUTTA here!!! -- -Barry Shein The World | [EMAIL PROTECTED] | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Login: Nationwide Software Tool Die| Public Access Internet | SINCE 1989 *oo*
RE: Can P2P applications learn to play fair on networks?
On Fri, 26 Oct 2007, Paul Ferguson wrote: The part of this discussion that really infuriates me (and Joe Greco has hit most of the salient points) is the deceptiveness in how ISPs underwrite the service their customers subscribe to. For instance, in our data centers, we have 1Gb uplinks to our ISPs, but guaranteed service subscription (a la CIR) to a certain rate which we engineer (based on average traffic volume, say, 400Mb), but burstable to full line rate -- if the bandwidth is available. Now, we _know_ this, because it's in the contract. :-) As a consumer, my subscription is based on language that doesn't say you can only have the bandwidth you're paying for when we are congested, because we oversubscribed our network capacity. That's the issue here. You have a ZERO CIR on a consumer Internet connection. How many different ways can an ISP say speeds may vary and are not guaranteed. It says so in the _contract_. So why don't you know that? ISPs tell you that when you order, in the terms of service, when you call customer care that speeds may vary and are not guaranteed. How much do you pay for your commercial 1GE connection with a 400Mbps CIR? Is it more or less than what you pay for a consumer connection with a ZERO CIR? ISPs are happy to sell you SLAs, CIRs, etc. But if you don't buy SLAs, CIRs, etc, why are you surprised you don't get them? Once again blinkspeeds may vary and are not guaranteed/blink. Now that you know that speeds may vary and are not guaranteed, does that make you satisified?
Re: RIPE is just more fun.
On Fri, Oct 26, 2007 at 03:42:27PM -0400, Leo Bicknell wrote: http://www.youtube.com/watch?v=_y36fG2Oba0 Cool. Time for a remix as well! Maybe i'll go to RIPE next time! - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
RIPE is just more fun.
http://www.youtube.com/watch?v=_y36fG2Oba0 -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpIykjL04NwK.pgp Description: PGP signature
OT: Vendors Using NANOG for a Sales Channel
--- [EMAIL PROTECTED] wrote: From: David Ulevitch [EMAIL PROTECTED] Often times when I get these (and it's pretty often) I just take their email address and add it to my list of people we send out RFQs to. The worst thing that happens is that they come back with a good price, good service and boom, I've found a new vendor. -- I would suggest that no one should buy from vendors who get email addresses from NANOG or other technical mailing lists. It will only encourage them to do it more and ruin the value of the mailing list in question. You obviously haven't had the experiences that some have had with sales folks that use this method. Some are like the little Chihuahua that won't quit trying to hump your leg. No matter how many times you tell them you're not going to do it they keep trying. However, the company in this case did redeem themselves and I respect a company like that. scott
Re: OT: Vendors Using NANOG for a Sales Channel
On Fri, 26 Oct 2007, Scott Weeks wrote: I would suggest that no one should buy from vendors who get email addresses from NANOG or other technical mailing lists. It will only encourage them to do it more and ruin the value of the mailing list in question. You obviously haven't had the experiences that some have had with sales folks that use this method. Some are like the little Chihuahua that won't quit trying to hump your leg. No matter how many times you tell them you're not going to do it they keep trying. However, the company in this case did redeem themselves and I respect a company like that. Which is to say, they were one of the few that apologised. The recurring theme is that it's always a rogue salesperson who didn't know better, or some overzealous marketing person. I'd agree with Scott on this point, that you shouldn't buy from vendors who do this, but ultimately, it's not going to change the way they behave. Over the course of my entire career, I've never been a fan of salespeople, because they do what they're supposed to do: whatever they can to make money. In our particular field, it cuts both ways, because they're either hassling you to buy something, or your own salespeople are selling something you can't support or don't even offer. It's the kind of thing that probably won't change until someone whips out one of the spam laws and sues a couple people over it, or engages in executive carpet bombing. Either way, it's always going to be a temporary reprieve until it gets out of hand again. It'd be churlish of NANOG, as an organization, to organize blacklists and boycotts, and probably even shooting itself in the foot because some vendors may actually be offering something worthwhile, but is there any other real solution? How often do people take the time to ask any given salescritter how they came by contact info? - billn
Re: OT: Vendors Using NANOG for a Sales Channel
On Fri, Oct 26, 2007 at 01:33:38PM -0700, Bill Nash wrote: How often do people take the time to ask any given salescritter how they came by contact info? I've done it, but if you've forced your way through my various filters and manage to get me on the phone and I ask you that, it's pretty much kiss of death unless you have a very good answer. John
Re: OT: Vendors Using NANOG for a Sales Channel
All, This thread has run its course. Let's move on, please, as it is not and never has been on topic. Thanks! - Tim
Re: Can P2P applications learn to play fair on networks?
On Fri, 26 Oct 2007, Paul Ferguson wrote: The part of this discussion that really infuriates me (and Joe Greco has hit most of the salient points) is the deceptiveness in how ISPs underwrite the service their customers subscribe to. For instance, in our data centers, we have 1Gb uplinks to our ISPs, but guaranteed service subscription (a la CIR) to a certain rate which we engineer (based on average traffic volume, say, 400Mb), but burstable to full line rate -- if the bandwidth is available. Now, we _know_ this, because it's in the contract. :-) As a consumer, my subscription is based on language that doesn't say you can only have the bandwidth you're paying for when we are congested, because we oversubscribed our network capacity. That's the issue here. You have a ZERO CIR on a consumer Internet connection. Where's it say that? How many different ways can an ISP say speeds may vary and are not guaranteed. It says so in the _contract_. So why don't you know that? Gee, that's not exactly what I read. http://help.twcable.com/html/twc_sub_agreement2.html Section 6 (a) Speeds and Network Management. I acknowledge that each tier or level of the HSD Service has limits on the maximum speed at which I may send and receive data at any time, as set forth in the price list or Terms of Use. I understand that the actual speeds I may experience at any time will vary based on a number of factors, including the capabilities of my equipment, Internet congestion, the technical properties of the websites, content and applications that I access, and network management tools and techniques employed by TWC. I agree that TWC or ISP may change the speed of any tier by amending the price list or Terms of Use. My continued use of the HSD Service following such a change will constitute my acceptance of any new speed. I also agree that TWC may use technical means, including but not limited to suspending or reducing the speed of my HSD Service, to ensure compliance with its Terms of Use and to ensure that its service operates efficiently. Both to ensure that its service operates efficiently and techniques employed by TWC would seem to allow for some variation in speed by the local cable company - just as the speed on a freeway may drop during construction, or during rush hour. However, there's very strong language in there that indicates that the limits on sending and receiving are set forth in the price list. ISPs tell you that when you order, in the terms of service, when you call customer care that speeds may vary and are not guaranteed. Speeds may vary and are not guaranteed is obvious on the Internet. We're deliberately going to screw with your speeds if you use too much is not, at least to your average consumer. How much do you pay for your commercial 1GE connection with a 400Mbps CIR? Is it more or less than what you pay for a consumer connection with a ZERO CIR? Show me a consumer connection with a contract that /says/ that it has a zero CIR, and we can start that discussion. Your saying that it has a zero CIR does not make it so. ISPs are happy to sell you SLAs, CIRs, etc. But if you don't buy SLAs, CIRs, etc, why are you surprised you don't get them? There's a difference between not having a SLA, CIR, etc., all of which I'm fine for with a residential class connection, and having an ISP that sells 20Mbps! Service! Unlimited! but then quietly messes with users who actually use that. The ISP that sells a 20Mbps pipe, and doesn't mess with it, but has a congested upstream, these guys are merely oversubscribed. That's the no-SLA-no-CIR situation. Once again blinkspeeds may vary and are not guaranteed/blink. Now that you know that speeds may vary and are not guaranteed, does that make you satisified? Only if my ISP isn't messing with my speeds, or has made it exceedingly clear in what ways they'll be messing with my speeds so that they do not match what I paid for on the price list. Let me restate that: I don't really care if I get 8 bits per second to some guy in Far North, Canada who is on a dodgy satellite Internet link. That's what speeds may vary and are not guaranteed should refer to - things well beyond an ISP's control. Now, let me flip this on its ear. We rent colo machines to users. We provide flat rate pricing. When we sell a machine with 1Mbps of Internet bandwidth, that is very much speeds may vary and are not guaranteed - HOWEVER, we do absolutely promise that if it's anything of ours that is causing delivery of less than 1Mbps, WE WILL FIX IT. PERIOD. This isn't a SLA. This isn't a CIR. This is simple honesty, we deliver what we advertised, and what the customer is paying for. The price points that consumers are paying for resi Internet may not allow quite that level of guarantee, but does that mean that they do not deserve to be provided with some transparency so that end users understand what the ACTUAL policy is,
Re: OT: Vendors Using NANOG for a Sales Channel
How often do people take the time to ask any given salescritter how they came by contact info? I use tagged addresses (as you can see), and if a vendor contacts me at an address I use solely for mailing lists the conversation is going to be short, unpleasant and unprofitable-- but I can't remember the last time that happened. My real address gets hit all the time by cold calls, but that goes with the territory. -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com
Re: Can P2P applications learn to play fair on networks?
On 10/22/07 2:01 AM, Mikael Abrahamsson [EMAIL PROTECTED] wrote: Could someone who knows DOCSIS 3.0 (perhaps these are general DOCSIS questions) enlighten me (and others?) by responding to a few things I have been thinking about. Let's say cable provider is worried about aggregate upstream capacity for each HFC node that might have a few hundred users. Do the modems support schemes such as everybody is guaranteed 128 kilobit/s, if there is anything to spare, people can use it but it's marked differently in IP PRECEDENCE and treated accordingly to the HFC node, and then carry it into the IP aggregation layer, where packets could also be treated differently depending on IP PREC. This is in my mind a much better scheme (guarantee subscribers a certain percentage of their total upstream capacity, mark their packets differently if they burst above this), as this is general and not protocol specific. It could of course also differentiate on packet sizes and a lot of other factors. Bad part is that it gives the user an incentive to hack their CPE to allow them to send higher speed with high priority traffic, thus hurting their neighbors. Yes, as a part of the DOCSIS specification (waiting for D3.0 not required); however, implementations vary on the CMTS end of the equation though. Having this capability ubiquitously on the CMTS equipment simplifies the problem space greatly (plus removes that hacked CPE risk). -ron
