Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
The Internet

Journal neutrino38's Journal: I have found the link!

I have finally found the link of this famous comment about implementing RFC1349. I reproduce here the relevant extract of the comment

One suggested solution that has not worked so far, and is unlikely to work in the foreseeable future, is voluntary bandwidth allocation protocols such as RSVP. Few people bother to use them, partly because they are poorly understood and partly because they are not widely implemented at the consumer end.

However, there is room for QoS in a limited, but still useful form. This uses an existing mechanism in IP, the TOS field. Some applications already set TOS to sensible values, which is commendable - it would be nice if some notice was taken of it at the points where it really matters.

I think there is reasonable provision for three general TOS classes:

  1. Low Latency, Limited Bandwidth (both directions) - for VoIP and shells
  2. Interactive Browsing, Limited Upload Bandwidth, Unlimited Download
  3. Bulk Traffic, Unlimited Bandwidth (both directions) - for P2P and unmarked flows

This simple priority scheme can be implemented within each queue in the above traffic shaper, perhaps combined with SFQ or similar just to give things an extra boost. It still doesn't require packet inspection beyond the TCP header, even with SFQ - and not even that if it's just a P-FIFO.

What it achieves is isolation of consumers' typical usage patterns from each other, within their own traffic streams. At the same time, applications have an incentive to correctly mark their traffic - if they just shove it in Low Latency regardless, they will get limited bandwidth, which isn't good for P2P! Malicious abuse is also avoided by the isolation of the intra-user priority from other users' flows.

That was easy, wasn't it?

I notice that Comcast is implementing a functionally similar scheme with this year's round of cable equipment updates. This appears to be just the bandwidth equalisation, which is implemented at the edge modems with help from the cable's upload receiver. I can't help guessing that this solution occurred to them only when they talked to BitTorrent Inc. I wonder whether the latter suggested it? Enquiring minds want to know.

Hat's off Mr funkman

This discussion has been archived. No new comments can be posted.

I have found the link!

Comments Filter:

Q: How many IBM CPU's does it take to execute a job? A: Four; three to hold it down, and one to rip its head off.