3 ms·

How do you define "fixed"? Quic still defines per stream plus per connection flow control windows, on top of the lower level congestion control algorithm.

xxpor 6y ago
Does it not use UDP?
- mobilio 6y ago
  It uses UDP because simply can't change all TCP infrastructure worldwide. Example - i'm still using on some place router Linksys WRT54GL with kernel 2.4 that is almost 15 years old. Because device still works and there was low network requirements.
  - xxpor 6y ago
    Sure, I totally get that. But my point is UDP doesn't have any underlying congestion control you have to fight.
- Matthias247 6y ago
  Right - it does. My point was that Quic still has 2 layers which determine the amount of data that is sent to peers. On the lower level, there is a congestion controller - which can be like Cubic, New Reno, BBR, etc. This part does not know anything about Quic streams yet. On a higher level you have the Quic streams, which carry user data. These are subject to flow control windows, and there also exists a shared per-connection window. Depending on the implementation the layers might not be very much aware of each other, which can also lead to imperfect utilization. That said the situation is obviously still different than with TCP, since the congestion controller does not limit the amount of user data but packets in general (which includes retransmits, etc). So the outcomes will certainly be different than what we observe with HTTP/2.
mobilio 6y ago
HTTP/3 is built with TLS 1.3 and have faster handshake. Second - HTTP/3 define some "idle" state of connections like 30 seconds or even more. So you can download something and then nothing. Here HTTP 0.9/1.0/1.1 and /2 closes connections. On HTTP/3 it was set to idle - nor closed. And let say after 15 sec you need new resource. On HTTP/3 connection flow continue where was stopped. On previous versions you must make TLS handshake and then to make new request. This mean performance penalty because congestion control will start with values similar to 0.
- Matthias247 6y ago
  This is pretty much unrelated to the discussion earlier on (which was about the interaction of different flow control mechansisms). But nevertheless one answer that tries to clear up some misunderstandings: You can reuse connections with every HTTP version up from HTTP/1.1. The main difference between HTTP/1.1 and HTTP/2 and /3 is that you can't make concurrent requests on a single connection with HTTP/1.1, but you can with /2 and /3. For how long a connection will stay open after a request will be determined by keepalive settings on the client and server side. All HTTP versions up from 1.1 allow you not to use a connection for 30s and then make another request.

xxpor 6y ago

Does it not use UDP?

mobilio 6y ago
It uses UDP because simply can't change all TCP infrastructure worldwide. Example - i'm still using on some place router Linksys WRT54GL with kernel 2.4 that is almost 15 years old. Because device still works and there was low network requirements.
- xxpor 6y ago
  Sure, I totally get that. But my point is UDP doesn't have any underlying congestion control you have to fight.
Matthias247 6y ago
Right - it does. My point was that Quic still has 2 layers which determine the amount of data that is sent to peers. On the lower level, there is a congestion controller - which can be like Cubic, New Reno, BBR, etc. This part does not know anything about Quic streams yet. On a higher level you have the Quic streams, which carry user data. These are subject to flow control windows, and there also exists a shared per-connection window. Depending on the implementation the layers might not be very much aware of each other, which can also lead to imperfect utilization. That said the situation is obviously still different than with TCP, since the congestion controller does not limit the amount of user data but packets in general (which includes retransmits, etc). So the outcomes will certainly be different than what we observe with HTTP/2.

mobilio 6y ago

HTTP/3 is built with TLS 1.3 and have faster handshake. Second - HTTP/3 define some "idle" state of connections like 30 seconds or even more. So you can download something and then nothing. Here HTTP 0.9/1.0/1.1 and /2 closes connections. On HTTP/3 it was set to idle - nor closed. And let say after 15 sec you need new resource. On HTTP/3 connection flow continue where was stopped. On previous versions you must make TLS handshake and then to make new request. This mean performance penalty because congestion control will start with values similar to 0.

Matthias247 6y ago
This is pretty much unrelated to the discussion earlier on (which was about the interaction of different flow control mechansisms). But nevertheless one answer that tries to clear up some misunderstandings: You can reuse connections with every HTTP version up from HTTP/1.1. The main difference between HTTP/1.1 and HTTP/2 and /3 is that you can't make concurrent requests on a single connection with HTTP/1.1, but you can with /2 and /3. For how long a connection will stay open after a request will be determined by keepalive settings on the client and server side. All HTTP versions up from 1.1 allow you not to use a connection for 30s and then make another request.