The objective of this tutorial is to extend basic L3 forwarding with an implementation of Explicit Congestion Notification (ECN).
ECN allows end-to-end notification of network congestion without
dropping packets. If an end-host supports ECN, it puts the value of 1
or 2 in the ipv4.ecn
field. For such packets, each switch may
change the value to 3 if the queue size is larger than a threshold.
The receiver copies the value to sender, and the sender can lower the
rate.
As before, we have already defined the control plane rules for routing, so you only need to implement the data plane logic of your P4 program.
Spoiler alert: There is a reference solution in the
solution
sub-directory. Feel free to compare your implementation to the reference.
The directory with this README also contains a skeleton P4 program,
ecn.p4
, which initially implements L3 forwarding. Your job (in the
next step) will be to extend it to properly append set the ECN bits
Before that, let's compile the incomplete ecn.p4
and bring up a
network in Mininet to test its behavior.
-
In your shell, run:
make
This will:
- compile
ecn.p4
, and - start a Mininet instance with three switches (
s1
,s2
,s3
) configured in a triangle. There are 5 hosts.h1
andh11
are connected tos1
.h2
andh22
are connected tos2
andh3
is connected tos3
. - The hosts are assigned IPs of
10.0.1.1
,10.0.2.2
, etc (10.0.<Switchid>.<hostID>
). - The control plane programs the P4 tables in each switch based on
sx-runtime.json
- compile
-
We want to send a low rate traffic from
h1
toh2
and a high rate iperf traffic fromh11
toh22
. The link betweens1
ands2
is common between the flows and is a bottleneck because we reduced its bandwidth to 512kbps in topology.json. Therefore, if we capture packets ath2
, we should see the right ECN value.
- You should now see a Mininet command prompt. Open four terminals
for
h1
,h11
,h2
,h22
, respectively:mininet> xterm h1 h11 h2 h22
- In
h2
's XTerm, start the server that captures packets:./receive.py
- in
h22
's XTerm, start the iperf UDP server:iperf -s -u
- In
h1
's XTerm, send one packet per second toh2
using send.py say for 30 seconds:The message "P4 is cool" should be received in./send.py 10.0.2.2 "P4 is cool" 30
h2
's xterm, - In
h11
's XTerm, start iperf client sending for 15 secondsiperf -c 10.0.2.22 -t 15 -u
- At
h2
, theipv4.tos
field (DiffServ+ECN) is always 1 - type
exit
to close each XTerm window
Your job is to extend the code in ecn.p4
to implement the ECN logic
for setting the ECN flag.
The ecn.p4
file contains a skeleton P4 program with key pieces of
logic replaced by TODO
comments. These should guide your
implementation---replace each TODO
with logic implementing the
missing piece.
First we have to change the ipv4_t header by splitting the TOS field into DiffServ and ECN fields. Remember to update the checksum block accordingly. Then, in the egress control block we must compare the queue length with ECN_THRESHOLD. If the queue length is larger than the threshold, the ECN flag will be set. Note that this logic should happen only if the end-host declared supporting ECN by setting the original ECN to 1 or 2.
A complete ecn.p4
will contain the following components:
- Header type definitions for Ethernet (
ethernet_t
) and IPv4 (ipv4_t
). - Parsers for Ethernet, IPv4,
- An action to drop a packet, using
mark_to_drop()
. - An action (called
ipv4_forward
), which will:- Set the egress port for the next hop.
- Update the ethernet destination address with the address of the next hop.
- Update the ethernet source address with the address of the switch.
- Decrement the TTL.
- An egress control block that checks the ECN and
standard_metadata.enq_qdepth
and sets the ipv4.ecn. - A deparser that selects the order in which fields inserted into the outgoing packet.
- A
package
instantiation supplied with the parser, control, checksum verification and recomputation and deparser.
Follow the instructions from Step 1. This time, when your message from
h1
is delivered to h2
, you should see tos
values change from 1
to 3 as the queue builds up. tos
may change back to 1 when iperf
finishes and the queue depletes.
To easily track the tos
values you may want to redirect the output
of h2
to a file by running the following for h2
./receive.py > h2.log
and just print the tos
values grep tos h2.log
in a separate window
tos = 0x1
tos = 0x1
tos = 0x1
tos = 0x1
tos = 0x1
tos = 0x1
tos = 0x1
tos = 0x1
tos = 0x1
tos = 0x1
tos = 0x1
tos = 0x1
tos = 0x1
tos = 0x3
tos = 0x3
tos = 0x3
tos = 0x3
tos = 0x3
tos = 0x3
tos = 0x1
tos = 0x1
tos = 0x1
tos = 0x1
tos = 0x1
tos = 0x1
How can we let the user configure the threshold?
There are several ways that problems might manifest:
ecn.p4
fails to compile. In this case,make
will report the error emitted from the compiler and stop.ecn.p4
compiles but does not support the control plane rules in thesX-runtime.json
files thatmake
tries to install using a Python controller. In this case,make
will log the controller output in thelogs
directory. Use these error messages to fix yourecn.p4
implementation.ecn.p4
compiles, and the control plane rules are installed, but the switch does not process packets in the desired way. The/tmp/p4s.<switch-name>.log
files contain trace messages describing how each switch processes each packet. The output is detailed and can help pinpoint logic errors in your implementation. Thebuild/<switch-name>-<interface-name>.pcap
also contains the pcap of packets on each interface. Usetcpdump -r <filename> -xxx
to print the hexdump of the packets.ecn.p4
compiles and all rules are installed. Packets go through and the logs show that the queue length was not high enough to set the ECN bit. Then either lower the threshold in the p4 code or reduce the link bandwidth intopology.json
In the latter two cases above, make
may leave a Mininet instance
running in the background. Use the following command to clean up
these instances:
make stop