Update README.md in reference to #680 (#681)

* Update README.md

Added 5th point for Troubleshooting and Food for thought

Signed-off-by: Sankalp Jha <sankalp.jha9643@gmail.com>

* Added Space

Signed-off-by: Sankalp Jha <sankalp.jha9643@gmail.com>

* Updated README.md

Signed-off-by: Sankalp Jha <sankalp.jha9643@gmail.com>

* corrected number bullets

Signed-off-by: Sankalp Jha <sankalp.jha9643@gmail.com>

* Spacing

Signed-off-by: Sankalp Jha <sankalp.jha9643@gmail.com>

* more spacing

Signed-off-by: Sankalp Jha <sankalp.jha9643@gmail.com>

* Note line changed

Signed-off-by: Sankalp Jha <sankalp.jha9643@gmail.com>

---------

Signed-off-by: Sankalp Jha <sankalp.jha9643@gmail.com>

Author: blackdragoon26

exercises/ecn/README.md

@@ -58,26 +58,30 @@ for `h1`, `h11`, `h2`, `h22`, respectively:
    ```bash
    mininet> xterm h1 h11 h2 h22
    ```
-3. In `h2`'s XTerm, start the server that captures packets:
+4. In `h2`'s XTerm, start the server that captures packets:
    ```bash
    ./receive.py
-   ```
-4. in `h22`'s XTerm, start the iperf UDP server:
+   ```  
+5. in `h22`'s XTerm, start the iperf UDP server:
    ```bash
    iperf -s -u
    ```
-5. In `h1`'s XTerm, send one packet per second to `h2` using send.py
+
+**Note:** Since we want packets sent by `h1` to at least sometimes experience long packet queues in switch `s1`, its important to have a synchronized and simultaneous flow of packets, which will be done via 6th and 7th step.<br> Hence, at first, type both (6th & 7th) commands together in the respective Xterm windows and later press the Enter button (`h1` and then `h11`) immediately for both Xterm windows, to clog up the traffic effectively.
+
+   
+6. In `h1`'s XTerm, send one packet per second to `h2` using send.py
 say for 30 seconds:
    ```bash
    ./send.py 10.0.2.2 "P4 is cool" 30
    ```
    The message "P4 is cool" should be received in `h2`'s xterm,
-6. In `h11`'s XTerm, start iperf client sending for 15 seconds
+7. In `h11`'s XTerm, start iperf client sending for 15 seconds
    ```bash
    iperf -c 10.0.2.22 -t 15 -u
    ```
-7. At `h2`, the `ipv4.tos` field (DiffServ+ECN) is always 1
-8. type `exit` to close each XTerm window
+8. At `h2`, the `ipv4.tos` field (DiffServ+ECN) is always 1
+9. 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.
@@ -158,7 +162,7 @@ and just print the `tos` values `grep tos h2.log` in a separate window
 
 ### Food for thought
 
-How can we let the user configure the threshold?
+How can we let the user configure the threshold? (lookout in the top segment of p4 code or search for ECN_THRESHOLD )
 
 ### Troubleshooting
 
@@ -183,6 +187,16 @@ There are several ways that problems might manifest:
    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 in `topology.json`
+5. When running the traffic from `h1` to `h2` at 1 packet/second (send.py), note that this flow only lasts for 30 seconds. Therefore, it is crucial to start the high-rate traffic from `h11` to 
+   `h22` within **10 seconds** after starting the `h1` to `h2` flow.<br>  
+   If you wait the full 30 seconds (or close to it) before starting the high-rate traffic, the `h1` to `h2` flow will have already finished. In that case, it will not experience queuing delay, 
+   which could significantly change the expected results of your experiment i.e. `tos` value will remain `0x1`, and would never hit the expected `0x3` spike.
+   
+   To overcome this issue, use a larger duration value (e.g., 60) when calling `send.py`, to make the `h1` → `h2` flow last longer and increase the chance of overlapping with congestion from the 
+   high-rate flow i.e.    
+   ```bash
+   ./send.py 10.0.2.2 "P4 is cool" 60
+   ```
 
 #### Cleaning up Mininet