Open Source Projects Europe

Hello,

the matter of handling RMT queues is going to require some discussion since we're not entirely sure how are we supposed to work with them (specifications are a bit vague about this).

Could Jordi or Sergio give me a brief overview of what are they expecting from us, especially why do we need multiple queues for each flow?

Thanks.

You can check https://wiki.ict-pristine.eu/wp3/d31/D31-CO-CL#Resource-allocation-in-a-DIF, check the second figure on why you need multiple queues per N-1 flow if you want to treat traffic from N-flows differently.

Jordi and Sergio want to try this multiplexing approach: https://wiki.ict-pristine.eu/wp3/d31/D31-CO-CL#Scheduling-for-resource-allocation-with-multiple-levels-of-QoS

For more details they are the experts :)

Okay, I shall separate queue allocation procedures into a "QueueAllocPolicy" (inside Resource Allocator) and write sample policies for the three cases described on the wiki.

Before we can declare this thing implemented, I'd like to raise one question. I originally asked Jordi about this via e-mail, but maybe someone else here may like to comment on it.

The way I understand it, you want to have support for multiple queues per (N-1)-flow for not only output directon but also for input. This seems to require some sort of demultiplexing logic to take place before the PDUs coming from below even enter their RMT input queues. In another words, a classification policy needs to be run on each PDU arriving to a port. Is this actually desirable?

I must admit this kind of PDU processing is something I have actively avoided from the start because the idea of classifying a PDU before it enters its input queue (and is classified again afterwards) didn't sit right with me, especially in lowest-level IPC processes that should, when implemented in a real setting, be handling data straight from the wire.

Implementation-wise, there isn't really any problem -- right now I'm asking from a strictly architectural point of view.

The current stable version contains support for multiple I/O queues per port + several examples.

The behavior can be specified by two of the RA policies:
- the QueueAlloc policy manages allocation/deallocation strategy of RMT queues via event hook methods (such as onNM1PortInit(), onNFlowAlloc())
- the QueueIDGen policy generates an ID for a given Flow object or a PDU; it should be invoked 1) by the QueueAlloc policy when picking a name for a newly created queue, and 2) by RMT when it needs to store a PDU into its corresponding queue

Example policies for all three allocation strategies described on https://wiki.ict-pristine.eu/wp3/d31/D31-CO-CL are provided.

Known issues:
- The "virtual circuit" approach (a queue per N-flow for each IPC process) isn't currently supported for routers' top-level IPC processes because those aren't aware of (N)-flows that are being relayed by them. This requires some modifications of RIBd which should be done in the future.

• status: open --> closed