Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

I have found the link!

neutrino38 (1037806) writes | more than 6 years ago

The Internet 0

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

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

cancel ×


Sorry! There are no comments related to the filter you selected.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>