June 2011 - Test - lists.nanog.org

Invitation to connect on LinkedIn
by Yaoqing Liu via LinkedIn 30 Jun '11

30 Jun '11

LinkedIn ------------ Yaoqing Liu requested to add you as a connection on LinkedIn: ------------------------------------------ Ted, I'd like to add you to my professional network on LinkedIn. - Yaoqing Accept invitation from Yaoqing Liu http://www.linkedin.com/e/-voa23o-gpjv55fb-66/q0XU4EiXDUS2IbxL1NdPb3ZaZI/bl… View invitation from Yaoqing Liu http://www.linkedin.com/e/-voa23o-gpjv55fb-66/q0XU4EiXDUS2IbxL1NdPb3ZaZI/bl… ------------------------------------------ DID YOU KNOW you can showcase your professional knowledge on LinkedIn to receive job/consulting offers and enhance your professional reputation? Posting replies to questions on LinkedIn Answers puts you in front of the world's professional community. http://www.linkedin.com/e/-voa23o-gpjv55fb-66/abq/inv-24/ -- (c) 2011, LinkedIn Corporation

1 0

Invitation to connect on LinkedIn
by Yaoqing Liu via LinkedIn 30 Jun '11

30 Jun '11

LinkedIn ------------ Yaoqing Liu requested to add you as a connection on LinkedIn: ------------------------------------------ Ted, I'd like to add you to my professional network on LinkedIn. - Yaoqing Accept invitation from Yaoqing Liu http://www.linkedin.com/e/-voa23o-gpjunqoh-4g/q0XU4EiXDUS2IbxL1NdPb3ZaZI/bl… View invitation from Yaoqing Liu http://www.linkedin.com/e/-voa23o-gpjunqoh-4g/q0XU4EiXDUS2IbxL1NdPb3ZaZI/bl… ------------------------------------------ DID YOU KNOW you can showcase your professional knowledge on LinkedIn to receive job/consulting offers and enhance your professional reputation? Posting replies to questions on LinkedIn Answers puts you in front of the world's professional community. http://www.linkedin.com/e/-voa23o-gpjunqoh-4g/abq/inv-24/ -- (c) 2011, LinkedIn Corporation

1 0

[pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3)
by Eugen Leitl 29 Jun '11

29 Jun '11

----- Forwarded message from William Salt <williamejsalt(a)googlemail.com> ----- From: William Salt <williamejsalt(a)googlemail.com> Date: Tue, 28 Jun 2011 08:03:25 +0100 To: support(a)pfsense.com Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) Reply-To: support(a)pfsense.com Hi All, For the last couple of months i have been pulling my hair out trying to solve this problem. We have a 1Gbps transatlantic link from the UK to the US, which has successfully passed the RFC2544 test. At either end, we have a media converter, and a supermicro server with an intel quad port NIC running pfsense 2 (RC2 at one end RC3 at the other) and the IGB driver on the quad port. We can pass 1gbps either way with UDP. However we are experiencing very strange issues with tcp connections. With window scaling enabled, and a max socket buffer set to 16MB, we see no difference. Even disabling window scaling and setting the window to 16MB makes no difference. Each TCP connection starts very slowly, and will max out at around 190mbps, taking nearly 2 minutes to climb to this speed before *plateauing*. We have to initiate many (5+) connections to saturate the link with tcp connections with iperf. Real world tests transferring files, max out at 100mbps, using multiple connections. I have followed guides like this: http://www.psc.edu/networking/projects/tcptune/#FreeBSD With no luck, and have tweaked, disabled, and enabled nearly every relevant sysctl parameter with no luck. Can anyone shed some light on this? I am now doubting the IGB driver, and am looking to swap out the cards as a last ditch effort. However, we have tried different hardware (L3 switches, media convertes + laptops etc), and the symptoms still persist... The only constant is freebsd 8.1 - pfsense (or 8.2 for our production systems). I have tried the freebsd net mailinglist, but im hoping you lot can help me! Cheers in advance Will ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

15 25

Wacky Weekend: NERC to relax power grid frequency strictures
by Jay Ashworth 29 Jun '11

29 Jun '11

The North American Electric Reliability Council is planning to relax the standards for how closely power utilities must hold to 60.00Hz. Here's my absolute favorite quote of all time: Tweaking the power grid's frequency is expensive and takes a lot of effort, said Joe McClelland, head of electric reliability for the Federal Energy Regulatory Commission. "Is anyone using the grid to keep track of time?" McClelland said. "Let's see if anyone complains if we eliminate it." http://hosted.ap.org/dynamic/stories/U/US_SCI_POWER_CLOCKS?SITE=AP&SECTION=… I believe the answer to that question is contained here: http://yarchive.net/car/rv/generator_synchronization.html [1] This is gonna be fun, no? Cheers, -- jra [1]Please, let's not start in on the source.[2] [2]No, really: *please*. :-) -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

18 38

Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3)
by Eugen Leitl 29 Jun '11

29 Jun '11

----- Forwarded message from William Salt <williamejsalt(a)googlemail.com> ----- From: William Salt <williamejsalt(a)googlemail.com> Date: Wed, 29 Jun 2011 13:16:32 +0100 To: support(a)pfsense.com Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) Reply-To: support(a)pfsense.com Hi all, thanks for the input. We have now swapped the cards to em card at both ends, instead of igb at one end, and em at the other. We are now seeing near gig speeds in both directions. Before, we saw very different speeds in each direction. We have now managed to reach around 860-900mbps each way with the following values in our sysctl.conf: kern.ipc.maxsockbuf=20971520 net.inet.tcp.recvbuf_max=20971520 net.inet.tcp.sendbuf_max=20971520 net.inet.tcp.recvbuf_inc=524288 net.inet.tcp.sendbuf_inc=524288 However, even though we can reach around the upper threshold of the connection, we are seeing the boxes crash, or tcp performance hit the miximum 860-900mbps then drop, and stick at around 8mbps, until a reboot. I might add that we are running 32bit (i386) RC3 at both ends, with 6gb of ram.(probably alot less in the OS, need to upgrade to x64) When i replicated these settings on two fresh boxes beyong the routers at either end, i saw no performance increase... Regards Will On Tue, Jun 28, 2011 at 3:34 PM, Eugen Leitl <eugen(a)leitl.org> wrote: > > ----- Forwarded message from Rhys Rhaven <rhys(a)rhavenindustrys.com> ----- > > From: Rhys Rhaven <rhys(a)rhavenindustrys.com> > Date: Tue, 28 Jun 2011 09:30:06 -0500 > To: nanog(a)nanog.org > Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) > Organization: Rhaven Industrys > User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; > rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 > > Obviously not helping if you are trying to tune standard TCP, but I > lament that protocols like Tsunami are not in wider use. > http://tsunami-udp.sourceforge.net/ Short of it, a TCP control channel > takes care of error checking and resends while the data channel is a UDP > stream, specifically built to max out LFNs. > > On 06/28/2011 03:52 AM, Eugen Leitl wrote: > > ----- Forwarded message from William Salt <williamejsalt(a)googlemail.com> ----- > > > > From: William Salt <williamejsalt(a)googlemail.com> > > Date: Tue, 28 Jun 2011 08:03:25 +0100 > > To: support(a)pfsense.com > > Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) > > Reply-To: support(a)pfsense.com > > > > Hi All, > > For the last couple of months i have been pulling my hair out > > trying to solve this problem. > > We have a 1Gbps transatlantic link from the UK to the US, which has > > successfully passed the RFC2544 test. > > > > At either end, we have a media converter, and a supermicro server with an > > intel quad port NIC running pfsense 2 (RC2 at one end RC3 at the other) and > > the IGB driver on the quad port. > > > > We can pass 1gbps either way with UDP. However we are experiencing very > > strange issues with tcp connections. > > > > With window scaling enabled, and a max socket buffer set to 16MB, we see no > > difference. > > Even disabling window scaling and setting the window to 16MB makes no > > difference. > > > > Each TCP connection starts very slowly, and will max out at around 190mbps, > > taking nearly 2 minutes to climb to this speed before *plateauing*. > > > > We have to initiate many (5+) connections to saturate the link with tcp > > connections with iperf. > > > > Real world tests transferring files, max out at 100mbps, using multiple > > connections. > > > > I have followed guides like this: > > http://www.psc.edu/networking/projects/tcptune/#FreeBSD > > > > With no luck, and have tweaked, disabled, and enabled nearly every relevant > > sysctl parameter with no luck. > > > > Can anyone shed some light on this? > > > > I am now doubting the IGB driver, and am looking to swap out the cards as a > > last ditch effort. > > However, we have tried different hardware (L3 switches, media convertes + > > laptops etc), and the symptoms still persist... > > The only constant is freebsd 8.1 - pfsense (or 8.2 for our production > > systems). > > I have tried the freebsd net mailinglist, but im hoping you lot can help me! > > > > Cheers in advance > > Will > > > > ----- End forwarded message ----- > > > ----- End forwarded message ----- > -- > Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org > 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE > > --------------------------------------------------------------------- > To unsubscribe, e-mail: support-unsubscribe(a)pfsense.com > For additional commands, e-mail: support-help(a)pfsense.com > > Commercial support available - https://portal.pfsense.org > ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: NANOG Digest, Vol 41, Issue 165
by Savyasachi Choudhary 29 Jun '11

29 Jun '11

Hi, There is a command to limit the number of redistributed route. redistribute maximum-prefix Say, if ISIS imports routes, it will redistribute only the number of configured routes in 'redistribute maximum-prefix . My question is: say I make the number as 10. So initially ISIS will redistribute inly 10 routes recvd from say BGP, and drop other packets. But later, if I change the number to 20, how should it work? How will BGP send other routes? ' I think Huawei doed not have this command, but Cisco has Regards, Savyasachi 7676077879 On Wed, Jun 29, 2011 at 3:00 AM, <nanog-request(a)nanog.org> wrote: > Send NANOG mailing list submissions to > nanog(a)nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request(a)nanog.org > > You can reach the person managing the list at > nanog-owner(a)nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. RE: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) (Leigh Porter) > 2. Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) (Cameron Byrne) > 3. Re: Announcing Project BISMark: ISP Performance Measurements > from Home Routers (Daniel Espejel) > 4. Re: website in ipv6 (Kenny Sallee) > 5. Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) (PC) > 6. Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) (Cameron Byrne) > 7. DENOG 3 - Call for Participation and Papers (Marcus Stoegbauer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 28 Jun 2011 16:11:23 +0000 > From: Leigh Porter <leigh.porter(a)ukbroadband.com> > Subject: RE: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) > To: Cameron Byrne <cb.list6(a)gmail.com> > Cc: "williamejsalt(a)googlemail.com" <williamejsalt(a)googlemail.com>, > NANOG list <nanog(a)nanog.org> > Message-ID: > <D181DDABABE57E4DB72FEE0033147864075D66(a)EALPO1.ukbroadband.com> > Content-Type: text/plain; charset="us-ascii" > > > > > -----Original Message----- > > From: Cameron Byrne [mailto:cb.list6@gmail.com] > > Sent: 28 June 2011 16:53 > > To: Leigh Porter > > Cc: Andreas Ott; Eugen Leitl; williamejsalt(a)googlemail.com; NANOG list > > Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > > (+3) > > In the 3G world, i have had good results overcoming longish RTT by > > using the Hybla TCP algorithm http://hybla.deis.unibo.it/ > > > > I am hoping it gets more default traction, especially in wireless > > where the radio link is a pretty big latency source > > > > Cameron > > How do you implement this for lots of clients and servers that have out of > the box implementations? The FastSoft box is a TCP man-in-the-middle box > that essentially implements the FAST TCP algorithm without either end having > to worry about it. > > I have also used home-fudged TCP proxies with some success. > > Some 3G/wireless/VSAT vendors implement their own TCP modification stacks > but they usually only fiddle with window sizes and such. > > -- > Leigh > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > > ------------------------------ > > Message: 2 > Date: Tue, 28 Jun 2011 09:16:13 -0700 > From: Cameron Byrne <cb.list6(a)gmail.com> > Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) > To: Leigh Porter <leigh.porter(a)ukbroadband.com> > Cc: "williamejsalt(a)googlemail.com" <williamejsalt(a)googlemail.com>, > NANOG list <nanog(a)nanog.org> > Message-ID: > <BANLkTi=nbqdV+=ZUvLaiwy_ZHwS_fk79amzFXxYB-ca_MSt7ZA(a)mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > On Tue, Jun 28, 2011 at 9:11 AM, Leigh Porter > <leigh.porter(a)ukbroadband.com> wrote: > > > > > >> -----Original Message----- > >> From: Cameron Byrne [mailto:cb.list6@gmail.com] > >> Sent: 28 June 2011 16:53 > >> To: Leigh Porter > >> Cc: Andreas Ott; Eugen Leitl; williamejsalt(a)googlemail.com; NANOG list > >> Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > >> (+3) > >> In the 3G world, i have had good results overcoming longish RTT by > >> using the Hybla TCP algorithm ?http://hybla.deis.unibo.it/ > >> > >> I am hoping it gets more default traction, especially in wireless > >> where the radio link is a pretty big latency source > >> > >> Cameron > > > > How do you implement this for lots of clients and servers that have out > of the box implementations? The FastSoft box is a TCP man-in-the-middle box > that essentially implements the FAST TCP algorithm without either end having > to worry about it. > > > > You don't, the full benefits only come with a Linux kernel patch. The > good news is that it only has to be implemented on the client end. > > > I have also used home-fudged TCP proxies with some success. > > > > Some 3G/wireless/VSAT vendors implement their own TCP modification stacks > but they usually only fiddle with window sizes and such. > > > > That's why i said i hope it catches on as default :) If Android > implemented Hybla, i think it would be a great improvement for user > experience. Nobody likes the middleboxes that proxy TCP.... they cost > money, don't scale well, and are generally fragile. Hybla is not a > solution for the OPs issue, just a solution for high RTT links where > the client can do Hybla. It an evolutionary step that i think would > make a great fit in smartphones like Android. > > Cameron > > -- > > Leigh > > > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > ______________________________________________________________________ > > > > > > ------------------------------ > > Message: 3 > Date: Tue, 28 Jun 2011 12:50:29 -0500 > From: Daniel Espejel <daniel.unam.ipv6(a)gmail.com> > Subject: Re: Announcing Project BISMark: ISP Performance Measurements > from Home Routers > To: nanog(a)nanog.org > Message-ID: <BANLkTimbkG9CyN2PjiA7AECbok-V5Fenkw(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi. > > I would like to participate in the Bismark project, for now only as a > poller-kind user. > While checking the router n600 specifications datasheet it seems that this > device is IPv6 compliant in some degree (because of the IPv6 Ready Logo > included at the bottom of the sheet). > > I'm really interested in performing some test about that issue; but I'm > also > worried about privacy/confidentiality and navigation speed features. > > It's likely all those whom participate may find related information about > this topics in the project website and related mailing list. > > Well, I'm waiting to get my hands dirty on N600 and this way trying to > solve > some of my doubts (or catch a lot more). > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 28 Jun 2011 11:30:07 +0100 > > From: Alex Brooks <askoorb+nanog(a)gmail.com> > > Subject: Re: Announcing Project BISMark: ISP Performance Measurements > > from Home Routers > > To: nanog <nanog(a)nanog.org> > > Message-ID: <BANLkTikuyoBbOJotA3qrJQRDWjvd-cWWOA(a)mail.gmail.com> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > Hello, > > > > On Mon, Jun 27, 2011 at 9:48 PM, Nick Feamster <feamster(a)cc.gatech.edu> > > wrote: > > > > > > Hello NANOG, > > > > > > We've launched Project BISMark, a project that performs active > > performance measurements of upload and download throughput, latency, etc. > > from OpenWRT-based routers running inside of homes. ? We have tested our > > OpenWRT image on the NetGear WNDR 3700v2 and are currently shipping out > > NetGear routers with the BISMark firmware to anyone who is interested. > > > > > > > -- > *Daniel Espejel Perez > * > > > ------------------------------ > > Message: 4 > Date: Tue, 28 Jun 2011 11:09:04 -0700 > From: Kenny Sallee <kenny.sallee(a)gmail.com> > Subject: Re: website in ipv6 > To: Mark Andrews <marka(a)isc.org> > Cc: nanog list <nanog(a)nanog.org> > Message-ID: <BANLkTikt-7aRAXBYzUk0ao9V5DBeKz-0eg(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > > > > > > > > > > > I did this by creating a 6to4 tunnel to a relay provided by > > > > 6in4, not 6to4. While HE do operate 6to4 relays, the brokered tunnel > > service is 6in4. > > > > > A very important distinction I didn't have clear in my head. To > regurgitate > some reading I just completed: both methods use v6 in v4 tunneling using ip > proto 41 in the IPv4 protocol field. However, 6to4 derives the IPv4 tunnel > destination of an IPv6 packet based on bits 17-48 of the IPv6 packet - > which > when converted, equals the 32 bit IPv4 destination. While 6in4 is > statically configured IPv4 source and destination IP addresses on the > Tunnel > (gre) interface. In Cisco world the config comes down to 'tunnel mode > ipv6ip' vs 'tunnel mode ipv6ip 6to4' and a few other lines of config. > > Of course there are a lot more details then that searchable via google. > Thanks for pointing out my mistake - it helped me learn some more! Later, > Kenny > > > ------------------------------ > > Message: 5 > Date: Tue, 28 Jun 2011 14:24:59 -0600 > From: PC <paul4004(a)gmail.com> > Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) > To: Cameron Byrne <cb.list6(a)gmail.com> > Cc: "williamejsalt(a)googlemail.com" <williamejsalt(a)googlemail.com>, > NANOG list <nanog(a)nanog.org> > Message-ID: <BANLkTi=xzzwc_vj=cA+aZLpZ5=M_tgFaUA(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > I have found most/all modern 3g networks can achieve optimal download speed > within their latency limitations (<200ms domestic end-to-end is normal for > most today) when combined with a modern operating system that does > automatic > TCP receive window adjustments based on per-flow characteristics. I never > had a problem getting ~2 megabit from EVDO-revA, and can get ~20 megabit > without issue from the new Verizon LTE network. (Windows XP is not > modern). > > As for VSAT, most every vsat equipment manufacturer has TCP > acceleration/proxy support built into the satellite modem. They basically > forge acks at the hub site to buffer data from the server, then deliver it > it to the remote end in a continuous flow. Many also have protocol > optimizations for some of the more "chatty" protocols. If you use it, your > 10 megabit should be achievable for typical HTTP/FTP consumer internet > activities, and it's surprisingly fast. I've sustained 6 without issue on > VSAT, only limited by bandwidth available, doing a simple SCP file > transfer. > > Of course, none of this is to the scale of transatlantic gigabit transfers > with a single flow... > > > On Tue, Jun 28, 2011 at 10:16 AM, Cameron Byrne <cb.list6(a)gmail.com> > wrote: > > > On Tue, Jun 28, 2011 at 9:11 AM, Leigh Porter > > <leigh.porter(a)ukbroadband.com> wrote: > > > > > > > > >> -----Original Message----- > > >> From: Cameron Byrne [mailto:cb.list6@gmail.com] > > >> Sent: 28 June 2011 16:53 > > >> To: Leigh Porter > > >> Cc: Andreas Ott; Eugen Leitl; williamejsalt(a)googlemail.com; NANOG > list > > >> Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > > >> (+3) > > >> In the 3G world, i have had good results overcoming longish RTT by > > >> using the Hybla TCP algorithm http://hybla.deis.unibo.it/ > > >> > > >> I am hoping it gets more default traction, especially in wireless > > >> where the radio link is a pretty big latency source > > >> > > >> Cameron > > > > > > How do you implement this for lots of clients and servers that have out > > of the box implementations? The FastSoft box is a TCP man-in-the-middle > box > > that essentially implements the FAST TCP algorithm without either end > having > > to worry about it. > > > > > > > You don't, the full benefits only come with a Linux kernel patch. The > > good news is that it only has to be implemented on the client end. > > > > > I have also used home-fudged TCP proxies with some success. > > > > > > Some 3G/wireless/VSAT vendors implement their own TCP modification > stacks > > but they usually only fiddle with window sizes and such. > > > > > > > That's why i said i hope it catches on as default :) If Android > > implemented Hybla, i think it would be a great improvement for user > > experience. Nobody likes the middleboxes that proxy TCP.... they cost > > money, don't scale well, and are generally fragile. Hybla is not a > > solution for the OPs issue, just a solution for high RTT links where > > the client can do Hybla. It an evolutionary step that i think would > > make a great fit in smartphones like Android. > > > > Cameron > > > -- > > > Leigh > > > > > > > > > ______________________________________________________________________ > > > This email has been scanned by the MessageLabs Email Security System. > > > For more information please visit http://www.messagelabs.com/email > > > ______________________________________________________________________ > > > > > > > > > > ------------------------------ > > Message: 6 > Date: Tue, 28 Jun 2011 13:35:16 -0700 > From: Cameron Byrne <cb.list6(a)gmail.com> > Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) > To: PC <paul4004(a)gmail.com> > Cc: "williamejsalt(a)googlemail.com" <williamejsalt(a)googlemail.com>, > NANOG list <nanog(a)nanog.org> > Message-ID: > <BANLkTin4RBcVAZaz9kwoBouHmT1TBndkbQ_xc9E=OFFx4GEr5w(a)mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > On Tue, Jun 28, 2011 at 1:24 PM, PC <paul4004(a)gmail.com> wrote: > > I have found most/all modern 3g networks can achieve optimal download > speed > > within their latency limitations (<200ms domestic end-to-end is normal > for > > most today) when combined with a modern operating system that does > automatic > > TCP receive window adjustments based on per-flow characteristics.? I > never > > had a problem getting ~2 megabit from EVDO-revA, and can get ~20 megabit > > without issue from the new Verizon LTE network.? (Windows XP is not > modern). > > > > AFAIK, Verizon and all the other 4 largest mobile networks in the USA > have transparent TCP proxies in place. > > My point was that if end-hosts had Hybla or something similar, these > proxies can be removed providing a better end-to-end solution. > > Cameron > > > As for VSAT, most every vsat equipment manufacturer has TCP > > acceleration/proxy support built into the satellite modem.? They > basically > > forge acks at the hub site to buffer data from the server, then deliver > it > > it to the remote end in a continuous flow.? Many also have protocol > > optimizations for some of the more "chatty" protocols.? If you use it, > your > > 10 megabit should be achievable for typical HTTP/FTP consumer internet > > activities, and it's surprisingly fast.? I've sustained 6 without issue > on > > VSAT, only limited by bandwidth available, doing a simple SCP file > transfer. > > > > Of course, none of this is to the scale of transatlantic gigabit > transfers > > with a single flow... > > > > > > On Tue, Jun 28, 2011 at 10:16 AM, Cameron Byrne <cb.list6(a)gmail.com> > wrote: > >> > >> On Tue, Jun 28, 2011 at 9:11 AM, Leigh Porter > >> <leigh.porter(a)ukbroadband.com> wrote: > >> > > >> > > >> >> -----Original Message----- > >> >> From: Cameron Byrne [mailto:cb.list6@gmail.com] > >> >> Sent: 28 June 2011 16:53 > >> >> To: Leigh Porter > >> >> Cc: Andreas Ott; Eugen Leitl; williamejsalt(a)googlemail.com; NANOG > list > >> >> Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 > RC2 > >> >> (+3) > >> >> In the 3G world, i have had good results overcoming longish RTT by > >> >> using the Hybla TCP algorithm ?http://hybla.deis.unibo.it/ > >> >> > >> >> I am hoping it gets more default traction, especially in wireless > >> >> where the radio link is a pretty big latency source > >> >> > >> >> Cameron > >> > > >> > How do you implement this for lots of clients and servers that have > out > >> > of the box implementations? The FastSoft box is a TCP > man-in-the-middle box > >> > that essentially implements the FAST TCP algorithm without either end > having > >> > to worry about it. > >> > > >> > >> You don't, the full benefits only come with a Linux kernel patch. ?The > >> good news is that it only has to be implemented on the client end. > >> > >> > I have also used home-fudged TCP proxies with some success. > >> > > >> > Some 3G/wireless/VSAT vendors implement their own TCP modification > >> > stacks but they usually only fiddle with window sizes and such. > >> > > >> > >> That's why i said i hope it catches on as default :) ?If Android > >> implemented Hybla, i think it would be a great improvement for user > >> experience. ?Nobody likes the middleboxes that proxy TCP.... they cost > >> money, don't scale well, and are generally fragile. ?Hybla is not a > >> solution for the OPs issue, just a solution for high RTT links where > >> the client can do Hybla. ?It an evolutionary step that i think would > >> make a great fit in smartphones like Android. > >> > >> Cameron > >> > -- > >> > Leigh > >> > > >> > > >> > ______________________________________________________________________ > >> > This email has been scanned by the MessageLabs Email Security System. > >> > For more information please visit http://www.messagelabs.com/email > >> > ______________________________________________________________________ > >> > > >> > > > > > > > > ------------------------------ > > Message: 7 > Date: Tue, 28 Jun 2011 23:30:19 +0200 > From: Marcus Stoegbauer <marcus(a)grmpf.org> > Subject: DENOG 3 - Call for Participation and Papers > To: nanog(a)nanog.org > Message-ID: <4E0A47EB.5060808(a)grmpf.org> > Content-Type: text/plain; charset=UTF-8 > > DENOG 3 - Call for Participation and Papers > > The third meeting of the German Network Operators Group (DENOG) will be > held in Frankfurt, Germany on the 20th of October 2011. We are pleased > to hereby invite applications for presentations or lightning talks to be > held at this event. > > General Information > =================== > DENOG is a community for professionals within Germany who are operating, > designing or researching the Internet. It provides a technical forum > where those working on, with and for the Internet can come together to > solve problems with every aspect of their (net)work. > > The meeting is designed to provide an opportunity for the exchange of > information among network operators, engineers, researchers and other > professionals close to the network community. > > More information about DENOG (in German) can be found at > http://www.denog.de/ > Information about the meeting will be published at > http://www.denog.de/meetings/ > > > Meeting Countdown > ================= > What When > ------------------------------------------------------ > Publication of Call for Papers June 28th, 2011 > Deadline for all submissions August 22th, 2011 > Publication of final programme September 3rd, 2011 > Deadline for receipt of final slides October 13th, 2011 > Meeting Day October 20th, 2011 > > Topics for Presentations/Talks > ============================== > The day will be divided into several sessions. The number and length of > presentations per session is not fixed, although due to time constraints > we would prefer the length of the presentations to be between 10 to 30 > minutes. > > However proposals whose subject fall outside of the topics below are > also welcome; please do not hesitate to submit them. > > Lightning Talks > --------------- > In addition to the topics mentioned below we will reserve slots for > lightning talks, which consist of a few slides and will not last longer > than 5 minutes. Lightning talks can be submitted until October 13th, > with the deadline for submission of the corresponding slides being > October 19th. > > Topic #1: Power Efficiency in Networks > --------------------------------------- > For operators of networks and data centres of any size power efficiency > has become more important. Servers and network gear with high power > consumption are expensive because of high operating and cooling power > costs; also in many places supplying more power into the location is no > longer possible. How are you dealing with power problems in your > environment? How do you efficiently cool a rack/a room/a datacenter? Can > a migration to VoIP help you save power? > > Topic #2: Social Networks, Cloud Services and Information Security > ------------------------------------------------------------------ > Social Networks are an essential working tool for networkers and cloud > services are also becoming increasingly popular. The security of your > information and data in these networks is a crucial aspect which we want > to discuss in this session. > > Topic #3: Peering > ------------------ > Everything about your peering experience. Why are you doing it? How are > you doing it? Have you written any useful tools which others might find > interesting? > > Topic #4: ISP BOF > ----------------- > "All things ISP". From Network/SLA Management (for or against it), abuse > handling and log systems to data centre layout and planning (including > power and cooling), everything that is interesting to you as an ISP can > be presented or discussed within this topic. > > Language of Slides and Talks > ============================ > To appeal to an international audience we ask you to produce your slides > in English, but the spoken language of the presentation itself can be > either German or English. > > Submission Guidelines > ===================== > All submissions must have a strong technical bias and must not be solely > promotional for your employer. > > Please remember that your presentations should be suitable for a target > audience of technicians from varied backgrounds, working for companies > whose sizes may vary considerably. > > To submit a proposal for a presentation, we request that you provide the > following information as plain text or PDF format to <denog-pc(a)denog.de>: > > * the name of the presenter (and if applicable your affiliation) > * a working email address > * the name and number of the topic which will contain the presentation > * the title of the presentation > * its expected length (in minutes) > * the preferred spoken language for the presentation > * a short abstract of the presentation (not more than 200 words) > > We also welcome suggestions for specific presentations which you feel > would be valuable to the DENOG community. > > Please be aware that your presentation will be published on the DENOG > website after the event. > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG(a)nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 41, Issue 165 > ************************************** >

1 0

website in ipv6
by Deric Kwok 29 Jun '11

29 Jun '11

Hi all I am trying to configure website for testing ipv6 Just wander how internet users eg: DSL users can visit this website and any people can access this website over the world Thank you

6 11

DENOG 3 - Call for Participation and Papers
by Marcus Stoegbauer 28 Jun '11

28 Jun '11

DENOG 3 - Call for Participation and Papers The third meeting of the German Network Operators Group (DENOG) will be held in Frankfurt, Germany on the 20th of October 2011. We are pleased to hereby invite applications for presentations or lightning talks to be held at this event. General Information =================== DENOG is a community for professionals within Germany who are operating, designing or researching the Internet. It provides a technical forum where those working on, with and for the Internet can come together to solve problems with every aspect of their (net)work. The meeting is designed to provide an opportunity for the exchange of information among network operators, engineers, researchers and other professionals close to the network community. More information about DENOG (in German) can be found at http://www.denog.de/ Information about the meeting will be published at http://www.denog.de/meetings/ Meeting Countdown ================= What When ------------------------------------------------------ Publication of Call for Papers June 28th, 2011 Deadline for all submissions August 22th, 2011 Publication of final programme September 3rd, 2011 Deadline for receipt of final slides October 13th, 2011 Meeting Day October 20th, 2011 Topics for Presentations/Talks ============================== The day will be divided into several sessions. The number and length of presentations per session is not fixed, although due to time constraints we would prefer the length of the presentations to be between 10 to 30 minutes. However proposals whose subject fall outside of the topics below are also welcome; please do not hesitate to submit them. Lightning Talks --------------- In addition to the topics mentioned below we will reserve slots for lightning talks, which consist of a few slides and will not last longer than 5 minutes. Lightning talks can be submitted until October 13th, with the deadline for submission of the corresponding slides being October 19th. Topic #1: Power Efficiency in Networks --------------------------------------- For operators of networks and data centres of any size power efficiency has become more important. Servers and network gear with high power consumption are expensive because of high operating and cooling power costs; also in many places supplying more power into the location is no longer possible. How are you dealing with power problems in your environment? How do you efficiently cool a rack/a room/a datacenter? Can a migration to VoIP help you save power? Topic #2: Social Networks, Cloud Services and Information Security ------------------------------------------------------------------ Social Networks are an essential working tool for networkers and cloud services are also becoming increasingly popular. The security of your information and data in these networks is a crucial aspect which we want to discuss in this session. Topic #3: Peering ------------------ Everything about your peering experience. Why are you doing it? How are you doing it? Have you written any useful tools which others might find interesting? Topic #4: ISP BOF ----------------- "All things ISP". From Network/SLA Management (for or against it), abuse handling and log systems to data centre layout and planning (including power and cooling), everything that is interesting to you as an ISP can be presented or discussed within this topic. Language of Slides and Talks ============================ To appeal to an international audience we ask you to produce your slides in English, but the spoken language of the presentation itself can be either German or English. Submission Guidelines ===================== All submissions must have a strong technical bias and must not be solely promotional for your employer. Please remember that your presentations should be suitable for a target audience of technicians from varied backgrounds, working for companies whose sizes may vary considerably. To submit a proposal for a presentation, we request that you provide the following information as plain text or PDF format to <denog-pc(a)denog.de>: * the name of the presenter (and if applicable your affiliation) * a working email address * the name and number of the topic which will contain the presentation * the title of the presentation * its expected length (in minutes) * the preferred spoken language for the presentation * a short abstract of the presentation (not more than 200 words) We also welcome suggestions for specific presentations which you feel would be valuable to the DENOG community. Please be aware that your presentation will be published on the DENOG website after the event.

1 0

Re: Announcing Project BISMark: ISP Performance Measurements from Home Routers
by Daniel Espejel 28 Jun '11

28 Jun '11

Hi. I would like to participate in the Bismark project, for now only as a poller-kind user. While checking the router n600 specifications datasheet it seems that this device is IPv6 compliant in some degree (because of the IPv6 Ready Logo included at the bottom of the sheet). I'm really interested in performing some test about that issue; but I'm also worried about privacy/confidentiality and navigation speed features. It's likely all those whom participate may find related information about this topics in the project website and related mailing list. Well, I'm waiting to get my hands dirty on N600 and this way trying to solve some of my doubts (or catch a lot more). > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 28 Jun 2011 11:30:07 +0100 > From: Alex Brooks <askoorb+nanog(a)gmail.com> > Subject: Re: Announcing Project BISMark: ISP Performance Measurements > from Home Routers > To: nanog <nanog(a)nanog.org> > Message-ID: <BANLkTikuyoBbOJotA3qrJQRDWjvd-cWWOA(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hello, > > On Mon, Jun 27, 2011 at 9:48 PM, Nick Feamster <feamster(a)cc.gatech.edu> > wrote: > > > > Hello NANOG, > > > > We've launched Project BISMark, a project that performs active > performance measurements of upload and download throughput, latency, etc. > from OpenWRT-based routers running inside of homes. ? We have tested our > OpenWRT image on the NetGear WNDR 3700v2 and are currently shipping out > NetGear routers with the BISMark firmware to anyone who is interested. > > > -- *Daniel Espejel Perez *

1 0

Announcing BRITE - BGPSEC / RPKI Interoperability Test & Evaluation system
by Montgomery, Douglas 28 Jun '11

28 Jun '11

BRITE is a web-based test and evaluation framework for exercising implementations, configurations and deployments of emerging IETF BGP security technologies, including some components of the Resource Public Key Infrastructure (RPKI) and routers that support BGP security extensions. BRITE is currently capable of testing: RPKI validation caches and BGP routers that perform origin validation based upon RPKI ROAs. Future extensions will support BGP routers that support full path validation. BRITE currently supports the following capabilities / protocol interfaces: * rsync of RPKI objects from BRITE test suite repositories, * RPKI/Router Protocol (draft-ietf-sidr-rpki-rtr-12 - TCP plain sockets, no SSH transport or TCP-AO) * BGP-4 (tested interoperability with Cisco IOS, JUNOS, Quagga, OpenBGPD and BIRD) BRITE is driven by test scripts that describe carefully crafted Test Scenarios (stimulus inputs from BRITE using the protocols above) and corresponding goals (expected responses from the Implementation Under Test (IUT) using the protocols above). BRITE allows users to login, select a specific test case, interactively configure and run the test case and then browse/download detailed test reports, packet captures and log files. Current test scripts & data sets are available for: * BGP routers that implement the rpki-rtr protocol and simple BGP origin validation route policies. Additional test suites & data sets are in development and will be announced when available. To get additional information, browse existing test suites, or use the BRITE system, goto: http://brite.antd.nist.gov/ Questions or comments can be directed to brite-dev(a)nist.gov. dougm -- Doug Montgomery Mgr. Internet & Scalable Systems Research / ITL / NIST

1 0