Bugzilla – Bug 668
not clear which values are to be used for QosTag::m_tid
Last modified: 2009-11-24 08:00:35 UTC
Created attachment 571 [details] enum UserPriority for QosTag currently there is no explicit hint on which values needs to be passed to the constructor QosTag::QosTag(uint8_t) or the QosTag::Set() methods. The proposed patch is an attempt to make the user do the right thing.
(In reply to comment #0) > Created an attachment (id=571) [details] > enum UserPriority for QosTag > > currently there is no explicit hint on which values needs to be passed to the > constructor QosTag::QosTag(uint8_t) or the QosTag::Set() methods. > > The proposed patch is an attempt to make the user do the right thing. > The patch looks good...but what do you propose for HCCA mode? In that mode TID value is between 8 and 15.
> The patch looks good...but what do you propose for HCCA mode? In that mode TID > value is between 8 and 15. > Well, my understanding is that QosTag really is only about User Priorities (UP), which will be set at the application layer (or anywhere else above networking) and as such are independent from the MAC being used. Actually, I would suggest moving qos-tag.{h,cc} out of src/dev/ces/wifi, since this code is much more related to the application layer and networking layer than to the mac/phy, and it is not specific for wifi only. The exact translation between the UP and the TID being used at the MAC layer depends on the MAC layer only, and it is not modified by this patch. If I understand correctly, the current wifi code supports only the mapping for EDCA, that is, TID = UP, with UP being between 0 and 7. For HCCA, the mapping between UPs and TIDs should be determined by a TSPEC element as per IEEE Std. 802.11-2007, Section 7.3.2.30, which does not seem to be currently implemented in ns3. However, let me stress again that I think this issue is beyond the scope of this patch. Nicola
Hrm, I thought I had posted comments before but I lost them. The code was originally designed with the assumption that the user knew what he was doing and that the user would provide a tid in the qos tag. What I was expecting is that, if/when tspec negociation is implemented, the WifiNetDevice would support a RequestFlow method with a bunch of arguments to specifty the kind of tspec to request to the AP and, a callback invoked when the reply comes form the AP to notify the user of the tspec tid. Then, the user would use that tid to tag packets using a trace hook at the application layer. The main reason the code was designed to do this is that there is no standard mechanism at the socket layer to specify qos requirements so, we have to do our own wifi/mac specific stuff and, since we were doing this, I did not see any point is trying to degined generic UP levels. To summarize, the current QosTag class was designed to be completely mac/wifi specific without any attempt at being generic so, while I don't see any reason not to make it easier to use for wifi (say, add a QosTag::SetUserPriority method), I also don't see much point in trying to make it more generic than that: It really contains a tid. I guess that when we get another MAC which has similar UPs, we can try to design a generic tag and use it in both macs but, until this happens, I would prefer to keep a wifi-specific qos tag.
Created attachment 674 [details] revised patch > To summarize, the current QosTag class was designed to be completely mac/wifi > specific without any attempt at being generic so, while I don't see any reason > not to make it easier to use for wifi (say, add a QosTag::SetUserPriority > method), I also don't see much point in trying to make it more generic than > that: It really contains a tid. Ok. Here is a revised patch which mainly does the following: 1) stick with a wifi-specific TID 2) add QosTag::SetUserPriority for user convenience 3) add doxygen documentation (I think the lack of it was the real cause of most confusion).
please, commit.
(In reply to comment #5) > please, commit. changeset: 5771:0fad665ff307