Multiple output queues

94 views

Skip to first unread message

Antti Mäkelä

unread,

Mar 31, 2010, 11:19:04 AM3/31/10

to ns-3-users

Hey,

is there any work in implementing multiple outgoing queues to a
single netdevice?

I'd like a relatively simple functionality, basically a priority
queue, where if a packet has some specific diffserv flag set (per RFC,
Expedited Forwarding class), it gets assigned to a different queue and
sent first.

Implementing in e.g. PointToPointNetDevice would seem simple enough
- In TransmitComplete() just check for a m_priorityqueue first and
send that instead of m_queue, and in Send() check if Diffserv flag is
set in packet and decide which queue to use.

Also, for setting the flag, socket option SO_PRIORITY in Linux is
something that probably could be reimplemented in ns-3's protocol
stacks - but if someone else has already worked this out I'd
appreciated a pointer..

Anyway, usually packet marking and classification is done by edge
routers instead of originating services directly. So if there is such
a work going on (this would basically have to be hooked to
RouteInput()) I'd like to check that too. If I understand correctly,
ipv4-l3-protocol.cc:s Receive() first makes a copy of the incoming
packet, then RemoveHeaders() the IP headers, and calls RouteInput with
the header information and rest of the packet.
This header and rest of the packet gets passed back to IpForward()
where right now it just sets TTL -1, nothing else.

So...In RouteInput, it should be ok to do a PeekHeader() (not
remove) to get the protocol headers for TCP/UDP if appropriate, and
classify traffic if they match some sort of classification list
(probably IP prefixes and port ranges). Basically a function like

MatchTraffic(Ipv4InterfaceAddress prefix, uint8_t diffserv, uint8_t
protocol = 0, uint16_t src_portstart=0,uint16_t src_portend=0,
uint16_t dst_portstart=0, uint16_t dst_portend=0).

where protocol and anything related that would be optional (and only
have significance if it would be TCP or UDP, that is 6 or 17).

Would such an API be appropriate to place in Ipv4 (and Ipv6)?

...and again, has anyone already worked on this?

Antti Mäkelä

unread,

Apr 3, 2010, 7:56:33 AM4/3/10

to ns-3-users

On Mar 31, 6:19 pm, Antti Mäkelä <zar...@gmail.com> wrote:
> So...In RouteInput, it should be ok to do a PeekHeader() (not
> remove) to get the protocol headers for TCP/UDP if appropriate, and
> classify traffic if they match some sort of classification list

Judging by lack of responses (or Easter?-)) I take it that no one
has yet taken a look at this.

Anyway, patch incoming for marking in the near future, then.

I think all I really have to do is come up with API for marking, and
then change RouteInput() in list-routing.cc (as it's going to be
common for all routing protocols) enough to

if (classification_enabled)
{
for (iterate through match statements)
{
bool match;
Compare against ipv4 source, destination masks (using eg.
header.GetDestination().CombineMask())
if matchstatement contains transport protocol info
{
uint8_t proto = header.GetProtocol();
if (proto == 6) {
Ptr<TcpHeader> tcp = Create<TcpHeader>;
p->PeekHeader(&TcpHeader);
// (compare dest/source ports, ranges)
}
// Do same for UDP
if (match) header->SetTos(asconfigured);
}
}

Doesn't seem like it's too complicated. The match statements should
basically be either it's own class or just a
struct
{
Ipv4InterfaceAddress network,
uint8_t protocol, // Only valid values are zero, 6 or 17
uint16_t src_port_start, // Defaults to 0 if neither start or end
specified
uint16_t src_port_end, // Defaults to 65535 or to
src_port_start if specified
uint16_t dst_port_start, // Same as src_port
uint16_t dst_port_end,
uint8_t tos_byte // Maybe provide API for DiffServ values
directly
};