October 2007 - Test - lists.nanog.org

Re: BitTorrent swarms have a deadly bite on broadband nets
by Tim Franklin 24 Oct '07

24 Oct '07

On Tue, October 23, 2007 5:17 pm, Jack Bates wrote: > Sorry, I am the incumbent. ;) I was just thinking of the copper necessary > to do such a task on a massive scale. It's definitely not in the ground > or on a pole at this point in time. One reason DSL was so desireable for > many small ILECs was the recovery of copper from dual phone lines caused > by dialup. Oops - hope I didn't say anything *too* offensive ;) And thanks for the perspective from the "other side". Regards, Tim.

1 0

Re: Misguided SPAM Filtering techniques
by Owen DeLong 24 Oct '07

24 Oct '07

On Oct 23, 2007, at 1:48 PM, Christopher Morrow wrote: > On 10/23/07, Jack Bates <jbates(a)brightok.net> wrote: >> I really don't get it. While I understand with tcp/25 blocking, >> there is >> absolutely no reason to block tcp/587. If credential's are being >> hijacked, it is > > morrowc$ telnet mail.ops-netman.net 26 > Trying 71.246.230.124... > Connected to mail.ops-netman.net. > Escape character is '^]'. > 220 A host is a host from coast to coast... Hosty-host ESMTP... > > why don't people just run a new version of their MTA on a port > not-filtered?? The simple fact is that port-25 filtering does help, it > does also seem to piss off some portion of 'smart folks' (power users, > whatever you choose to call them). So, being smart, just work your > box(es) such that this isn't a problem for you? > I want to make it clear... I don't mind people filtering either 25 or 587, but, blocking both is highly unacceptable. Even more unacceptable in my opinion is hijacking connections to either off to your own man-in-the-middle attack server. Owen

5 5

Internet infrastructure - recovery planning
by Jared Mauch 23 Oct '07

23 Oct '07

Anyone else read this GAO report yet:? http://www.gao.gov/new.items/d08212t.pdf As a service provider were you interviewed by GAO? Just curious. - Jared -- Jared Mauch | pgp key available via finger from jared(a)puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

3 2

Fw: WG Action: Conclusion of IP Version 6 (ipv6)
by Steven M. Bellovin 23 Oct '07

23 Oct '07

The subject line is amazing... Begin forwarded message: Date: Tue, 25 Sep 2007 14:30:02 -0400 From: IESG Secretary <iesg-secretary(a)ietf.org> To: ietf-announce(a)ietf.org Cc: Robert Hinden <bob.hinden(a)nokia.com>, Brian Haberman <brian(a)innovationslab.net>, ipv6(a)ietf.org Subject: WG Action: Conclusion of IP Version 6 (ipv6) The IP Version 6 Working Group (ipv6) in the Internet Area has concluded. The IESG contact persons are Jari Arkko and Mark Townsley. +++ A new Working Group, 6MAN, has been created to deal with maintenance issues arising in IPv6 specifications. The IPv6 WG is closed. This is an important milestone for IPv6, marking the official closing of the IPv6 development effort. The ADs would like to thank everyone -- chairs, authors, editors, contributors -- who has been involved in the effort over the years. The IPv6 working group and its predecessor, IPNGWG, produced 79 RFCs (including 5 in the RFC queue). Issues relating to IPv6 should in the future be taken up in 6MAN if they relate to problems discovered during implementation or deployment; V6OPS if they relate to operational issues; BOF proposals, individual submissions etc. for new functionality. The mailing list of the IPv6 WG stays alive; the list will still be used by the 6MAN WG in order to avoid people having to resubscribe and/or adjust their mail filters. _______________________________________________ IETF-Announce mailing list IETF-Announce(a)ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --Steve Bellovin, http://www.cs.columbia.edu/~smb

33 127

Misguided SPAM Filtering techniques
by Owen DeLong 23 Oct '07

23 Oct '07

I'm seeing an increasing variety of misguided SPAM blocking techniques such that they are starting to become more and more annoying, and, I'm curious as to what solutions/work-arounds others have deployed, and, if anyone has any ideas on how to get these tactics reduced/stopped? Here's the primary hinderance. I use an authenticated TLS-protected mailhost at home for submitting my email for delivery. Unfortunately, networks have taken to: outright blocking 25 and 587 except to their own servers. proxying all 25/587 connections in a manner incompatible with TLS proxying all 25/587 connections in a manner incompatible with SMTPAUTH blocking TLS startup on 25/587 connections Primarily, I have run up against this in the following networks: SPRINT Cellular network (can no longer send email from my phone) Public wireless networks Hotel networks Other WiFi hotspots Some DSL providers networks I can't imagine that these tactics actually do anything to significantly reduce the amount of spam delivered to the internet, so, I'm curious as to: 1. Why are they used? 2. How do we convince operators to abandon them? 3. How prevalent is this problem, and, is it growing as I perceive? Owen

17 27

Re: BitTorrent swarms have a deadly bite on broadband nets
by Tim Franklin 23 Oct '07

23 Oct '07

On Tue, October 23, 2007 4:06 pm, Jack Bates wrote: > Errr, 8 pairs per customer? Even 4 is a step backwards. If we're going to > do construction at that level, might as well drop in fiber. We're still > enjoying the fact that ADSL runs on 1/2 a pair while the customer's > phone service is out. Doing (or getting the incumbent to do, where the last mile is a monopoly) a little bit more of what you already do seems to be an awful lot easier than doing something completely different. Certainly in the (admittedly all European) countries where I've seen it done, getting 4 or 8 copper pairs from a customer site to the exchange is an order of magnitude or more difference in both cost and lead time to doing anything at all with fibre. Every house I've lived in has had 4 pairs already going from the house to the first street cabinet, with just the first pair connected for voice, and getting a second line has always just needed a patch onto a spare pair from the cab to the exchange. Obviously if *everyone* wants 4 or 8 pairs to their house, there's going to need to be a lot more copper between the exchange and the street cabs. It's not clear that *everyone* wants upstream though, and 2M to 5M on a single pair (depending on distance / quality) is quite possible if you wanted to think in terms of ubiquitous symmetric service. I take it that getting spare / new copper in the US is more painful? Regards, Tim.

2 1

New NANOG Programme Committee
by Philip Smith 23 Oct '07

23 Oct '07

In its last scheduled meeting, the NANOG Steering Committee selected a new Programme Committee. With sixteen very well-qualified new candidates, and nine open positions, it was a difficult decision to make. The SC, with input from the current PC and the community, felt it necessary to form a balanced PC, with a diversity of backgrounds, knowledge, and experience, and one that is representative of the entire NANOG constituency. The SC would like to thank outgoing PC members Steve Feldman, Dan Golding, Pete Templin and Vish Yelsangikar for their valuable contributions to the PC. In particular the SC would like to acknowledge Steve's service as NANOG PC Chair. Additionally, the SC is grateful to the seven candidates who volunteered their time but who weren't selected this time round. We hope they will all consider volunteering again next time. The NANOG Programme Committee for 2007/2008 is as follows: Existing members: Igor Gashinsky Kobi Hsu Mike Hughes Keith Mitchell Ted Seely Richard Steenbergen Bill Woodcock New (or returning) members: Nick Feamster Joel Jaeggli Rodney Joffe Sylvie LaPerriere Kevin Oberman Lane Patterson Ren Provo Josh Snowhorn Todd Underwood With Steve Feldman's election to the NANOG SC, the one year remaining of his term on the PC needed to be filled. Therefore Nick Feamster will serve a one year term on the PC; the remaining new members will serve a two year term. Philip Smith SC Chair

1 0

Re: BitTorrent swarms have a deadly bite on broadband nets
by Tim Franklin 23 Oct '07

23 Oct '07

On Tue, October 23, 2007 2:55 am, Leo Bicknell wrote: > 3) Is there any chance US providers could offer similar technologies at > similar prices, or are there significant differences (regulation, > distance etc) that prevent it from being viable? For the UK (and NL), on the tech side we're seeing some success with EFM on copper, in this particular case on an Actelis platform. It's a new unit in the CO, from 1-8 pairs from the CO to the customer premises, up to a total bandwidth across all pairs of 40Mb/s in each direction. (Admittedly 40Mb/s is 8 pairs at something like 1km from the exchange, but I'm seeing some useful 6-10M symmetric services on 4 or so pairs). Upstream from the CO box is FE or GE, either a VLAN or multiple double-tagged VLANs per customer, so if you want to offer uncontended, you just have to get enough backhaul from the CO to cope with all your customers. This is still running in the tromboning, everything-is-backhauled model, but there's no technical reason why you couldn't put a switch or router in the CO to keep local traffic local. (I'm mostly using this for VPN access circuits, so there's rarely traffic between sites on the same CO, but if you were rolling it out large-scale for Internet, it might make sense). It *is* nice though in that Ethernet frames go in, Ethernet frames come out - no need for fancy router interfaces, nasty PPPoSomething nonsense, or anything similar - it looks to the networking equipment on both ends like a long piece of Cat5. How you market "less downstream, more upstream" to customers (assuming you're getting more like the 10M symmetric, not 40M), and how you make all this happen for $40, I'm not so sure... Regards, Tim.

2 1

The next broadband killer: advanced operating systems?
by Leo Bicknell 23 Oct '07

23 Oct '07

Windows Vista, and next week Mac OS X Leopard introduced a significant improvement to the TCP stack, Window Auto-Tuning. FreeBSD is committing TCP Socket Buffer Auto-Sizing in FreeBSD 7. I've also been told similar features are in the 2.6 Kernel used by several popular Linux distributions. Today a large number of consumer / web server combinations are limited to a 32k window size, which on a 60ms link across the country limits the speed of a single TCP connection to 533kbytes/sec, or 4.2Mbits/sec. Users with 6 and 8 MBps broadband connections can't even fill their pipe on a software download. With these improvements in both clients and servers soon these systems may auto-tune to fill 100Mbps (or larger) pipes. Related to our current discussion of bittorrent clients as much as they are "unfair" by trying to use the entire pipe, will these auto-tuning improvements create the same situation? -- Leo Bicknell - bicknell(a)ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request(a)tmbg.org, www.tmbg.org

7 10

Re: BitTorrent swarms have a deadly bite on broadband nets
by Adrian Chadd 23 Oct '07

23 Oct '07

On Tue, Oct 23, 2007, Brandon Galbraith wrote: > I believe the bittorrent client Azureus actually does prioritize based on > subnet, picking local subnet hosts first (such as when used in a large NAT'd > environment). > > -brandon That hasn't been my experience with some of the statistics coming out of colleges. People either just don't download the same stuff or they can't see each other via different clients. Now, if there were one IETF standardised P2P protocol which clients could implement, with basic proxying/content routing at higher levels built in; maybe some of this mess would be saner. Unfortunately I think the cat's not just out of the bag, its gone and had 15 generation of kittens.. Adrian

1 0