bug 668

[Nicola Baldo-3]

Hi all,

some time ago I posted a patch for bug 668:

http://www.nsnam.org/bugzilla/show_bug.cgi?id=668

Mirko had a look at it and we had some discussion, but we did not reach
any conclusion. Can we resume this discussion and see if the patch can
go into ns-3.7?

Regards

[Pavel Boyko]

On Thursday 05 November 2009 01:29:48 pm Nicola Baldo wrote:
> Hi all,
>
> some time ago I posted a patch for bug 668:
>
> http://www.nsnam.org/bugzilla/show_bug.cgi?id=668
>
> Mirko had a look at it and we had some discussion, but we did not reach
> any conclusion. Can we resume this discussion and see if the patch can
> go into ns-3.7?

  I vote for: 1) apply your patch 2) write comment to QosTag class, it can
quote bug 668 discussion starting from "The exact translation between the UP
and the TID being used ..." 3) move qos-tag.{h,cc} out of wifi (m.b. to
src/node?) and 4) close bug 668

  Pavel

[Mathieu Lacage]

The QosTag class was designed with the expectation that the user would
know what he is doing and that he would be giving a tid directly there,
not a UP. i.e., when we support TSPEC setup, the user could call
directly the MAC to establish the TSPEC with required parameters, get
the corresponding tid and set it in the qos tag of his application-level
packets (This is how I implemented it in the old ns-2 wifi code I wrote
originally).

As far as I can tell, this is the only way to allow user applications
control over the qos characteristics of an HCCA channel since there is
no standardized way to convey the application requirements from the
application down to the MAC layer.

Mathieu

On Thu, 2009-11-05 at 11:29 +0100, Nicola Baldo wrote:

> Hi all,
>
> some time ago I posted a patch for bug 668:
>
> http://www.nsnam.org/bugzilla/show_bug.cgi?id=668
>
> Mirko had a look at it and we had some discussion, but we did not reach
> any conclusion. Can we resume this discussion and see if the patch can
> go into ns-3.7?
>
> Regards