September 2010 - Test - lists.nanog.org

Re: Did Internet Founders Actually Anticipate Paid,
by Robert Bonomi 20 Sep '10

20 Sep '10

> From nanog-bounces+bonomi=mail.r-bonomi.com(a)nanog.org Mon Sep 20 13:24:42 2010 > From: William Herrin <bill(a)herrin.us> > Date: Mon, 20 Sep 2010 14:25:31 -0400 > Subject: Re: Did Internet Founders Actually Anticipate Paid, > To: Justin Horstman <justin.horstman(a)gorillanation.com> > Cc: NANOG <nanog(a)nanog.org> > > On Mon, Sep 20, 2010 at 2:08 PM, Justin Horstman > <justin.horstman(a)gorillanation.com> wrote: > > Devil's Advocate here, > > > > What would you say to ISP A that provided similar > > speeds as ISP B, but B took payments from content > > providers and then provided the service for free? > > > > Gives you the choice, ISP A, which costs, and ISP B, > > which is free, and most people wouldn't know the difference. > > Justin, > > I'd say ISP B was incorrectly described. He doesn't provide service > for free; he merely has a different customer. In ISP A, the end user > is the customer but in ISP B, he isn't. I'm tempted to point out that there have been severl attempts at the ISP B model. None of which are still in existance. I take that back, one or two of them may still exist, but they're not using that business model any more.

1 0

Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
by msokolov＠ivan.Harhan.ORG 20 Sep '10

20 Sep '10

Leo Bicknell <bicknell(a)ufp.org> wrote: > Part of the reason for this is "U-Verse" is FTTN, Fiber to the Node. > AT&T 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 AT&T 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 (AT&T) 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

2 1

Specifications for Internet services on public frequency
by Georges-Keny PAUL 20 Sep '10

20 Sep '10

Hello all, My team is working on technical and technological specifications of a document for the deployment of Internet service on public frequencies in rural areas. We welcome your thoughts on the topic in terms of previous experiences and, well sure, you recommendation in terms of equipment. You should note that the environment in question is very mountainous with very precarious infrastructure conditions: no electricity, poor access, etc. We would like to deploy a service at minimal cost, using mainly open source software. All comments, suggestions, recommendations, draft, success stories are well come. Feel free to contact me for additional information. Warms regards, Georges-Keny PAUL

6 5

Da Shi wants to stay in touch on LinkedIn
by Da Shi 19 Sep '10

19 Sep '10

LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Da Shi Da Shi Managing Director at 3z Canada Toronto, Canada Area Confirm that you know Da Shi https://www.linkedin.com/e/-voa23o-geaggbx4-2z/isd/1686347474/EeHY08Xk/ -- (c) 2010, LinkedIn Corporation

1 0

Re: Nevis Internet
by Rudolph Daniel 19 Sep '10

19 Sep '10

Very interesting Randy, this sounds like what we endure on a regular basis in the eastern Caribbean....I too would like to know why myself since I have always wondered whether our local networks are set up. Rudi Daniel > From: Randy Bush <randy(a)psg.com> > Subject: very strange internet behavior > To: customersupport(a)caribcable.com > Date: Sun, 19 Sep 2010 04:14:08 -0400 > > [ this needs to be escalated to an internet engineer ] > > hi, > > i am an old senior internet geek vacationing on nevis's nesbit beach. > the cottage has your tv and internet service. > > during what i suspect are the busy hours of the day, your internet > service borders on useless. it is as if an overloaded NAT is in the > middle. one can reach very few web sites. one can reach (ping, ssh, > ...) some hosts and not others. and the hosts are in the same rack and > same ip address space in a stateside colo. one can ping a host but not > ssh to it. or i can be sshed into a host and yet not be able to ping > it. very twisty stuff. > > if i turn on the tv, the cable seems to be working. > > i can run an openvpn tunnel to a stateside or japan-based host and then > everything is reachable. of course i have to try three or four of my > openvpn serving hosts before i find one which is reachable. this is not > a great solution, and certainly not one available to the vast majority > of your customers. > > from an engineer's point of view, i would love to understand what the > cause of all this really is. > > randy > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG(a)nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 32, Issue 62 > ************************************* > -- Rudi Daniel *danielcharles <http://goog_470770575>* consulting <http://goog_470770575>*ICT4Dev & e Business and services<http://goog_470770575> * <http://goog_470770575>*1-784 498 8277 <http://goog_470770575>* ** <http://goog_470770575>*h <http://csisvg.ning.com>ttp://csisvg.ning.com *

2 1

caribbean cable ip contact
by Randy Bush 19 Sep '10

19 Sep '10

if a clued engineer at caribbean cable happens to read this message, i would be thankful if they contacted me privately. thank you. randy -- From: Randy Bush <randy(a)psg.com> Subject: very strange internet behavior To: customersupport(a)caribcable.com Date: Sun, 19 Sep 2010 04:14:08 -0400 [ this needs to be escalated to an internet engineer ] hi, i am an old senior internet geek vacationing on nevis's nesbit beach. the cottage has your tv and internet service. during what i suspect are the busy hours of the day, your internet service borders on useless. it is as if an overloaded NAT is in the middle. one can reach very few web sites. one can reach (ping, ssh, ...) some hosts and not others. and the hosts are in the same rack and same ip address space in a stateside colo. one can ping a host but not ssh to it. or i can be sshed into a host and yet not be able to ping it. very twisty stuff. if i turn on the tv, the cable seems to be working. i can run an openvpn tunnel to a stateside or japan-based host and then everything is reachable. of course i have to try three or four of my openvpn serving hosts before i find one which is reachable. this is not a great solution, and certainly not one available to the vast majority of your customers. from an engineer's point of view, i would love to understand what the cause of all this really is. randy

1 0

Troubleshooting TCP performance tutorial
by Abel Alejandro 18 Sep '10

18 Sep '10

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.

6 6

Re: Specifications for Internet services on public frequency
by Georges-Keny PAUL 18 Sep '10

18 Sep '10

Eric, Thanks for your reply. We're located in Haiti (Caribbean), we use basically the same template than rural S. America and Africa. I'm waiting for you. Regards, Georges-Keny PAUL 2010/9/18 Eric Brunner-Williams <brunner(a)nic-naa.net> > Georges-Keny, > > Well, I wrote a WiMAX based BTOP application last year for rural Maine. It > didn't get a dime but I had a bit to think about. Put me in your co-think'um > mailing list since NANOG won't be a place for long discussion or rural > service. There's interesting wireless work done in rural S. America and > Africa to keep abreast of as well. > > Eric >

1 0

TCP Performance (NANOG Digest, Vol 32, Issue 60)
by DMFH 18 Sep '10

18 Sep '10

Sat, 18 Sep 2010 09:34:55 +0000 nanog-request(a)nanog.org fuream loqour : >From: "Abel Alejandro" <aalejandro(a)worldnetpr.com> >Subject: Troubleshooting TCP performance tutorial > >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, Walking through the layers, if L2 checks out, & UDP checks out, but TCP does not, you might have a problem "up the stack", @ L4 with TCP. I don't know your test rig / setup, but a few ideas come to mind: - Mismatch in the TCP personality between the hosts - mixing Windows & some UNIX OS flavors, like Sun Solaris 2.8 or others can produce incredible degradation in streaming TCP performance either due to buggy TCP behavior, or one TCP stack supports options the other doesn't, like one side is doing Classic Reno TCP (max 64K) window, doesn't respect or process RFC1323 window-sizing options, but the other side does. It happens UNIX-to-UNIX too, and embedded devices usually don't have robust TCP/IP stacks as well (like hand-held barcode readers, etc.). Any client patch an OS recently? - Someone is doing QoS of some type either expressly or indirectly by effect. Stream / test TCP on multiple ports / sockets to multiple hosts, different OS combinations, or a known good combination - Knoppix Linux boot CD's are great for this kind of thing - send them to a client, pop 'em in, do some testing - once built a test CD for this, fun, gets rid of that long "troubleshoot loop". - MTU / other issue? Did your UDP stream pack full-size payloads? If not, walk up the size of the test packets to the maximum, see what happens. If it breaks somewhere, you have the beginning of an answer, etc. - Not thinking it's the client app since you mentioned you've run a whole set of TCP-based tests. /dmfh -- __| |_ __ / _| |_ 01100100 01101101 / _` | ' \| _| ' \ 01100110 01101000 \__,_|_|_|_|_| |_||_| dmfh(-2)dmfh.cx

1 0

Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
by msokolov＠ivan.Harhan.ORG 18 Sep '10

18 Sep '10

Leo Bicknell <bicknell(a)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 AT&T 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 AT&T ADSL network at Layer 2 (ATM) and provide their own IP layer? MS

5 5