small updates

03-RSVP/README.md

@@ -555,31 +555,30 @@ allocated as you expected.
 
 ## Part 2: Rate Limiting and Priorities
 
-At this point, you have competed a basic implementation of RSVP.
-Congratulations!
+At this point, you have completed a basic implementation of centralized RSVP. Congratulations! 
 
-As you may have noticed, even tough that the controller takes into account the 
-bandwidth hosts request when computing the reservations, switches do not perform
-any rate limiting. Thus, a host making a 1Mbps reservation is still able to get 
-full bandwidth. Furthermore, at this point, all the reservations are treated equally. 
+As you may have noticed, even though the controller takes into account the 
+bandwidth hosts request when computing the reservations, edge switches do not perform
+any rate limiting. In fact, a host making a 1Mbps reservation is able to get
+full bandwidth. Furthermore, at this point, all the reservations are treated equally.
 
 In this second part of the exercise, we will improve our implementation and rate
 limit host reservations using meters at ingress switches. Also, by extending our 
-`add_reservation` controller function, we will introduce the sense of priority to
+`add_reservation` controller function, we will introduce a sense of priority to
 the reservations.
 
 ### Task 1: Reservation rate limiting with meters
 
 During the last [lecture](https://polybox.ethz.ch/index.php/s/A7lGH0JQsGSpBob) 
-you were taught P4 stateful data structures. There, we showed you
+you were taught different P4 stateful data structures. There, we showed you
 that direct/indirect color `meters` can be used to rate limit traffic. 
 
-The `bmv2` software switch implements the so called two-rate three-color marker meters. 
+The `bmv2` software switch implements the so-called two-rate three-color marker meters. 
 You can find more details in the corresponding [RFC](https://tools.ietf.org/html/rfc2698).
 The figure below shows how two-rate three-color marker meters work. In the figure we use 
 the packet size as count unit, however `bmv2` supports both bytes and packet-based meters.
 
-These meters are configured using four parameters:
+Two-rate three-color meters are configured using four parameters:
 
 * CIR(committed information rate): is the rate per unit of time in bytes or packets at which the CBS bucket is filled. 
 * PIR(peak information rate): is the rate per unit of time in bytes or packets at which the PBS bucket is filled. 
@@ -598,7 +597,7 @@ If we consider a byte-based meter, a packet of size `B` is colored as follows:
 
 In this task, you will need to extend your `rsvp.p4` program such that each reservation
 is metered and all non-green packets get dropped. Furthermore, you will have to extend 
-your controller code such that after every reservation addition or modification its 
+your controller code such that after every reservation (addition or modification) its 
 associated meter is configured properly.
 
 > Hint: in the last lecture there are some slides in which you can find how to define and use meters. 
@@ -608,10 +607,11 @@ associated meter is configured properly.
 1. Whenever a meter is executed, the color is saved into a metadata field. Define that field in your metadata structure.
 2. Define a direct meter at the beginning of your ingress pipeline. You can find an example in the slides and 
    some documentation in the [v1model documentation](https://github.com/p4lang/p4c/blob/master/p4include/v1model.p4).
-3. Read the meter in all the `mpls_ingress_x_hop` actions to your metadata field. 
-4. Update your ingress control logic and drop all the packets for which the meter is yellow or red (not green).
+3. Associate the direct meter with the table `FEC_tbl`. 
+4. Read the meter in all the `mpls_ingress_x_hop` actions to your metadata field. 
+5. Update your ingress control logic and drop all the packets for which the meter is yellow or red (not green).
 
-At this point you have all the P4 logic to rate limit your traffic reservations.
+At this point, you have all the P4 logic to rate limit your traffic reservations.
 However, you still need to add some small modifications to your controller code such
 that associated meters get configured with the desired rate.
 
@@ -621,7 +621,7 @@ that associated meters get configured with the desired rate.
    meters using our control plane API you will have to use `meter_set_rates(meter_name, handle, rates)`.
    `meter_name` is the name you called the meter in `P4`, `handle` is the table handle for the reservation rule and 
    `rates` is a list of the form `[(CIR, CBS), (PIR, PBS)]`. *IMPORTANT:* in `bmv2` `CIR` and `PIR` are the bucket 
-   filling rate every micro second. For example, if `CIR=1` the bucket is filled at a rate of 1000000/s. 
+   filling rate per microsecond. For example, if `CIR=1` the bucket is filled at a rate of 1000000 Bytes/s (or packets). 
 
 2. Implement the function `get_meter_rates_from_bw(self, bw, burst_size)`. This function has to return 
    `[(CIR, CBS), (PIR, PBS)]`. Use `bw` (Mbps) to compute `CIR` and `PIR` (in bytes). 
@@ -640,7 +640,7 @@ that associated meters get configured with the desired rate.
 1. Start the topology and the controller.
 
 2. Make 2 bidirectional reservations from `h1->h5` and `h2->6`. For the 
-   first use `2Mbps`, for the second `8Mbps`.
+   first one use `2Mbps`, for the second one `8Mbps`.
 
 ```
 ======================================================================
@@ -707,21 +707,21 @@ still did not use the `priority` attribute when performing the allocations. In t
 you will have to modify the `add_reservation` controller function such that some reservations
 have a higher priority over others. 
 
-When a a high priority reservation comes and there is no space left many different things 
+When a high priority reservation comes and there is no space left many different things 
 could be done. For example, previous reservations can be moved to make space, reservations 
-with lower priority can be deleted to make space, etc. As a guide we propose you one way, 
-which is the one we will provide as a solution. Our proposed solution is not perfect, but 
+with lower priority can be deleted to make space, etc. We propose one possible implementation, 
+which will then be the one we will provide as a solution. Our proposed solution is not perfect, but 
 does well enough while not needing a major change to the current implementation. In any case, 
 feel free to implement a different algorithm.
 
 We propose the following algorithm:
 
 1. if the reservation (addition or modification) fits in the current network we do the same than before.
-2. if the reservation (addition or modification) does not fit in the network:
-  1. remove all the reservations with a lower prioiry than the requested one. Hint: you don't need to really remove them from switches, you can just remove its capacities. 
-  2. Check if the requested reservation fits the network without the lower priority ones.
-  3. if it fits, add or modify it. Now, take all the reservations with lower priority that you `virtually` removed, and allocate them starting with the ones with highest priority. Some will remain in the same path, some will be moved to a new path. If they don't fit anymore, delete them. 
-  4. if it does not fit remove the entry if this is a modification (the entry already existed)
+2. if the reservation (addition or modification) does not fit in the current network:
+  1. remove (`virtually`) all the reservations with a lower priority than the requested one. Hint: you don't need to remove them from switches, you can just remove its capacities. 
+  2. Check if now, (without the low priority reservations) the requested reservation fits the network. 
+  3. if it fits, add or modify it. Now, take all the reservations with lower priority that you `virtually` removed, and allocate them starting with the ones with the highest priority. Some will remain in the same path, some will be moved to a new path, and some, if they don't fit anymore, will be deleted. 
+  4. if it does not fit, if there is an existing entry for this reservation, delete it.
 
 > Hint: make sure `self.links_capacity` is updated properly in each of your steps. Sometimes, when you virtually remove 
 reservations you will have to add the capacity to links. 

03-RSVP/rsvp.p4

@@ -126,7 +126,7 @@ control MyIngress(inout headers hdr,
 
     action mpls_ingress_1_hop(label_t label_1) {
 
-        // PART 2 TASK 1.3 Read meter
+        // PART 2 TASK 1.4 Read meter
 
         hdr.ethernet.etherType = TYPE_MPLS;
 
@@ -138,7 +138,7 @@ control MyIngress(inout headers hdr,
     }
 
     action mpls_ingress_2_hop(label_t label_1, label_t label_2) {
-        // PART 2 TASK 1.3 Read meter
+        // PART 2 TASK 1.4 Read meter
 
         hdr.ethernet.etherType = TYPE_MPLS;
 
@@ -156,7 +156,7 @@ control MyIngress(inout headers hdr,
     }
 
     action mpls_ingress_3_hop(label_t label_1, label_t label_2, label_t label_3) {
-        // PART 2 TASK 1.3 Read meter
+        // PART 2 TASK 1.4 Read meter
 
         hdr.ethernet.etherType = TYPE_MPLS;
 
@@ -180,7 +180,7 @@ control MyIngress(inout headers hdr,
     }
 
     action mpls_ingress_4_hop(label_t label_1, label_t label_2, label_t label_3, label_t label_4) {
-        // PART 2 TASK 1.3 Read meter
+        // PART 2 TASK 1.4 Read meter
 
         hdr.ethernet.etherType = TYPE_MPLS;
 
@@ -210,7 +210,7 @@ control MyIngress(inout headers hdr,
     }
 
     action mpls_ingress_5_hop(label_t label_1, label_t label_2, label_t label_3, label_t label_4, label_t label_5) {
-        // PART 2 TASK 1.3 Read meter
+        // PART 2 TASK 1.4 Read meter
 
         hdr.ethernet.etherType = TYPE_MPLS;
 
@@ -246,7 +246,7 @@ control MyIngress(inout headers hdr,
     }
 
     action mpls_ingress_6_hop(label_t label_1, label_t label_2, label_t label_3, label_t label_4, label_t label_5, label_t label_6) {
-        // PART 2 TASK 1.3 Read meter
+        // PART 2 TASK 1.4 Read meter
 
         hdr.ethernet.etherType = TYPE_MPLS;
 
@@ -288,7 +288,7 @@ control MyIngress(inout headers hdr,
     }
 
     action mpls_ingress_7_hop(label_t label_1, label_t label_2, label_t label_3, label_t label_4, label_t label_5, label_t label_6, label_t label_7) {
-        // PART 2 TASK 1.3 Read meter
+        // PART 2 TASK 1.4 Read meter
 
         hdr.ethernet.etherType = TYPE_MPLS;
 
@@ -336,7 +336,7 @@ control MyIngress(inout headers hdr,
     }
 
     action mpls_ingress_8_hop(label_t label_1, label_t label_2, label_t label_3, label_t label_4, label_t label_5, label_t label_6, label_t label_7, label_t label_8) {
-        // PART 2 TASK 1.3 Read meter
+        // PART 2 TASK 1.4 Read meter
 
         hdr.ethernet.etherType = TYPE_MPLS;
 
@@ -407,7 +407,7 @@ control MyIngress(inout headers hdr,
             NoAction;
         }
         default_action = NoAction();
-        meters = rsvp_meter;
+        // PART 2 TASK 1.3 Associate table with meter
         size = 256;
     }
 
@@ -459,7 +459,7 @@ control MyIngress(inout headers hdr,
             mpls_tbl.apply();
         }
 
-        // PART 2 TASK 1.4 Drop all the packets for which the color is not green
+        // PART 2 TASK 1.5 Drop all the packets for which the color is not green
 
 
     }