Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(141)

Issue 277570043: class of service, version 2

Can't Edit
Can't Publish+Mail
Start Review
Created:
8 years, 2 months ago by Tom Henderson
Modified:
8 years, 2 months ago
CC:
ns-3-reviews_googlegroups.com
Visibility:
Public.

Description

This is an alternative implementation of the feature in issue: https://codereview.appspot.com/277230044/ The basic difference is as follows. In this implementation, care is taken to avoid any need to touch NetDevice types that do not implement Class of Service handling. Instead, the IP layer (Ipv4Interface) will query the device for a special ClassOfServiceInterface object. This has been aggregated to WifiNetDevice but no other devices. If the GetObject<> () succeeds, then an additional Send() method is exposed, with an additional class of service parameter. This version follows the ns-3 pattern of using object aggregation (querying for an aggregated interface) to avoid the need to touch all derived classes. However, it makes it more complicated in the IP code to look for this interface rather than use the existing Send().

Patch Set 1 #

Total comments: 3
Unified diffs Side-by-side diffs Delta from patch set Stats (+775 lines, -15 lines) Patch
A examples/wireless/wifi-qos.cc View 1 chunk +184 lines, -0 lines 1 comment Download
M examples/wireless/wscript View 1 chunk +3 lines, -0 lines 0 comments Download
M src/applications/model/onoff-application.h View 2 chunks +17 lines, -0 lines 0 comments Download
M src/applications/model/onoff-application.cc View 4 chunks +28 lines, -0 lines 0 comments Download
M src/applications/model/udp-client.h View 1 chunk +20 lines, -0 lines 0 comments Download
M src/applications/model/udp-client.cc View 4 chunks +29 lines, -0 lines 0 comments Download
M src/internet/model/ipv4-header.h View 1 chunk +5 lines, -0 lines 0 comments Download
M src/internet/model/ipv4-header.cc View 1 chunk +41 lines, -0 lines 0 comments Download
M src/internet/model/ipv4-interface.h View 2 chunks +3 lines, -1 line 1 comment Download
M src/internet/model/ipv4-interface.cc View 3 chunks +64 lines, -7 lines 0 comments Download
M src/internet/model/ipv4-l3-protocol.cc View 8 chunks +11 lines, -6 lines 0 comments Download
M src/network/model/socket.h View 1 chunk +49 lines, -1 line 1 comment Download
A src/network/utils/class-of-service-interface.h View 1 chunk +96 lines, -0 lines 0 comments Download
A src/network/utils/class-of-service-interface.cc View 1 chunk +44 lines, -0 lines 0 comments Download
M src/network/wscript View 2 chunks +2 lines, -0 lines 0 comments Download
M src/wifi/helper/wifi-helper.cc View 2 chunks +5 lines, -0 lines 0 comments Download
A src/wifi/model/wifi-class-of-service-interface.h View 1 chunk +84 lines, -0 lines 0 comments Download
A src/wifi/model/wifi-class-of-service-interface.cc View 1 chunk +88 lines, -0 lines 0 comments Download
M src/wifi/wscript View 2 chunks +2 lines, -0 lines 0 comments Download

Messages

Total messages: 4
Tommaso Pecorella
Overall I like it MUCH more than the previous one. Simple and elegant. I have ...
8 years, 2 months ago (2016-01-05 18:10:08 UTC) #1
Tom Henderson
On 2016/01/05 18:10:08, Tommaso Pecorella wrote: > Overall I like it MUCH more than the ...
8 years, 2 months ago (2016-01-05 18:28:15 UTC) #2
Stefano Avallone
On 2016/01/05 18:28:15, Tom Henderson wrote: > OK, so this is one strong vote for ...
8 years, 2 months ago (2016-01-07 16:56:31 UTC) #3
Tom Henderson
8 years, 2 months ago (2016-01-07 17:15:09 UTC) #4
On 2016/01/07 16:56:31, Stefano Avallone wrote:
> On 2016/01/05 18:28:15, Tom Henderson wrote:
> > OK, so this is one strong vote for the aggregated interface approach.  I
said
> > yesterday that I felt less in favor of this than the tag after working on
it,
> > since it gets converted into a tag in the interface code anyway, and felt
> > intrusive to the Ipv4Interface code, as well as needing to propagate this
also
> > into the forthcoming tc layer.
> > 
> > I think that the major advantage of this approach is in not touching the
> > multitude of other device types.  It does not avoid the tag later being
placed
> > on the packet internally in the Wifi code.
> > 
> > Other thoughts?
> 
> Tom,
> 
> I think (and maybe you realized that, too) that the work on deferring the
> addition of the IP header until after the packet is extracted from the queue
> disc might make this approach a little less intrusive. Given that
> Ipv4Interface::Send receives the IP header, there would be no need to pass the
> cos to it. Given that TrafficControlLayer::Send also receives the IP header,
> there would be no need for Ipv4Interface::Send to propagate the cos to the tc
> layer. Also, the check whether the special interface is aggregated to the
device
> would be done just once in Ipv4Interface::Send (when the packet is destined to
> loopback) and once/twice in TrafficControlLayer::Send (depending on whether a
> queue disc is always installed on a device -- we might introduce a noqueue
queue
> disc to achieve that).

I agree that the impact in the Ipv4Interface class could be made more localized
than in this patch.  I would be fine with trying to adapt this approach to the
traffic control layer branch once that code stabilizes (and I would try to merge
this QoS support on top of that feature when the time comes).
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b