New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
802.1Q Mapping #5
Comments
Good point, and getting this all right is important. and CS1 is just plain wrong. You have a clue, I'm giving you commit access. :) |
Regarding: Commit Access Sorry, but the company I work for, competes with devices running OpenWRT. |
DSCP These are the DS field values I use in 'netinet/ip.h':
Note:
|
Applications
Notes:
| DSCP Value | Service Class | RFC-4594 | Cisco Baseline | ---------------|------------|----------------|- Signalling | CS5 = 40 | CS3 = 24 | BroadcastVideo | CS3 = 24 | CS5 = 40 | -----------------------------------------------
Suggestions:
Clarification: |
I am travelling heavily in the next few days (moving to france!) and will attempt to straighten out this repo along the lines you suggest (we are mostly on the same page, with your page far more detailed than mine!) and will get back towards producing a working implementation on linux during the cerowrt-1.0rc7 release cycle. |
re: 1) "Give TCP SYN and SYN+ACK packets at least the LowLatencyData DSCP." Mostly agree. "Rate limit the number of TCP SYNs [to about 50/sec ?] to reduce load." Disagree. having a (SYN start to FIN completion) ratio of some sort, maybe - but with individual web connections able to start 6+ connections at a time, and complete more than that within a second particularly in places close to internet core systems, this can drastically limit performance for multiple users over a router. re: 2. A problem with prioritizing fin,ack and fin+ack packets in any way is that then they can get ahead of the remainder of the ack packets (which will still get sent onwards, uselessly). So this is a win for the tcp sender, but does little for the tcp client doing the close. That said, it seems a good idea. I do agree that these packets should NOT be dropped very often by an AQM. re: 3. Absolutely. I wish there was more than 3 sane traffic classes available in dscp for web traffic. re: 4. 42 rocks as a newly defined traffic class. |
ACKs should only get prioritized, if they are not piggy-backed.
Please note that I updated my comment on GitHub. Manuel Stol E-mail: ManuelStol@operamail.com On Monday, September 19, 2011 6:54 PM, "Dave Täht"
http://www.fastmail.fm - Send your email first class |
In scripts/functions.h : mac80211e() and ame/functions.h : mac8021q(), mac80211e()
CS1 DSCP (= Signalling DSCP Service Class) is mapped to a background priority.
The CS1 DSCP is placed in the IpTables Chain 'Ants' (comment: "VOIP Signalling").
Is the mapping from CS1 DSCP to IEEE 802.1Q PCP and IEEE 802.11e AC (WMM) correct?
If so, why is VoIP Signalling in IpTables an Ant and for IEEE 802.1Q PCP a background?
The text was updated successfully, but these errors were encountered: