Re: [manet] next version of pause extension

[Henning Rogge <[e-mail]>]

On Thu, Nov 9, 2017 at 5:24 PM, Rick Taylor
<[e-mail]> wrote:
> Queue and Flows however are an altogether more complicated problem.  Yes, the answer is probably a QueueId dataitem to discriminate between the egress queues on the local modem, but there still needs to be a "These are my queues" announcement (complex), and even then I'm not sure that covers all the potential use-cases!
>
> Are we discussing:

lets assume we have an additional TLV called "queue id" which carriers
a numeric identifier similar to the current LID.

> * The local modem classifies egress traffic into more than one egress queue, *no matter* what destination it goes to?  In which case the metrics are {per-Destination,per-Queue}, and the control is per-Queue

Each neighbor would announce the same queue-id per "traffic class".
Flow control would refer to this flow-ids.

e.g.:

neighbor 1, traffic class 1: queue-id 1
neighbor 1, traffic class 2: queue-id 2
neighbor 2, traffic class 1: queue-id 1
neighbor 2, traffic class 2: queue-id 2

flow control could be done by defining parameters for queue-id 1 or queue-id 2.

> * The local modem maintains one egress queue for each destination? In which case we have metrics per-Queue and control per-Queue, but some kind of Queue-to-Destination mapping.

Each neighbor would announce the a different queue-id per "traffic
class". Flow control would refer to this flow-ids.

e.g.:

neighbor 1, traffic class 1: queue-id 1
neighbor 1, traffic class 2: queue-id 2
neighbor 2, traffic class 1: queue-id 3
neighbor 2, traffic class 2: queue-id 4

flow control could be done by defining parameters for flow-id 1 to 4.


The "flow control for whole interface" would just become the special
case where everyone is "queue-id 0" (the default value if the queue-id
TLV is missing).

This mechanics would also give us the option to have a special
"broadcast" queue but still group all unicast together.

What do you think?

> One thing that is starting to crystalize in my mind is that it's all about transmit queues, any receive queueing that occurs should be transparent to the DLEP session for simplicity's sake.

yes, flow control is mostly interesting at the bottleneck... unless we
assume a radio faster than the ethernet, we don't have a bottleneck
for receiving queues.

Henning