Update README

README.md

@@ -6,10 +6,13 @@ need for retransmissions, thereby increasing the quality of the connection. In t
 
 For our experiments, we used a client-server file-download scenario. On each interface, we used netem to control the bandwidth, loss rate, and latency with values of 50Mbit/s, .1%, and 50ms, respectively. These values were chosen due to being within the range of Starlink network conditions as shown by Mohan et al.[^10]. Each test was repeated 50 times. Seen in the figures below are the file download times from 1MB, 10MB, and 20MB files, respectively. The trend derived from these figures is that the larger the file size, the larger the discrepancy is between the median times of retransmission-only QUIC and FEC-based QUIC. This result can largely be attributed to the fact that in addition to the 1.5x overhead caused from the two-thirds coding rate, a large amount of spurious retransmissions occur. This is because with a packet-based loss detection threshold of 3 packets as defined in the QUIC loss recovery document[^11], spurious retransmission may commonly occur as the packet has been recovered too late. Consequently, this partly explains why the 10MB example has less of a discrepancy between FEC and non-FEC versions as there is simply less time for spurious retransmissions to occur. Another reason may also be because algorithms like slow-start play outsized roles during very short connections and overshadow the impacts of FEC. Although disappointing, these results are consistent with those from François Michel as seen in the figure below. Using network conditions derived from Rula et al.[^8], Michel also showed how small file sizes showed less of a median DCT discrepancy than with larger files.
 
-<img src="docs/starlink_1MB.png" alt="Download Completion Time (DCT) with .1% Constant Loss for 1MB File" width=303 height=124>
-<img src="docs/starlink_10MB.png" alt="Download Completion Time (DCT) with .1% Constant Loss for 10MB File" width=303 height=124>
-<img src="docs/starlink_20MB.png" alt="Download Completion Time (DCT) with .1% Constant Loss for 20MB File" width=303 height=124>
-<img src="docs/rs-vs-quic.png" alt="" width=303 height=124>
+![Download Completion Time (DCT) with .1% Constant Loss for 1MB File](docs/starlink_1MB.png)
+
+![Download Completion Time (DCT) with .1% Constant Loss for 10MB File](docs/starlink_10MB.png)
+
+![Download Completion Time (DCT) with .1% Constant Loss for 20MB File](docs/starlink_20MB.png)
+
+![François Michel Throughput Measurements](docs/rs-vs-quic.png)
 
 [^1]: [RFC 9000](https://www.rfc-editor.org/info/rfc9000)
 [^2]: [RFC 791](https://www.rfc-editor.org/info/rfc791)
@@ -23,14 +26,6 @@ For our experiments, we used a client-server file-download scenario. On each int
 [^10]: [Starlink measurements](http://dx.doi.org/10.1145/3589334.3645328)
 [^11]: [RFC 9002](https://www.rfc-editor.org/info/rfc9002)
 
-quic-go is an implementation of the QUIC protocol ([RFC 9000](https://datatracker.ietf.org/doc/html/rfc9000), [RFC 9001](https://datatracker.ietf.org/doc/html/rfc9001), [RFC 9002](https://datatracker.ietf.org/doc/html/rfc9002)) in Go. It has support for HTTP/3 ([RFC 9114](https://datatracker.ietf.org/doc/html/rfc9114)), including QPACK ([RFC 9204](https://datatracker.ietf.org/doc/html/rfc9204)).
-
-In addition to these base RFCs, it also implements the following RFCs: 
-* Unreliable Datagram Extension ([RFC 9221](https://datatracker.ietf.org/doc/html/rfc9221))
-* Datagram Packetization Layer Path MTU Discovery (DPLPMTUD, [RFC 8899](https://datatracker.ietf.org/doc/html/rfc8899))
-* QUIC Version 2 ([RFC 9369](https://datatracker.ietf.org/doc/html/rfc9369))
-* QUIC Event Logging using qlog ([draft-ietf-quic-qlog-main-schema](https://datatracker.ietf.org/doc/draft-ietf-quic-qlog-main-schema/) and [draft-ietf-quic-qlog-quic-events](https://datatracker.ietf.org/doc/draft-ietf-quic-qlog-quic-events/))
-
 ## Using QUIC
 
 ### Running a Server
@@ -154,4 +149,14 @@ See the [example client](example/client/main.go). Use a `http3.RoundTripper` as
 http.Client{
   Transport: &http3.RoundTripper{},
 }
-```
+```
+
+## Supported RFCs
+
+quic-go is an implementation of the QUIC protocol ([RFC 9000](https://datatracker.ietf.org/doc/html/rfc9000), [RFC 9001](https://datatracker.ietf.org/doc/html/rfc9001), [RFC 9002](https://datatracker.ietf.org/doc/html/rfc9002)) in Go. It has support for HTTP/3 ([RFC 9114](https://datatracker.ietf.org/doc/html/rfc9114)), including QPACK ([RFC 9204](https://datatracker.ietf.org/doc/html/rfc9204)).
+
+In addition to these base RFCs, it also implements the following RFCs: 
+* Unreliable Datagram Extension ([RFC 9221](https://datatracker.ietf.org/doc/html/rfc9221))
+* Datagram Packetization Layer Path MTU Discovery (DPLPMTUD, [RFC 8899](https://datatracker.ietf.org/doc/html/rfc8899))
+* QUIC Version 2 ([RFC 9369](https://datatracker.ietf.org/doc/html/rfc9369))
+* QUIC Event Logging using qlog ([draft-ietf-quic-qlog-main-schema](https://datatracker.ietf.org/doc/draft-ietf-quic-qlog-main-schema/) and [draft-ietf-quic-qlog-quic-events](https://datatracker.ietf.org/doc/draft-ietf-quic-qlog-quic-events/))