(In reply to comment #0)
> Created an attachment (id=571) [details] [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 an attachment (id=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