It could, yes, but in both cases, you're likely to have more than just an allegation against an anonymous identifier; as soon as you can show the judge the outline of your future case against the identified individual, you've passed the bar he set.

Taking your examples in turn, in the telephone line subscriber case, you would be expected to show the judge some evidence that you were receiving silent or abusive calls (maybe a call recording, maybe a diary of the calls paired up with some records from your phone provider to show that those calls did actually happen, even if the content isn't as you state). You now have some evidence that your request isn't just a fishing expedition, and the subpoena process can continue.

In the car case, if you present a police record of your incident report, that's a good enough start to get you going - you've again demonstrated that there is more to your request than a simple fishing expedition.

In the case presented to the judge, there was no evidence of infringement that was of high enough standard to present in court, merely an allegation by the plaintiff; the judge basically told the plaintiff "come back with evidence, and then we'll talk".

I read the judgement - did you? In it, the judge makes it clear that the IP address and a naked assertion of infringement is not enough to get the subpoena; you need sufficient evidence to show the judge that you can tie the infringement to the IP address, and could continue to tie the infringement to an individual if you were given the chance to identify possible individuals.

So, if I can show that I know that a user of the IP address infringed, and that if I could get the Limewire user GooberToo who was also sharing Ubuntu 10.04 x86_64 and Fedora 15 i686 I would have the user who infringed, I could still get the subpoena. If all I have is an IP and an allegation of infringement, tough.

At a technical level, there still are ATM fees for using a bank ATM in the UK. It's just that our banks have worked out that it's better for business overall if the fees are internal bookkeeping between banks rather than something to pass onto a customer.

Put simply, banks with huge ATM networks like Barclays make a net profit on ATM fees; they receive more than they pay out. Banks with small ATM networks often find it cheaper to pay the fees than to either expand their network or deal with the customer service problem of guiding irate customers to their only ATM in town (partly because mobile phones means that people are more likely to call in and ask for help, mostly because - as you've said - no foreign withdrawal fees is a selling point).

Just to help with that feeling that things are improving, I've been and looked up the modern equivalent of my SEAT (size-wise - it has a more powerful engine to make up for weighing a bit more, getting it marginally better 0-60 figures than my current car). It's got the same size fuel tank, and is rated to get between 487 and 690 miles on one tank. I could get a bit more mileage (about 50 to 100 miles per tank) by going for a less powerful engine that closely matches my current car.

As my normal driving is dominated by high-speed roads, I'm getting close to the highest end figures my car can manage - it's only rated to get 550 miles on a tank at most, and I should expect about 400 to 450 miles per tank.

So, things are improving - it helps that fuel prices here are much higher than in the USA, so poor fuel economy is higher on people's shopping list. Plus, you'd be mad to buy a car today without expect fuel prices to at least double if not triple in the next 3 years - either the price of crude will do it, or the tax rate will be increased again.

I'm going from a small car to a big car. My new car is 6.5" wider, 30" longer, and 2" higher than the one it's replacing, giving me twice the carrying capacity; it's also about 50% heavier than the old one.

Given all that, it's not surprising that it's a little more fuel hungry.

A 600 mile range on a tank of fuel isn't especially large - I get 500 miles per tank (40 litres) on my 1998 SEAT Cordoba Vario. My new car (a Skoda Superb that's being built now) is rated (manufacturer figures) to get anything from 490 to 730 miles on a single tank of fuel (60 litres).

There is a market for 3kW kettles - I even own a cordless one from Krups. John Lewis's online list of kettles is dominated by 3kW units.

Your cheap (under £20) kettle will be a 2kW model, so that they can sell the same kettle EU-wide (just change the plug), but more expensive ones are able to draw more; checking Comet's web site, I see that all 12 kettles they sell for under £20 are also under 10A draw, but once you're spending £20 or more, you can get 3kW kettles.

And it's important to have a fast boiling kettle - there's enough waiting involved in making tea as it is.

The same class of GPS map is sold in the UK; the problem is that they cost more than the cheap car GPS units. Taking Garmin as a sample manufacturer, the cheapest car unit they sell here is £99. The cheapest truck unit is £259. A trucker buying a GPS unit on his own dime because he's a bit unsure about how best to get to his destination, but isn't brave enough to ask the office to get the maps out is going to buy the £99 unit. And then he's going to foul up; if it wasn't such a problem for the rest of us, it'd just be funny.

Indeed - once the overflow state caused by bufferbloat gets that bad for most people, we'll see a repeat of the 1986 NSFNet congestion collapse. Lots of packets flowing, buffers filling and emptying, and next to no usable throughput, as each bloated buffer in turn overflows and causes a full-blown RTO timeout, not a fast recovery.

The TCP window has only grown that large because there's been no congestion signalled; thanks to slow start, my TCP window started out at just 2 packets, but grew and grew until TCP experienced congestion. Bufferbloat has meant that TCP has not experienced any congestion until the latency has reached insane values (as congestion is signalled in the Internet by dropping packets).

This is the root cause of the problem; we have lots of workarounds for it, but at heart, the issue is that the only working mechanism for indicating congestion on the Internet is packet drops (packets marked as ECN-capable are blocked by too many idiots with firewalls to be useful). TCP by design will increase the current in-use window size until such point as it experiences congestion, then it will scale back to fit within the link; because we've removed congestion notification in the name of zero packet loss (yet we still have packet loss on these "zero packet loss" links - go figure), we hit pain.

If you artificially constrain TCP so that it cannot fill a link (i.e. make the maximum window tiny compared to BDP - noting that on today's Internet, I experience BDPs from as little as 1 kilobyte, to as high as 10 megabytes), then, yes, you won't hit bufferbloat - you won't hit saturation, either. If you rate limit outside the application layer (and how exactly is Slashdot's web server meant to know what the bottleneck rate between Slashdot and my PC is, exactly?), you have to signal congestion back to TCP somehow. On the Internet, that's done by dropping packets instead of queueing them; but, thanks to bufferbloat, my link doesn't drop packets until the latency is very high. As a result, TCP doesn't scale back its send rate until it's too late; I can fix that locally, by rate limiting at my router to some fraction of my link speed, but then I have to drop the packets that exceed that fraction. Why shouldn't the ISP drop them instead, and thus let me use more of the link speed I'm paying for?

How much bandwidth can I have, though? Take the link between my desktop and a Slashdot server; is the correct answer "1GBit/s, no more" (speed of my network card)? Is is "20MBit/s, no more" (speed of my current Internet connection)? Is it "0.5MBit/s, no more" (my fair share of this office's Internet connection)? In practice, you need the answer to change rapidly, depending on network conditions - maybe I can have the full 20MBit/s if no-one else is using the Internet, maybe I should slow down briefly while someone else handles their e-mail.

TCP doesn't slam the network; it starts off slowly (TCP slow start currently sends just two packets initially), and gradually ramps up as it finds that packets aren't dropped. When packet drop happens, it realises that it's pushing too hard, and drops back. If there's been no packet drop for a while, it goes back to trying to ramp up. RFC 5681 talks about the gory details. It's possible (bar idiots with firewalls that block it) to use ECN (explicit congestion notification) instead of packet drop to indicate congestion, but the presence of people who think that ECN-enabled packets should be dropped (regardless of whether congestion has happened) means that you can't implement ECN on the wider Internet.

This works well in practice, given sane buffers; it dynamically shares the link bandwidth, without overflowing it. Bufferbloat destroys this, because TCP no longer gets the feedback it expects until the latency is immense. As a result, instead of sending typically 20MBit/s (assuming I'm the only user of the connection), and occasionally trying 20.01MBit/s, my TCP stack tries 20.01MBit/s, finds it works (thanks to the queue), speeds up to 20.10MBit/s, and still no failure, until it's trying to send at (say) 25MBit/s over a 20MBit/s bottleneck. Then packet loss kicks in, and brings it back down to 20MBit/s, but now the link latency is 5 seconds, not 5 milliseconds.

The point he's making is that in the days when TCP was developed, RAM was expensive, so we didn't have big queues. As a result, you didn't need to rate limit any connections to get low latency and high throughput.

Remember that no matter how big the queue is, if you saturate your link for long enough, you get a degree of packet loss. If, for example, the queue is 5 seconds long at maximum speed, and you saturate the link for 6 seconds, you lose some packets. TCP exploits this by using the packet drop as an indication that a link in the path between two hosts is saturated. When buffers are appropriately sized, and queue length appropriately managed by something active like RED, this is not a problem; latency stays low because the queue isn't that big compared to the link throughput, and packet drops genuinely indicate congestion on the path.

Bufferbloat creates the symptom you're working around by QoS and rate-limiting. Because the queue is immense, there's no packet drop until the latency is insane. Because there's no packet drop, the TCP stacks sending data your way don't believe that your link is congested, so don't slow down. Your rate-limiting and QoS fixes this by letting the packets come in via your Internet connection, then dropping them if the actual data rate exceeds a level below that which your line is capable of; Gettys is asking why you need to do that. Why can't your ISP shrink their queue, and drop packets when your line is just saturated, rather than building up an immense queue, which you promptly go and waste by throttling to less than the speed you've paid for?

Looks like my English irony didn't come over properly. Let me explain :-)

One of the other justifications I hear for "must have an SUV" is that the owner couldn't fit their entire family plus luggage for a trip away in a Smart, or a Mini, or a Renault Clio, and thus must drive a massive SUV. There's a false dichotomy there; the fair comparison is not "Range Rover" versus "Smart"; it's "Range Rover" versus (say) "Audi A8", where carrying capacity is similar.

As the Lexus IS (while not a small vehicle) has lower carrying capacity than many SUVs, I thought I'd describe it as "small"; I didn't want SUV apologists attacking me for not realising that they need immense load carrying capacity.

FWIW, I do see the market niche for SUVs; round here, it's people who need the carrying capacity of something like a Ford Transit Connect, but also need to be able to go offroad. I mentioned that my mother in law drives an SUV; she's a nurse, and has to make house visits to patients who can't get out in good weather, let alone snow. Worse, some of those patients aren't in houses on good tarmac roads, they're at the ends of muddy clearings that they used to maintain, but can't now they're injured. The SUV lets her get out to these patients whatever the weather, which means fewer people in hospital (i.e. more space for people who really cannot be elsewhere).

I've seen two fatal road accidents, and one injury accident in the last ten years. All three involved children, all three involved SUVs.

In the case of the two fatalities, the SUV driver was confident that the power and weight of their vehicle would let them do things that other road users weren't risking; it turns out that even a 3-ton SUV is going to lose against a 40-odd ton truck.

In the case of the injury, it was even simpler; the kid did something stupid (ran in front of their parent's vehicle, not behind it, to cross to the shop opposite their school), got hit at relatively low speeds (about 10 mph), and instead of going over the car (seen that, too, with a Lexus IS - quite survivable by the size of kids in question, who were merely shocked), went under the wheels (Range Rover). The resulting injuries needed hospital treatment.

As to the two fatalities? Fatality one was caused when two big rigs on a 3-lane highway hadn't seen each other and decided to signal to change lanes, the one on the left moving right, the one on the right moving left. The rest of us dropped back - you do not want to be next to a big rig when it's in a crash. The SUV driver went round the traffic that had dropped back, and tried to overtake - they nearly made it, but got hit by one of the big rigs. The SUV was crushed against the central reservation, then driven over by the rig that hit it. Result? Two adults declared dead on the scene, their child declared dead before I'd finished giving my statement of what I'd seen to the police.

The second was in icy conditions, climbing a hill with (again) big rigs coming down towards us. The SUV decided to try and overtake, lost control, span onto the other side of the road, and got hit in the side by a big rig. The resulting damage meant that people on the side that was hit were killed (possibly at time of impact, possibly when the SUV rolled and then slid on the damaged side), but people on the other side of the vehicle were OK.

You will notice a pattern to the serious incidents; someone does something stupid, and an accident ensues. In the two fatal cases, a better driver wouldn't have been involved in the first place; for the first of the two, they'd have observed that the trucks were signalling stupid plans, and that everyone else was dropping back, for the second, they'd have noted the icy conditions, and decided to take a bit longer rather than overtake when there's traffic coming downhill. I find myself wondering whether the sense that the SUV would protect them encouraged these drivers to take risks that they just wouldn't risk in a smaller car; if it did, it cost them dearly.

In the injury case, there wasn't that much the driver could do - similar accidents occurred at that spot about once every three months, as there was a school on one side of the road, and a shop on the other. Kids dropped off at school sometimes decided to go to the shop instead; if the kid was especially distracted, or especially foolish, they'd dart just in front of the car that just dropped them off. Result is one accident - small vehicles like the Lexus IS throw the kid over the bonnet, and there are no injuries, just a seriously terrified kid and parent. SUVs force the kids under the car, and if the wheels get them, it's serious injury time.

My conclusion? If you're buying an SUV to "keep the kids safe", you're better off spending the difference in price between a car and an SUV on advanced driving lessons; learn to read the road, and make better judgement calls. You're better off with half the chance of being in an accident, and a 25% higher chance of someone dying in the accident than you are with a slightly lower chance of someone dying in the accident, but twice the odds of being in an accident in the first place.

Further, it's worth thinking about the bumps and scrapes you've actually been in - if your experience is that you're regularly in high speed crashes involving other vehicles, but never in incidents where the collision speed is low, or there are no other vehicles involved, then an SUV might be a good idea on safety grounds; if you're like the rest of us, where you're as likely to be in an incident where you're the only motor vehicle involved (e.g. when parking), or where the collision speed is low (fender benders instead of head on collisions), a smaller vehicle meeting modern safety standards is going to protect you just as well, and you'll have money left over for driving lessons.