Bugzilla – Full Text Bug Listing |
Summary: | DSCP EF packets not prioritized by PrioQueueDisc | ||
---|---|---|---|
Product: | ns-3 | Reporter: | Tom Henderson <tomh> |
Component: | traffic-control | Assignee: | Stefano Avallone <stavallo> |
Status: | PATCH WANTED --- | ||
Severity: | normal | CC: | ns-bugs |
Priority: | P3 | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All |
Description
Tom Henderson
2018-06-19 17:05:00 EDT
(In reply to Tom Henderson from comment #0) > Now for the solution options. First, it seems to me that we should suggest > (and provide an example) that an IPv4 or IPv6 filter based on DSCP should be > added when configuring this queue, so that the queue does not rely on > priority tag but instead on PacketFilter. Currently, there is no packet filter based on DSCP (actually, there is none). On Linux, Diffserv based filtering is done with the dsmark qdisc and the tcindex filter. Probably we shall add these to ns-3 as well. Actually, I was thinking to implement a simplified version of the universal filter (u32). But this will take some time. > Second, we should try to improve > the mapping of TOS to priority in the IP stack. I am not sure how we can improve the mapping. I was thinking to implement RFC 8325 (https://www.rfc-editor.org/info/rfc8325) for wi-fi. Probably we can reuse it to improve the TOS-to-priority mapping ad well. > Third, we should document > better in the class Doxygen that the default (no packet filter) case relies > on the socket priority tag if present, but if there is no SocketPriorityTag > present, the default priority from index 0 in the priority map will be used. Yep, this can be easily done. > So in summary, suggest that Ipv4/v6 PacketFilter be used to map DSCP to > priority, but if the user forgets this, we should try to see that DSCP EF > gets classified to band 0 somehow. |