Skip to content
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

Open
Hacklin opened this issue Sep 2, 2011 · 7 comments
Open

802.1Q Mapping #5

Hacklin opened this issue Sep 2, 2011 · 7 comments

Comments

@Hacklin
Copy link
Collaborator

Hacklin commented Sep 2, 2011

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?

@dtaht
Copy link
Owner

dtaht commented Sep 2, 2011

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. :)

@Hacklin
Copy link
Collaborator Author

Hacklin commented Sep 19, 2011

Regarding: Commit Access

Sorry, but the company I work for, competes with devices running OpenWRT.
Maybe for new products we will use OpenWRT as well.
But till then, I can't really help you directly.
And as I don't compile the Diffserv sources, giving me commit access makes no sense.

@Hacklin
Copy link
Collaborator Author

Hacklin commented Sep 19, 2011

DSCP

These are the DS field values I use in 'netinet/ip.h':

/*
 * Definitions for IP Differentiated Services Code Points (DSCP)
 *
 * Taken from RFC-2597 Section 6, RFC-3246 Section 2.7, RFC-4594 Section 2.3 and RFC-5865 Section 4.
 */
#define IPTOS_DSCP_MASK                       0xfc
#define IPTOS_DSCP(ds)                        ((ds) & IPTOS_DSCP_MASK)
#define IPTOS_DSCP_DF                         0x00
#define IPTOS_DSCP_AF11                       0x28
#define IPTOS_DSCP_AF12                       0x30
#define IPTOS_DSCP_AF13                       0x38
#define IPTOS_DSCP_AF21                       0x48
#define IPTOS_DSCP_AF22                       0x50
#define IPTOS_DSCP_AF23                       0x58
#define IPTOS_DSCP_AF31                       0x68
#define IPTOS_DSCP_AF32                       0x70
#define IPTOS_DSCP_AF33                       0x78
#define IPTOS_DSCP_AF41                       0x88
#define IPTOS_DSCP_AF42                       0x90
#define IPTOS_DSCP_AF43                       0x98
#define IPTOS_DSCP_VA                         0xb0
#define IPTOS_DSCP_EF                         0xb8


/*
 * Definitions for IP Differentiated Services Code Points (DSCP) for Service Classes
 *
 * Taken from RFC-4594 Section 2.3.
 */
#define IPTOS_DSCP_LOCAL_NETWORK_CONTROL      0xe0  /* Layer 2 network control */
#define IPTOS_DSCP_NETWORK_CONTROL            0xc0  /* Network routing */
#define IPTOS_DSCP_TELEPHONY                  0xb8  /* IP Telephony bearer */
#define IPTOS_DSCP_SIGNALING                  0xa0  /* IP Telephony signaling */
#define IPTOS_DSCP_REALTIME_INTERACTIVE       0x80  /* Video conferencing and Interactive gaming */
#define IPTOS_DSCP_MULTIMEDIA_CONFERENCING    0x88  /* H.323/V_2video conferencing (adaptive) */
#define IPTOS_DSCP_MULTIMEDIA_CONFERENCING_1  0x88  /* H.323/V_2video conferencing (adaptive) [Low    Drop] */
#define IPTOS_DSCP_MULTIMEDIA_CONFERENCING_2  0x90  /* H.323/V_2video conferencing (adaptive) [Medium Drop] */
#define IPTOS_DSCP_MULTIMEDIA_CONFERENCING_3  0x98  /* H.323/V_2video conferencing (adaptive) [High   Drop] */
#define IPTOS_DSCP_BROADCAST_VIDEO            0x60  /* Broadcast TV and Live events */
#define IPTOS_DSCP_MULTIMEDIA_STREAMING       0x68  /* Streaming video and Audio on demand */
#define IPTOS_DSCP_MULTIMEDIA_STREAMING_1     0x68  /* Streaming video and Audio on demand [Low    Drop] */
#define IPTOS_DSCP_MULTIMEDIA_STREAMING_2     0x70  /* Streaming video and Audio on demand [Medium Drop] */
#define IPTOS_DSCP_MULTIMEDIA_STREAMING_3     0x78  /* Streaming video and Audio on demand [High   Drop] */
#define IPTOS_DSCP_OAM                        0x40  /* Operations, Administration, Maintenance & Provisioning */
#define IPTOS_DSCP_LOW_LATENCY_DATA           0x48  /* Client/server transactions and Web-based ordering */
#define IPTOS_DSCP_LOW_LATENCY_DATA_1         0x48  /* Client/server transactions and Web-based ordering [Low    Drop] */
#define IPTOS_DSCP_LOW_LATENCY_DATA_2         0x50  /* Client/server transactions and Web-based ordering [Medium Drop] */
#define IPTOS_DSCP_LOW_LATENCY_DATA_3         0x58  /* Client/server transactions and Web-based ordering [High   Drop] */
#define IPTOS_DSCP_STANDARD                   0x00  /* Undifferentiated applications */
#define IPTOS_DSCP_HIGH_THROUGHPUT_DATA       0x28  /* Store and forward applications */
#define IPTOS_DSCP_HIGH_THROUGHPUT_DATA_1     0x28  /* Store and forward applications [Low    Drop] */
#define IPTOS_DSCP_HIGH_THROUGHPUT_DATA_2     0x30  /* Store and forward applications [Medium Drop] */
#define IPTOS_DSCP_HIGH_THROUGHPUT_DATA_3     0x38  /* Store and forward applications [High   Drop] */
#define IPTOS_DSCP_LOW_PRIORITY_DATA          0x20  /* Any flow that has no BW assurance */

Note:

  1. The DSCP Service Class names come from RFC-4594
    except for 'IPTOS_DSCP_LOCAL_NETWORK_CONTROL'
    which is used for on IEEE Network Control (NC).
  2. IEEE Internetwork Control (IC) corresponds to DSCP Network Control .
    IEEE Network Control (NC) corresponds to DSCP Local Network Control.
    (The name 'Local Network Control' comes from the priority name that Cisco uses for this DSCP.)

@Hacklin
Copy link
Collaborator Author

Hacklin commented Sep 19, 2011

Applications

 DSCP Service Class     Dec Full Name                               (Examples)

Elastic Group:
 CS1                     8  Class Selector 1 / Priority
 LowPriorityData         8  Low-Priority Data / Scavenger           (P2P, BitTorrent)
 DF                      0  Default Forwarding
 CS0                     0  Class Selector 0 / Routine
 Standard                0  Standard / Best Effort                  (<default>, NTP for Clocks)

Assured Elastic Group:
 AF13                   14  Assured Forwarding 1, High   Drop
 AF12                   12  Assured Forwarding 1, Medium Drop
 AF11                   10  Assured Forwarding 1, Low    Drop
 HighThroughputData     10  High-Throughput Data / Bulk Data        (E-Mail, FTP, Backup Apps.)
 AF23                   22  Assured Forwarding 2, Low    Drop
 AF22                   20  Assured Forwarding 2, Medium Drop
 AF21                   18  Assured Forwarding 2, High   Drop
 LowLatencyData         18  Low-Latency Data / Transactional Data   (IM, Money Transfers, ERP Apps.)
 CS2                    16  Class Selector 2 / Immediate
 OAM                    16  Operations, Administration & Management (DNS, SNMP, SSH, Telnet, Syslog, Firmware Update)
 AF33                   30  Assured Forwarding 3, Low    Drop
 AF32                   28  Assured Forwarding 3, Medium Drop
 AF31                   26  Assured Forwarding 3, High   Drop
 MultimediaStreaming    26  Multimedia Streaming                    (VoD, Netflix, YouTube, Veamer, Pod Casts)

Real-Time Group:
 CS3                    24  Class Selector 3 / Flash
 BroadcastVideo         24  Broadcast Video                         (Live TV, Live Radio, Video Surveillance)
 AF43                   38  Assured Forwarding 4, High   Drop
 AF42                   36  Assured Forwarding 4, Medium Drop
 AF41                   34  Assured Forwarding 4, Low    Drop
 MultimediaConferencing 34  Multimedia Conferencing                 (Rate-Adaptive Video Conferencing)
 CS4                    32  Class Selector 4 / Flash Override
 RealTimeInteractive    32  Real-Time Interactive                   (First Person Shooters, WoW)
 CS5                    40  Class Selector 5 / Critic/ECP
 Signalling             40  Call Signalling                         (SIP, H.323, SCCP, IGMP for TV)
 EF                     46  Expedited Forwarding
 Telephony              46  VoIP Telephony / Voice                  (VoIP Data, RTP, NTP for Computers)
 VA                     44  Voice-Admit
 AdmittedTelephony      44  Admitted VoIP Telephony                 (Virtual Circuits, Serial Lines)

 Network Control Group:
 CS6                    48  Class Selector 6 / Internetwork Control
 NetworkControl         48  Internet Control / Routing              (DHCP, OSPF, BGP, EIGRP, IGMP, IKE, RIP, AHCP)
 CS7                    56  Class Selector 7 / Network Control
 LocalNetworkControl    56  Intranet Control                        (Layer 1 & 2 Management, STP, ARP)

Notes:

  1. The DiffServ Code Points are sorted from low to high priority.
  2. The Class Selector DSCPs are backwards compatible with the IP Precedence.
    The IP Precedence name is in the Full Name field after the slash.
  3. Admitted Telephony is the same as Telephony; only the resources
    for the VoIP data have been pre-allocated (by RSVP) in each router.
  4. RSVP must use the same DSCP as the data traffic, for which it is reserving resources.
  5. By default Cisco QoS Baseline has switched the DSCPs for Signalling and BroadcastVideo:
                  |        DSCP Value           |
   Service Class  |  RFC-4594  | Cisco Baseline |
   ---------------|------------|----------------|-
   Signalling     |  CS5 = 40  |    CS3 = 24    |
   BroadcastVideo |  CS3 = 24  |    CS5 = 40    |
   -----------------------------------------------
   
 http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSIntro_40.html#wp60882

Suggestions:

  1. Give TCP SYN and SYN+ACK packets at least the LowLatencyData DSCP.
    Rate limit the number of TCP SYNs [to about 50/sec?] to reduce load, but only during congestion.
  2. Give TCP FIN and FIN+ACK packets the NetworkControl or at least the LowLatencyData DSCP.
    Dropping TCP FIN and FIN+ACK packets is detrimental to throughput.
  3. Give Webbrowsing one of the LowLatencyData DSCPs:
  • LowLatencyData1 (AF21) for https traffic and proxy connections,
  • LowLatencyData2 (AF22) for "interactive" browsing (AJAX, WebApps) and
  • LowLatencyData3 (AF23) for "bulk/normal" browsing.
    But beware, ports 80 and 443 are rat-holes;
    i.e. all kinds of different and unrelated traffic are squeezed through these ports.
  1. Give DNS and DHCP their own Signalling-like DSCP of 42 (= 0x2a = 052)?
    Otherwise give DNS the OAM DSCP and DHCP the NetworkControl DSCP.
  2. Give TCP ACK only packets (packets without payload data) the NetworkControl DSCP.
    Reducing TCP ACK drops reduces unnecessary packet resents.
    Re-ordering packets is detrimental to the throughput of the TCP connection.
  3. For backwards compatibility:
    treat IPTOS_LOWDELAY as an OAM DSCP,
    treat IPTOS_THROUGHPUT as HighThroughputData DSCP and
    treat IPTOS_RELIABILITY as Standard DSCP.
  4. For forwards compatibility treat all odd value DSCPs as their even DSCP equivalents.

Clarification:
When I say "Give .. DSCP", I mean that a router should treat the packet as if the packet has the given DSCP, not that a router should actually mark the packet with the DSCP.

@dtaht
Copy link
Owner

dtaht commented Sep 20, 2011

  1. The diffserv code is in no way openwrt specific - it is linux specific, and needs to cover clients,servers,handhelds,and routers.
  2. Establishing a clear, useful standard for diffserv - and providing sample implementations - is a good idea - across all OSes.

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.

@dtaht
Copy link
Owner

dtaht commented Sep 20, 2011

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.

@Hacklin
Copy link
Collaborator Author

Hacklin commented Sep 21, 2011

  1. What I meant was that SYNs should only be rate limited during
    congestion. During congestion the performance is already limited. When
    you reduce the number of SYNs, you reduce the number of new connection
    flows.
    [I don't do this. Dynamically changing the rate limit may not be worth
    it.]
  2. FIN drop should be low, because closing connections frees up
    resources.

ACKs should only get prioritized, if they are not piggy-backed.
You want ACKs to get through, so packets aren't unnecessary resent.
However, you don't want to re-order packets, as this is detrimental to
the TCP connection's throughput. Giving preferential treatment to ACK
packets without any payload data is a save way to to do this.
[I do this.]

  1. A bit costly to classify the type of http traffic. The application
    should set the DSCP.
    [I don't do this.]
  2. According to Cisco DNS should use the OAM DSCP and DHCP should use
    NetworkControl DSCP.
    [I treat packets with DSCP 42 the same as ones with the Signalling
    DSCP.]

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"
reply@reply.github.com
wrote:

re: "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 to FIN ratio of some sort, maybe - but with
individual web connections able to start 6+ connections at a time, and
complete more than that, this can drastically limit performance for
multiple users over a router.

  1. 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.

  1. Absolutely. I wish there was more than 3 sane traffic classes
    available in dscp for web traffic.
  2. 42 rocks.

Reply to this email directly or view it on GitHub:
#5 (comment)

http://www.fastmail.fm - Send your email first class

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants