Joho the BlogGiving packets sirens - Joho the Blog

Giving packets sirens

I want to pull on just one thread in the argument against Net neutrality: The claim that it’s obvious that some types of applications deserve priority. It’d be crazy not to give priority to Internet telephony packets or to heart monitoring packets. Right?

It seems crazy because it’s a fact that some application types are sensitive to delay and others are not. No denying that.

But given finite bandwidth and an indefinite number of jitter-sensitive, delay-sensitive app types, it’s not obvious that the ISPs are the ones who should make the decision about how to prioritize the packets. That is, it makes sense to give vehicles with sirens priority in the streets, but when an indefinite number of vehicles have sirens, who decides which vehicles get priority? If I’m not a VOIP user and if I don’t care about watching videos over the Net, why should my World of Warfare packets suffer? Why should your interest in high-def ESPN packets shoulder aside my SecondLife packets? Do my in-game chat VOIP packets deserve the same — or greater? — priority than your VOIP business calls? If I’m a Boston researcher who is engaged in some obscure (but important to me) delay-sensitive research with a lab in Japan, why should I have to hope the ISPs will decide to honor my packets’ sirens? Will my physician have to petition Comcast to let my kidney monitoring data have priority? Diabetes monitoring vs. thyroid info? Who decides if routine heart monitoring data should go at the same speed as critical care heart data?

And if I invent a new type of application that happens to be delay-sensitive, who has to approve it to get it onto the priority list?

If the only way to manage this were to rely upon the ISPs, then we’d just have to hope they’d make decisions that are genuinely in the public interest. But, if end-users can instead make those decisions, why not give them the power to say that they want their heart monitoring data to have a huge siren, and VOIP to be a Yugo that needs a valve job? And when their hearts stabilize, let them turn down those packets’ priority. in order to avoid an obvious gaming of the system, only let users change their designated siren vehicles once a month or so. And, I’d prefer that the ISPs not charge for this service — it’s simply a bit of network mgt — because I don’t want to give them an incentive for keeping the system sluggish.

There are some easy ways to present this to users, ways that never use the word “packet” or “jitter.” Let them designate some sites as high priority. Let them specify some application types (telephone calls, on-demand video). Even maybe let them choose “What type of user are you?” from a list.

It’s entirely possible that the solution I’m proposing is technically impossible or too expensive. IANAG (I am not a geek.) Nevertheless, thinking that some packets obviously should have priority doesn’t resolve the problem of figuring out how to prioritize packets. The more you look at it, the less obvious it becomes. [Tags: ]

10 Responses to “Giving packets sirens”

  1. Show me something that genuinely needs low latency, low jitter packets and I’ll show you something that shouldn’t be carried over a consumer grade internet line. In general, more bandwidth and better design just solves this problem. And for proof of that, see Skype.

  2. Indeed, I think it’s important to resist this framing. I’ve written before both on the idea of allowing subscribers to shape their own traffic rather than having the providers do it.

    And, as I’ve observed, this is a best efforts network. You want certainty, use a different network. Different applications belong on different networks. It is foolish to break the current best efforts network for a handful of applications favored by providers.

  3. ISPs can get away with this story because of the network topology. Whether star or hub and spoke design, there are many different types of customers along the line between the cloud and you. That means that a single set of priority decisions will likely impact everyone in between.

    If every end user were to be able to prioritize themselves, as some point those priorities would have to be resolved with each other. It surely won’t be as granular as heart monitoring vs. thyroid because those probably aren’t identfied as such – perhaps one can only use a source like MassGen to make the decision. VOIP or P2P are identifiable though, and thus easier to decide to block.

  4. Quality of service (QoS) is also very subjective to the context in which someone is using an app. So, the real network management decision, imho, is not simply between one app and another app, or one protocol and another, but between specific needs in specific cases–something that *can’t* be managed primarily at the public router level.

    For example, I was involved in running some live audio events, RTSP streaming over the net, going back to 1996. And, the ability for certain players to buffer the streams effected the perception of QoS–in some cases, higher quality audio that was delayed (buffered) for 30 seconds was not acceptable. In other cases, buffering was way better than degraded quality audio.

    Given the known limitations of the network, between manual and automatic features in the audio players (one end) and decisions we’d make about broadcasting the audio (the other end), we could optimize based on what we considered to be QoS for each event.

  5. Here’s how I think this should work: your ISP should sell you a plan that allows you a certain quota of bandwidth in four classes of service. In the highest class, you’d be limited to the equivalent of 30 minutes a day of VoIP, or about 30 MB. In the second class, you’d get maybe 2 hours at SDTV video rate, about 75MB; in the third class you’d get 150MB, and the fourth would be unlimited. You’re free to use these quotas as you see fit, and it’s your obligation to mark the streams, which your home gateway/router would do for you according to rules you define (as people configure WiFi WMM today.)

    If you go over quota for a certain class, it’s simply demoted to the next lower class for which you have some quota left. There is no guarantee of QoS outside the carrier’s network, but if he wants to negotiate with his wholesale provider to honor your QoS markings that can be a selling point.

    This is good for ISP’s because it relieves them of the hassle of packet stream inspection, and it’s good for The People because it gives them QoS when they want it.

    On a statistical network, there are no hard and fast guarantees, but there are statistical behaviors that can be manipulated in a meaningful way. So let’s open the door to doing that.

    The only downside is that it make the NN issue go away completely, and some people obviously need to keep on making a living from it.

    BTW, it was good to meet you yesterday, David.

  6. […] Since I suggested yesterday that I would alternate days between anxiety and other topics, I’ll point to the heavy-handed corruption evinced by Comcast’s deliberate inhibition of participatory democracy, and I’ll put off talking about lost sleep till tomorrow. On the other hand, if that fortune cookie slip were right, and my dreams were indeed to come true when I least expect it, I would be hard-pressed to imagine a time I expect it less than, for instance, right about now.   Returning to Comcast, David provides both a rich account of what happened at the hearing (bloggie-style, so you have to read from the bottom up) and a meditation on how dangerous the path is that starts identifying some packets as privileged. […]

  7. Larry, I assume the provider would only provide a best-effort to speed the chosen packets through the last-mile funnel. Since, as Comcast said, they are managing the slowdowns caused by their party-line model, accelerating packets through that particular bulge in the pipe ought to be as effective as the protocol-based discrimination Comcast has been engaged in. (Am I getting this right? Or, more exactly, how am I getting this wrong?)

    Richard, what you’re proposing is a version of the “bucket of bits” idea that’s structured like most cell phone contracts in the US? I like that idea in general. But does it manage the congestion?

    Richard, after years of I’d say pretty much uninterrupted disagreement, it was good to meet you and have a chance to talk with you about some of what we have in common.

  8. Yes, it does manage congestion provided it’s implemented in both the upstream and downstream entry point to the residential link. It’s pretty normal in enterprise wireless, and the universities love it.

    I suggested it in my written filing with the FCC a couple of weeks ago. It enhances both sein and zeit.

  9. Richard, can you explain more about how the bucket-of-bits idea manages congestion? Let’s say the 500 people sharing my stretch of the cable have bought the various size buckets, but we all decide to watch the high-def He-Hunks of Baywatch online special at 9pm on Monday. Presumably, we’ll create congestion for one another. Does the bit-bucket proposal help prevent that somehow or help sort it out, or is it irrelevant to that particular traffic jam?

    I’m just trying to understand…

  10. […] by and their cause has been taken up by thousands of people. However, not everyone agrees that Net Neutrality is necessarily a good thing, arguing that the new model might “allow […]

Web Joho only

Comments (RSS).  RSS icon