From cd97bd888f64706d5e119001962f4a812efa3164 Mon Sep 17 00:00:00 2001 From: Simone Basso Date: Fri, 21 Jun 2024 11:41:55 +0200 Subject: [PATCH] x --- docs/design/dd-007-throttling.md | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/docs/design/dd-007-throttling.md b/docs/design/dd-007-throttling.md index e053682cb..54becfd1b 100644 --- a/docs/design/dd-007-throttling.md +++ b/docs/design/dd-007-throttling.md @@ -244,13 +244,11 @@ also the possibility of instrumenting the QUIC library to periodically collect snapshots about the receiver's state. However, in general, sender stats are much more useful to understand QUIC performance. This fact implies that we could instrument a QUIC library to observe the sender's state and gather information -about throttling uploads. (Yet, the whole design of Web Connectivity is not +about throttling uploads. + +Yet, the whole design of Web Connectivity is not such that we upload resources, therefore we would need to figure out whether -it is possible to overcome this fundamental limitation first.) - -In the same vein, our Web Connectivity methodology does not currently factor in -the possibility of measuring upload speed throttling for HTTP/1.1 and HTTP/2. However, -anecdotal evidence exists that some countries may throttle the upload path or just -have poor upstream connectivity towards interesting websites. A technique that -has sometimes been applied is that of including very large headers into the request -body, even though servers may not necessarily accept such headers. +it is possible to overcome this fundamental limitation for HTTP/1.1 and HTTP/2 +first. A technique that has sometimes been applied is that of including very +large headers into the request body, even though servers may not +necessarily accept such headers.