October 2007 - Test - lists.nanog.org

RE: BitTorrent swarms have a deadly bite on broadband nets
by Paul Ferguson 22 Oct '07

22 Oct '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- "Crist Clark" <Crist.Clark(a)globalstar.com> wrote: >[...] How >many P2P protocols are already blocking/shaping evasive? The Storm botnet? :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHHUavq1pz9mNUZTMRAoINAJ4ooF/62eGDSP8ediLys2CifbuUCwCglF/v iPLQgxrMz9iVlHWiUYkfFkQ= =UV+2 -----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/

1 0

Comcast blocking p2p uploads
by Steven M. Bellovin 22 Oct '07

22 Oct '07

http://www.nytimes.com/aponline/technology/AP-Comcast-Data-Discrimination.h… http://www.nytimes.com/aponline/technology/AP-Comcast-Data-Discrimination-T… Not a lot more I can say, other than argghhh! --Steve Bellovin, http://www.cs.columbia.edu/~smb

36 70

Re: Can P2P applications learn to play fair on networks?
by Adrian Chadd 21 Oct '07

21 Oct '07

On Sun, Oct 21, 2007, Christopher E. Brown wrote: > Where is there a need to go beyond simple remarking and WRED? Marking > P2P as scavenger class and letting the existing QoS configs in the > network deal with it works well. Because the p2p client authors (and users!) are out to maximise throughput and mess entirely with any concept of fairness. Ah, if people understood cooperativeness.. > A properly configured scavenger class allows up to X to be used at any > one timer where X is the capacity unused by the rest of the traffic at > that time. Adrian

1 0

OT: Remebering Abha Ahuja - 6 years
by Patrick W. Gilmore 21 Oct '07

21 Oct '07

Sorry for the OT post, but it has been 6 years since Abha passed. I'm sure there's lots more to say, but I don' think I can say it. Rest in peace, Abha. You know how much we miss you. -- TTFN, patrick

3 2

how to write an incident report
by Joe Abley 21 Oct '07

21 Oct '07

For those who don't recognise the name (presumably many people), Citylink are a disruptive high-speed metro transport provider in Wellington, New Zealand. They run the most elaborate and scary layer-2 switched ethernet network I've ever heard of, and the other week they ran into some problems which caused a prolonged outage. Here's their writeup: http://news.clnz.net/2007/10/19#Loopback-Saturday-Discussion Why don't I have any suppliers like this? Joe

9 9

dns authority changes and lame servers
by Mike Lewinski 20 Oct '07

20 Oct '07

I find it exceptionally annoying that there is no process whereby the root servers and/or registrars can inform us of new/modified/removed delegations. The end result is that we serve a lot of stale zones long after they leave us. In the past I've hacked out some perl to audit our BIND configs and find the stuff that's moved, but it's ugly. And really, it's only partially dependable. For example, does the lack of root server records mean that: 1) the customer abandoned the zone and no longer wishes us to host it - or - 2) the customer forgot to pay the zone today, and tomorrow will bitch like hell if my script removes it overnight There are sub-problems of this, mostly related around customers who move and change their company names every six months. So now I have a customer whose zone has expired from the roots (no more email to them) and whose phone number has changed (no way to call and find out what real intentions re: expired zone are). It's not worth our time to physically drive to their site to answer a question that has little to no real financial implications for us (thanks to the free hosting of up to three domains with order of T1 service). So questions: 1) Does anyone else find this flaw in the DNS system as annoying as I do? If authority is to be regularly moved around between ISPs (who may be hosting thousands of customer domains), some automated process is needed to allow the ISP to make intelligent choices about when to remove a customer zone (authority transfers to another provider are likely the thing I'd key on, while non-payment removals would probably have a 30 day grace period since aforementioned physical moves are most likely cause of non-payment expiration). 2) Does anyone have a better way of cleaning out the dreck than some home-grown scripts? I've used sleep() judiciously to try not beating on any external servers more than necessary, but the output is less than 100% predictable and often hand audits are required before I can really generate automatic removals. We used to get bitch notices from someone about zones we were supposed to be authoritative for and weren't. This was even more annoying, since often the whole point was that the customer was "parking" it on our servers but had used their 3 freebies and had no real immediate use for it, so neglected to tell us of it. Fine. But give us some notification, from somebody, so we can stick an empty placeholder in there and be ready when it is deployed. For extra fun, this week a customer simply added their new providers DNS servers to their zone, without removing ours, or asking us to remove our config. So things were kinda whacky for them until someone called us and asked WTF was going on.

14 19

Some thoughts on 240/4
by Eliot Lear 20 Oct '07

20 Oct '07

Dear all, Thanks to Vince for presenting at NANOG. Everyone should recognize by now that this is a provocative topic. Even the authors of draft-fuller-240space-00.txt do not altogether agree on what should happen in the medium term. The one thing we do agree on, and we hope you do to, is that the future is now, and that code changes need to occur quickly if this space is to be useful for ANYTHING. I would agree with the many people who have pointed out that there are a billion devices out there, many of which might not ever understand 240.0.0.0/4. But this issue is complex. There are many possibilities and I believe it requires a bit of study before the community jumps in with both feet as to the best answer for this space. By way of background, and you'll see why this becomes relevant later down in this message, I am no fan of private address space, and less a fan of NATs. I think both add complexity into an already complex environment and should generally be avoided. I am a co-author of both RFC 1617 and RFC 1918, so I have some idea bout what I am talking about. I also have enough formal training in economics to know that the issues surrounding 240.0.0.0/4 are not simply a matter of computer science, but not enough training to really help me drive to a conclusion on the matter. Having said all of this, let's talk about some possible uses for 240.0.0.0/4. When doing so, let's ask three questions: * Who would benefit? * What effort is involved to realize the benefit? * What is the risk of not devoting the address space to this use? * Are there alternatives that would equally satisfy the need in this case? Let's first suppose that 240.0.0.0/4 or some portion of it is made private. This is what draft-wilson-class-e-01.txt proposed. There are two distinct groups who could potentially benefit from private address space. Big cable providers require a substantial number of IP addresses just for management purposes. As Alain has already pointed out, not every provider would want to make use of this space, but rather simply go to IPv6. Still, some might. The effort involved in making this space useful would be a change to cable modems, CMTS hardware, and back end systems that need to process the address. By comparison, many cable modems and CMTSes already have an IPv6 capability for this purpose. Only individual providers know who their vendors are and what their back end systems look like in order to understand just how much work is involved. The risk of not devoting address space to this use would be a need for large providers to bite the bullet and deploy v6 for this purpose (n.b., this says nothing of end user use). Another alternative to would be to mark an additional /8 or two out of the OTHER remaining unicast space (< 224.0.0.0) as private. Some large organizations are said to be running out of RFC 1918 space. These organizations could benefit from some portion of 240/4 being marked as private. The perceived benefit would be that it forestalls an infrastructure upgrade to IPv6 that might require an out-of-cycle depreciation hit. As a case and point, some account and billing systems have knowledge of addresses, and the first provider to jump could end up bearing the full brunt of the cost of the upgrade, while other providers coast. This is the typical early adopter charge, when one finds oneself on the left side of the Rogers Curve. Randy has spoken some to this point, and could probably do so more eloquently than I. The problem here is the effort required to realize the benefit. Because large organizations have large amounts of hardware, large number of vendors to interact with, and a large amount of management software, the cost of using 240.0.0.0/4 is likely to approach that of upgrading to IPv6. Worse, if someone eats the cost of doing this, they will still need to eat the cost of moving to IPv6 later, so this would be almost a double hit. This says nothing of actual product development costs to remove the few lines of code that mark 240.0.0.0/4 as a martian. Another alternative to would be to mark an additional /8 or two out of the OTHER remaining unicast space (< 224.0.0.0) as private, as no code changes would be necessary. I believe someone already mentioned this on the list. As you heard at NANOG, Dino, Vince, Scott, and many others, including myself, are investigating LISP. Another potential use of this address space would be as RLOC space. To remind you, this would be essentially PA space that is only seen in the network core. If widely deployed, this would free up space outside the 240/4 block for other uses. The effort to deploy as RLOC space would be roughly similar to our first use case, except it will depend on what transition mechanisms are made available. If as a matter of transition, the entire Internet has to understand 240.0.0/4 in their FIBs and RIBs, that in itself may require an upgrade of some software EVERYWHERE. An alternative would be to use IPv6 address space or to continue to use IPv4 blocks as providers do today. This use really bridges between public and private addressing, although the astute might argue that a little public is like being a little pregnant. So let's talk about public use cases. If the IANA were to simply allocate these addresses out after a time the way they do today, the benefit would be to push out the run-out date by about 10 months. This would require every public system on the Internet to upgrade. The alternatives here are complex. One could move to IPv6, or use multiple layers of NAT (although gamers would find this highly objectionable). Arguably this where we all stand up and in a grand chorus say, "There is no Plan B to IPv6". But here is the case for completeness' sake. This leaves one final possible use. There can be no doubt that a market exists today for IP address space. It is simply a black market. There have been discussions on mailing lists such as PPML and in other forums of what happens if a market is structured for IP address space. Putting aside whether you believe this to be a good idea or a bad idea, should it happen, the possibility of speculation to drive up prices would be something that we would have to contend with. Having a big block of addresses concentrated in some authority could well dissuade the use of the IP address market for generating capital gain. The transition to IPv6 will be bumpy enough without speculators. To say there are many complex issues with this case would be a MASSIVE understatement. First of all, it has many if not all of the problems of the previous case. It could be that the addresses are made usable to some portion of upgraded equipment, and that this would be sufficient to ward off speculators. Also, the network effect and IPv6 *could* represent a price cap that further deters speculators. The risk, however, of not considering this use could be a very serious disruption to those who are least able to move to IPv6. Consider for the moment any industry that requires certification of their devices. That will take a while. In such circumstances, a firm cannot simply move. And there are shades of gray here. It might well be that portions of a firm are moved to IPv6 and portions remain on v4. This will depend on service provider offerings and vendor tool sets. So. There are mine. You probably have others you would add to the list. I think I can speak for Vince and Dave when I say that we should consider these cases as we are actually removing 240.0.0.0/4 from our bogon filters, because it's all academic if we don't change our code now. We'll be talking more about this at the IETF in Vancouver in the int-area meeting. Eliot

4 10

240-e List
by Jared Mauch 20 Oct '07

20 Oct '07

Seems there is a lot of people interested in this within the operator community. Since some have developed patches, and other ideas, I've created a new mailing list http://puck.nether.net/mailman/listinfo/240-e Information on how to subscribe, post, etc.. is located there. - 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.

2 1

Re: Comcast blocking p2p uploads
by Steven M. Bellovin 19 Oct '07

19 Oct '07

On Fri, 19 Oct 2007 15:26:14 -0400 "Christopher Morrow" <christopher.morrow(a)gmail.com> wrote: > On 10/19/07, John C. A. Bambenek <bambenek(a)gmail.com> wrote: > > > > I love how the framed it as "data discrimination". Let's just be > > honest... 99% of it was illegal traffic taking up far more than > > their fair share of bandwidth. > > is there really anyway to really know how much of it was > legit/legal/illegal?? Nope. And BitTorrent is trying to be very legit; see, for example, http://www.forbes.com/home/technology/2007/10/08/brightcove-fox-paramount-t… Besides, legal issues should be dealt with by the legal process. If nothing else, there one has guarantees of due process and the right to contest the charges. > > Also, I'll channel Sean Donelan now: "ISP's... damned if they do, > damned if they don't" It's a funny world out there :) > > (also, how is it that Comcast is getting dinged on this but BT or > other carreirs doing similar 'rate shaping' for p2p traffic are NOT?) > Personally, I see a big difference between rate-shaping and sending RSTs. (I suppose you could view RSTs as allocating 0 bps, but that's not a helpful distinction.) That said, I don't approve of other carriers sending RSTs, either; I simply happened to see the articles on Comcast today. --Steve Bellovin, http://www.cs.columbia.edu/~smb

2 1

Re: Comcast blocking p2p uploads
by Daniel Senie 19 Oct '07

19 Oct '07

At 03:10 PM 10/19/2007, John C. A. Bambenek wrote: >I love how the framed it as "data discrimination". Let's just be >honest... 99% of it was illegal traffic taking up far more than their >fair share of bandwidth. Let's be honest. The US ISPs have been advertising "unlimited" service, but heavily oversubscribe to limit costs. The expectation is that users will only use the bandwidth rarely and in short bursts. We all know all about over subscription, but it is now problematic due to distributed applications. Blocking heavy users (or terminating them, as at least one cellular/wireless Internet service provider does to heavy users of its "unlimited" service) is false advertising. but it seems to be accepted all around, without so much as an asterisk and footnote. So it all comes down to what the definition of "unlimited" is. Truth in advertising and all that. There seems to be a great unwillingness to tell the truth in our society.

1 0