Just wanted to say you made my day with your paper about p4-codel HOT 7 OPEN

Hi Dave,
At the moment P4 can not describe how packets are dequeued. In our proposed implementation we use the fixed capabilities of the BMv2 switch.

For the fq_codel algorithm: a classification based on a 5-tuple is possible. If the switch supports multiple queues they can be used. However, the decision which queue should be served next is not part of P4. A simple RoundRobin should be supported by any target with more than one queue per egress port.

A smarter way would be a programmable scheduler, as proposed in "Programmable Packet Scheduling at Line Rate" on SIGCOMM'16. Maybe something like this will become part of a future P4 specification.

In short: yes, I think it is possible and I add it to my ToDo List ;-)

For details about the implementation: https://www.kom.tu-darmstadt.de/research-results/publications/publications-details/?no_cache=1&pub_id=KBV%2B18-1

from p4-codel.

I have made a possibly mistaken assumption that a 5 tuple hash was essentially "free" nowadays.

Elsewhere we had made some progress with the DRR implementation for the netfpga that cambridge has but the work halted due to lack of funding.

elsewhere, elsewhere, I'd discussed how to go about it with netronome:

That conversation went like this:

"I think it would be feasible to implement fq_codel on the NFP.

The hardware schedulers do not support fq_codel, so the schedulers
would have to be implemented in one of the NFP firmware languages
(e.g. micro-C or micro-code); the NFP hardware rings could be used for
the queueing mechanism. Practically, this may be one way of making it
work:

The main worker threads could calculate the flow hash in order to
select which ring should be used, and then issue the packet to a
re-ordering thread.
I believe the re-ordering thread can push the packets to the internal
NFP rings instead of the wire.
The scheduler thread could then make the scheduling decision, pop the
packet from the corresponding ring, then send the packet to the
hardware packet schedulers (or drop the packet if performing a
head-drop), and also check the timestamp for the CoDel portion of the
algorithm.
The hardware packet schedulers should then transmit the packet.

In terms of handling any rate-mismatch on the outgoing interface, you
could have another thread monitor the NFP hardware packet scheduler
queue levels. The scheduler thread can then throttle the packet rate
being sent to the hardware packet schedulers (unless of course it is
okay to tail-drop at the hardware packet scheduler queues).

Finally, if the outgoing interface is not the natural point of
congestion/rate mis-match (e.g. if the outgoing Ethernet interface is
attached to a cable/DLS modem), the NFP hardware does have some
support for rate-limiting the outgoing interface (e.g. limiting a 10
Gigabit Ethernet interface down to 600 Mbps outbound), so as to move
the congestion/rate mis-match point to the NFP, so that fq_codel can
take effect in terms of handling the buffer bloat."

from p4-codel.

I've always been puzzled about people needing "queues", in that the next fetch from memory in a linear implementation of fq_codel is basically hash & 3FF (for 1024 queues, but as few as 64 are "useful"), and the netfpga version just grabbed that from a bram block. I know there's a huge gap between C code, fpgas, and p4, but...

from p4-codel.

I note I'd settle for sfq or drr with lots of queues in hw, and letting the endpoints manage depth. :)

from p4-codel.

@ralfkundel - heard of SCE yet? It's a really nice backward compatible extension to classic ECN that works well, (we think) even with single queued AQMs. Maybe that will be easier to express in P4?

https://tools.ietf.org/id/draft-morton-taht-sce-00.html

https://github.com/dtaht/bufferbloat-rfcs/blob/master/sce/results/prototype1/Screen%20Shot%202019-03-30%20at%204.25.16%20PM.png

from p4-codel.

Hi Dave,
thanks for the hint to SCE. We already thought about ECN and now we will consider SCE as well.
However, our planed next steps are further tests on hardware, e.g. Tofino, Netronome and P4-NetFPGA.

from p4-codel.

Well, I'd like my team to be able to join with you on your efforts!! Our preso at ietf tsvwg went well,
and transport support is progressing rapidly.

https://www.youtube.com/watch?v=JQmWyr0JDJM&t=1h3m50s

Can we setup a time/day to talk? What tz are you in? I'm currentlt in prague.

from p4-codel.