Re: TCP congestion
[EMAIL PROTECTED] wrote on 07/12/2007 02:07:00 PM: Typical Problem Scenario: Data transmission is humming along consistently at 2 Mbps, all of a sudden transmission rates drop to nothing then pickup again after 15-20 seconds. Prior to the drop off (based on packet capture) there is usually a DUP ACK/SACK coming from the receiver followed by the Retransmits and congestion avoidence. What is strange is there is nothing prior to the drop off that would be an impetus for congestion (no high BW utilization or packet loss). Perhaps you're filling buffers by flowing from a 1Gbps link into a 9Mbps circuit. Dropped packets induces slow-start/congestion avoidance. Joe
Re: Thoughts on increasing MTUs on the internet
Large MTUs enable significant throughput performance enhancements for large data transfers over long round-trip times (RTTs.) The original question had to do with local subnet to local subnet where the difference would not be noticable. But for users transferring large data sets over long distances (e.g. LHC experimental data from CERN in France to universities in the US) large MTUs can make a big difference. For an excellent and detailed (though becoming dated) examination of this see: Raising the Internet MTU Matt Mathis, et. al. http://www.psc.edu/~mathis/MTU/ Joe Stephen Wilcox [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 04/12/2007 01:45 PM To [EMAIL PROTECTED] cc NANOG list [EMAIL PROTECTED] Subject Re: Thoughts on increasing MTUs on the internet On Thu, Apr 12, 2007 at 11:34:43AM -0400, [EMAIL PROTECTED] wrote: I think it's a great idea operationally, less work for the routers and more efficient use of bandwidth. It would also be useful to devise some way to at least partially reassemble fragmented frames at links capable of large MTU's. I think you underestimate the memory and cpu required on large links to be able to buffer the data that would allow a reassembly by an intermediate router Since most PC's are on a subnet with a MTU of 1500 (or 1519) packets would still be limited to 1500B or fragmented before they reach the higher speed links. The problem with bringing this to fruition in the internet is going to be cost and effort. The ATT's and Verizons of the world are going to see this as a major upgrade without much benefit or profit. The Cisco's and Junipers are going to say the same thing when they have to write this into their code plus interoperability with other vendors implementations of it. I dont think any of the above will throw out any particular objection.. I think your problem is in figuring out a way to implement this globally and not break stuff which relies so heavily upon 1500 bytes much of which does not even cater for the possibility another MTU might be possible. Steve Iljitsch van Beijnum [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 04/12/2007 05:20 AM To NANOG list [EMAIL PROTECTED] cc Subject Thoughts on increasing MTUs on the internet Dear NANOGers, It irks me that today, the effective MTU of the internet is 1500 bytes, while more and more equipment can handle bigger packets. What do you guys think about a mechanism that allows hosts and routers on a subnet to automatically discover the MTU they can use towards other systems on the same subnet, so that: 1. It's no longer necessary to limit the subnet MTU to that of the least capable system 2. It's no longer necessary to manage 1500 byte+ MTUs manually Any additional issues that such a mechanism would have to address?
Re: Thoughts on increasing MTUs on the internet
[EMAIL PROTECTED] wrote on 04/12/2007 04:05:43 PM: On Thu, 12 Apr 2007, Joe Loiacono wrote: Large MTUs enable significant throughput performance enhancements for large data transfers over long round-trip times (RTTs.) The original This is solved by increasing TCP window size, it doesn't depend very much on MTU. Window size is of course critical, but it turns out that MTU also impacts rates (as much as 33%, see below): MSS 0.7 Rate = - * --- RTT(P)**0.5 MSS = Maximum Segment Size RTT = Round Trip Time P = packet loss Mathis, et. al. have 'verified the model through both simulation and live Internet measurements.' Also (http://www.aarnet.edu.au/engineering/networkdesign/mtu/why.html): This is shown to be the case in Anand and Hartner's TCP/IP Network Stack Performance in Linux Kernel 2.4 and 2.5 in Proceedings of the Ottawa Linux Symposium, 2002. Their experience was that a machine using a 1500 byte MTU could only reach 750Mbps whereas the same machine configured with 9000 byte MTUs handsomely reached 1Gbps. AARnet - Australia's Academic and Research Network Larger MTU is better for devices that for instance do per-packet interrupting, like most endsystems probably do. It doesn't increase long-RTT transfer performance per se (unless you have high packetloss because you'll slow-start more efficiently). -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Thoughts on increasing MTUs on the internet
I believe the formula applies when the TCP window size is held constant (and maybe as large as is necessary for the bandwidth-delay product). Obviously P going to zero is a problem; there are practical limitations. But bit error rate is usually not zero over long distances. The formula is not mine, it's not new, and there is empirical evidence to support it. Check out the links for more (and better :-) info. Joe [EMAIL PROTECTED] wrote on 04/12/2007 04:48:09 PM: On Thu, 12 Apr 2007, Joe Loiacono wrote: Window size is of course critical, but it turns out that MTU also impacts rates (as much as 33%, see below): MSS 0.7 Rate = - * --- RTT(P)**0.5 MSS = Maximum Segment Size RTT = Round Trip Time P = packet loss So am I to understand that with 0 packetloss I get infinite rate? And TCP window size doesn't affect the rate? I am quite confused by this statement. Yes, under congestion larger MSS is better, but without congestion I don't see where it would differ apart from the interrupt load I mentioned earlier? -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Broadband ISPs taxed for generating light energy
Notice the date: October 10. That is the Indian equivalent of our April 1. Joe [EMAIL PROTECTED] wrote on 10/10/2006 10:28:13 AM: .. because they provide internet over fiber optic cables, which workby sending pulses of light down the cable to push packets .. http://www.hindu.com/2006/10/10/stories/2006101012450400.htm So they get slapped with tax + penalties of INR 241.8 million. Broadband providers accused of tax evasion Special Correspondent Commercial Tax Department serves notice on Airtel # Firms accused of evading tax on sale of `light energy' # Loss to State exchequer estimated at Rs. 1,200 crore Bangalore: The Commercial Tax Department has served a notice on Airtel, owned by Bharti Televentures Ltd., seeking payment of Rs. 24.18 crore as tax, interest and penalty for the sale of `light energy' to its customers for providing broadband through optical fibre cables (OFC). The department has been investigating alleged tax evasion by OFC broadband providers, both in the public and private sectors, for selling lightenergy to customers. While the assessment on Airtel was completed and a notice issued to it for alleged tax evasion during the year 2005-06, no assessment has been concluded on other OFC broadband providers, A.K. Chitaguppi, Deputy Commissioner of Commercial Taxes, said. Other OFC broadband providers facing tax evasion charges are public sector BSNL and private sector VSNL, Reliance, Tata Teleservices and Sify. The Commercial Tax Department has estimated a loss of Rs. 1,200 crore to the State exchequer in this regard since OFC broadband providers have been operating in the State for several years. Mr. Chitaguppi said that OFC operates on light energy, which is artificially created by the OFC providers and sold to customers for the purpose of data transmission and information, on the OFC broadband line. Without such energy, data or information cannot be transmitted. Whoever sells light energy is liable to pay VAT as it comes under the category of goods, and hence its sale constitutes taxable turnover attracting VAT at 12.5 per cent, he said. Bharti Televentures had approached the Karnataka High Court seeking to quash the demand notice, but failed to get a stay when the case was heard by Justice Shantanu Goudar on September 1. The judge rejected Bharti's plea seeking issue of an injunction against any initiatives from the Commercial Tax Department on the recovery of the tax. Bharti Televentures had contended in the High Court that re-assessment orders passed by State tax officials and the issue of demand notice was not valid as the disputed activity fell under the provision of service tax levied by the Union Government and did not attract VAT. The High Court is expectedto take up the case for hearing again in the next few days. `Business venture' The Commercial Tax Department has argued that the OFC broadband operators are running a business venture after investing thousands of crores to put in place a state-of-the-art set-up to artificially generate light energy and supply it to its customers for their data transmission work. The characteristics of the light energy constitute a moveable property, which has to be categorised as `goods' as per the norms laid down by the Supreme Court. In the process of data transmission, other than light energy, no other elements are involved and the customers are paying for the same. This proves that light energy constitutes goods, which is liable for levy of tax. Therefore, the State has every legal competence and jurisdiction to tax it, the department has contended. It has taken serious note of the non-payment of taxes by the broadband service providers. Reporting a turnover and then claiming exemption is one thing. But some of the OFC operators don't even report their turnovers, Mr. Chitaguppi alleged.
Re: text based netflow top ASN tool?
... or perhaps flow-tools? Installs easy. Great capability. http://freshmeat.net/projects/flow-tools/ http://www.splintered.net/sw/flow-tools/ matthew zeier [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 08/04/2006 02:04 AM To [EMAIL PROTECTED] cc Subject text based netflow top ASN tool? I recall using a text based netflow collector that would show me top destination ASNs. I recall it being really simple to get working too. But it's been some time since I used it and can't recall what it's called. Can someone give me a hint?
Sticky Bogons
a little help ... - Forwarded by Joe Loiacono/CIV/CSC on 01/11/2006 10:51 AM - Dong Yan dongyan @cnnic.cn Sent by: apnic-talk-bounces 01/09/2006 10:17 PM To: [EMAIL PROTECTED], [EMAIL PROTECTED] cc: Chen Tao [EMAIL PROTECTED], Xiangjian Li [EMAIL PROTECTED] Subject: Re: [apnic-talk] [Apnic-announce] APNIC new IPv4 addresses(121/8and122/7) The same issue from China. One of our member got a block /17 from 125/8, this block caused many web-accessing problems, which annoyed our member very much. This time, when they came back for subsequent IPv4 application, they pointed out clearly they do not want to get any block in 125/8 or even newer /8. Any doable suggestion and action from APNIC and all members in AP region will be helpfull. Dong Yan CNNIC - Original Message - From: Skeeve Stevens [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, January 09, 2006 5:08 PM Subject: RE: [apnic-talk] [Apnic-announce] APNIC new IPv4 addresses (121/8and122/7) Just an opinion... But as someone who is currently experiencing the pain of using a /19 in 125/8 at present and have our customers suffering greatly, I think APNIC needs to do something better to be approaching the bogon list managers and perhaps giving notice of 6 months or some such that these ranges will be used so the pain will be a lot less. ..Skeeve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Tran Sent: Monday, 9 January 2006 3:15 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [apnic-talk] [Apnic-announce] APNIC new IPv4 addresses (121/8 and122/7) Dear colleagues APNIC received IPv4 address blocks 121/8 and 122/7 from IANA in January 2006 and will be making allocations from these ranges in the near future. This announcement is being made for the information of the Internet community so that network configurations such as routing filters may be updated as appropriate. For more information on the resources administered by APNIC, see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, see: http://www.apnic.net/db/min-alloc.html Kind regards Son Resources Services Manager [EMAIL PROTECTED] Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 Helpdesk phone: +61 7 3858 3188 email: [EMAIL PROTECTED] Please send Internet Resource Requests to [EMAIL PROTECTED] _ ___ Apnic-announce mailing list [EMAIL PROTECTED] http://mailman.apnic.net/mailman/listinfo/apnic-announce ___ apnic-talk mailing list [EMAIL PROTECTED] http://mailman.apnic.net/mailman/listinfo/apnic-talk iBurst Wireless Broadband from $34.95/month www.platformnetworks.net Forward undetected SPAM to: [EMAIL PROTECTED] ___ apnic-talk mailing list [EMAIL PROTECTED] http://mailman.apnic.net/mailman/listinfo/apnic-talk ___ apnic-talk mailing list [EMAIL PROTECTED] http://mailman.apnic.net/mailman/listinfo/apnic-talk
Re: what will all you who work for private isp's be doing in a few years?
So imagine a residential area all pulling digital video over wireless. Sound familiar? Ironically close to TV! (yet so different) What I can't understand is why multicast hasn't just gone gangbusters into use yet. I see it as a really pent-up capability that, in light of broadband video, etc., is just going to have to break wide open soon. Joe Ross Hosman rosshosman To: Steve Sobol [EMAIL PROTECTED], Fred Heutte [EMAIL PROTECTED] @yahoo.com cc: [EMAIL PROTECTED] Sent by: Subject: Re: what will all you who work for private isp's be doing in a few years? owner-nanog 05/12/2005 02:16 PM Not pointing any fingers but many of you think these small ISP's are just going to die off instead of adapt. Wireless is becoming a better and more reliable technology that in the future will be able to provide faster service then FTTH. I know of atleast one small ISP in Michigan that went from dial-up to deploying wireless. With WiMAX coming out I think you will see a number of smaller ISPs switching to it as a service. It is also much cheaper to deploy a wireless network. Me personally, I think wireless is the future for residential internet/tv/phone. Ross Hosman Charter Communcations --- Steve Sobol [EMAIL PROTECTED] wrote: Fred Heutte wrote: (1) There will be a market for independent ISPs as long CLECs I think a more appropriate term would be ALEC (anti-competitive local exchange carrier) ...That having been said, the problem with the small guys providing access is they can't generally achieve the economies of scale that allow them to compete with the big guys. I'm on a Charter cablemodem, 3mbps down x 256kbps up, $39.95/month. Verizon is building out FTTH in this area and they're going to be offering 5x2 for $39.95 or 10x5 for $49.95, IIRC. Those are all residential prices, but Charter's actually pretty competitive on business rates too. And yes, there are people who value service over price, but the price differential is only going to get worse. -- JustThe.net - Apple Valley, CA - http://JustThe.net/ - 888.480.4NET (4638) Steven J. Sobol, Geek In Charge / [EMAIL PROTECTED] / PGP: 0xE3AE35ED The wisdom of a fool won't set you free --New Order, Bizarre Love Triangle
Re: Weekly Routing Table Report
Wha happen? Routing Table Report 04:00 +10GMT Sat 09 Apr, 2005 Analysis Summary BGP routing table entries examined: 139674 Prefixes after maximum aggregation: 83474 Unique aggregates announced to Internet: 67116 Total ASes present in the Internet Routing Table: 17729 Origin-only ASes present in the Internet Routing Table: 15381 Origin ASes announcing only one prefix:7282 Transit ASes present in the Internet Routing Table:2348 Transit-only ASes present in the Internet Routing Table:194 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 23 Prefixes from unregistered ASNs in the Routing Table:38 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space: 13 Number of addresses announced to Internet: 1212269440 Routing Table Report 04:00 +10GMT Sat 02 Apr, 2005 Analysis Summary BGP routing table entries examined: 158858 Prefixes after maximum aggregation: 92606 Unique aggregates announced to Internet: 76314 Total ASes present in the Internet Routing Table: 19277 Origin-only ASes present in the Internet Routing Table: 16774 Origin ASes announcing only one prefix:7827 Transit ASes present in the Internet Routing Table:2503 Transit-only ASes present in the Internet Routing Table: 68 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 23 Prefixes from unregistered ASNs in the Routing Table:31 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space: 13 Number of addresses announced to Internet: 1394234240 This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. Routing Table Analysis cscora To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], afnog@afnog.org @apnic.net cc: Sent by: Subject: Weekly Routing Table Report owner-nanog 04/08/2005 02:18 PM Please respond to pfs This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to [EMAIL PROTECTED] If you have any comments please contact Philip Smith [EMAIL PROTECTED]. Routing Table Report 04:00 +10GMT Sat 09 Apr, 2005 Analysis
Re: size of the routing table is a big deal, especially in IPv6
Please see an earlier write-up below. Will we run into IPv6 routing table problems without more formalized aggregation guidelines? The general guiding principal for the allocation of IPv6 address space is as follows: /48 in the general case, except for very large subscribers /64 when it is known that one and only one subnet is needed by design /128 when it is absolutely known that one and only one device is connecting The second-half of the IPv6 address (the last 64 bits) are generally reserved for the devices end-system identifier. Typically this is a Network Service Access Point (NSAP) identifier, or derived from the device's 48-bit IEEE 802 address padded up to 64 bits. A /64 network address then can hold 64 bits worth of devices. It is useful to look at /64s as if they were IPv4 Class C addresses, which are typically used for a single LAN or broadcast domain. A /48 has 16 bits worth (65,536) of Class C's then, which, if we continue the comparison, makes it the equivalent of an IPv4 Class A address. A /48 is generally considered the smallest routable prefix. A typical IPv6 address allocation (e.g., 200A:06D1::/32) holds 16 bits worth (65,535) of these /48 Class A's. The overall Aggregatable Global Unicast range (001::/3) holds 45 bits worth of routable networks. This clearly exceeds any router's capacity to accommodate a routing table of strictly /48s. Joe Loiacono
Re: animations from Making Sense of BGP talk available
Cool tool! It's amazing to see BGP in action and what 'really' happens. A comment: could you define the number of prefixes a little more? E.g., is it the total imported and exported across the link, imported only, exported only, context dependent, etc. Thanks! Joe Loiacono Van Jacobson van To: [EMAIL PROTECTED] @packetdesign.co cc: m Subject: animations from Making Sense of BGP talk available Sent by: owner-nanog 02/11/2004 02:14 AM The animations from Tina Wong's Making Sense of BGP talk at NANOG-30 this morning are available at: http://www.packetdesign.com/technology/presentations/nanog-30/index.htm The animations are in SVG (a W3C graphics standard) and should be viewable in any web browser but you'll probably have to download an SVG plugin first (there's a link to Adobe's free plugin at the top of the web page). If you play with the stuff, we'd welcome coments, suggestions, whatever. Thanks. - Tina, Cengiz Van
Re: PSINet/Cogent Latency
Actually RRDTool interpolates any late replys to the nearest specified collection timepoint (e.g., every 5th minute.) It doesn't really resample. Joe Matt ZimmermanTo: [EMAIL PROTECTED] mdz cc: @csh.rit.eduSubject: Re: PSINet/Cogent Latency Sent by: owner-nanog 07/23/2002 09:46 AM On Mon, Jul 22, 2002 at 10:50:03PM -0700, Doug Clements wrote: I think the problem with using rrdtool for billing purposes as described is that data can (and does) get lost. If your poller is a few cycles late, the burstable bandwidth measured goes up when the poller catches up to the interface counters. More bursting is bad for %ile (or good if you're selling it), and the customer won't like the fact that they're getting charged for artifically high measurements. RRDtool takes into account the time at which the sample was collected, and if it does not exactly match the expected sampling period, it is resampled on the fly. See: http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/tutorial/rrdtutorial.html under Data Resampling for more information. RRDtool has some quirks when used for billing purposes, but it is not guilty of the error that you describe. -- - mdz
