4 ms·

Total networking layman here. Am I understanding correctly the author uses a bit outdated example to show how quic can be theoretically faster for the initial c

by a_imho 10y ago

Total networking layman here. Am I understanding correctly the author uses a bit outdated example to show how quic can be theoretically faster for the initial connection while at the same time admits TCP fast open will reduce RTT? Also, with quic you actually receive 10% less data, but then saying a packet retransmit would take longer is not convincing to me. It should depend on how many packets are lost (on average) like 1 RTT = 20 UDP packets * 10% thus using quic/FEC on a stable network would actually decrease performance and drive up data plan costs. Also I don't see why a few packets matter that much to actually introduce a new networking stack with all of its own problems from e.g. increasing complexity. Just opened a news site on desktop, it was over 2 MB in size without the ads. If we should be concerned about percentages, we would surely be cutting down on the JS/CSS bloat first.

signa11 10y ago
check out QUIC: Design Document and Specification Rationale available at https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqs... for way more detailed description of what is going on and why...
k__ 10y ago
TCP has a few ugly problems that enhance each other. First you need to wait till all the handshaking stuff is done and then you can't even transmit with full speed. If you use UDP, you have to implement much of the TCP stuff yourself. But you can use the experience with web connections to implement it and leave out things that weren't needed.
- wtallis 10y ago
  > [...] and then you can't even transmit with full speed. This is nothing specific to TCP. "Full speed" is a fundamentally unknowable quantity in advance in the general case. It varies with time and endpoints. If you try to start a connection transmitting at the full speed of your first-hop link (the only one you have any chance of knowing the bandwidth of), you just put the congestion control a hop or more away from the box that has the information necessary to do it right. QUIC can have an advantage in re-using a connection in situations where multiple sequential TCP connections might have been made. Probing for link bandwidth fewer times is not the same as not having to probe for link bandwidth. And HTTP/2 has already addressed the most common case of this without abandoning TCP.
  - k__ 10y ago
    Ah, didn't know this. I thought this was bacause of the tsc slow start
exDM69 10y ago
TCP is a stream oriented protocol, the bytes must arrive in the order they were sent. Packet loss will cause going back in the sliding window. For sending an entire file over the network, you don't care which order the packets arrive. If a packet goes missing in the middle, there's no reason to stop transmitting and receiving later packets. Just re-transmit the missing piece from the middle at any point in the future. This is assuming that the entire file is stored on the sender's side. edit: the protocol design document (linked in this thread) also mentions multiplexing many "connections" using the same sockets in SPDY. With TCP, a lost packet in any of the mux'ed connections will slow down the others. Using UDP instead of TCP allows increasing bandwidth and decreasing latency. Website bloat is an orthogonal issue and should be addressed but QUIC can mitigate the problems a little.

by a_imho 10y ago

signa11 10y ago

check out QUIC: Design Document and Specification Rationale available at https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqs... for way more detailed description of what is going on and why...

k__ 10y ago

TCP has a few ugly problems that enhance each other. First you need to wait till all the handshaking stuff is done and then you can't even transmit with full speed. If you use UDP, you have to implement much of the TCP stuff yourself. But you can use the experience with web connections to implement it and leave out things that weren't needed.

wtallis 10y ago
> [...] and then you can't even transmit with full speed. This is nothing specific to TCP. "Full speed" is a fundamentally unknowable quantity in advance in the general case. It varies with time and endpoints. If you try to start a connection transmitting at the full speed of your first-hop link (the only one you have any chance of knowing the bandwidth of), you just put the congestion control a hop or more away from the box that has the information necessary to do it right. QUIC can have an advantage in re-using a connection in situations where multiple sequential TCP connections might have been made. Probing for link bandwidth fewer times is not the same as not having to probe for link bandwidth. And HTTP/2 has already addressed the most common case of this without abandoning TCP.
- k__ 10y ago
  Ah, didn't know this. I thought this was bacause of the tsc slow start

exDM69 10y ago

TCP is a stream oriented protocol, the bytes must arrive in the order they were sent. Packet loss will cause going back in the sliding window. For sending an entire file over the network, you don't care which order the packets arrive. If a packet goes missing in the middle, there's no reason to stop transmitting and receiving later packets. Just re-transmit the missing piece from the middle at any point in the future. This is assuming that the entire file is stored on the sender's side. edit: the protocol design document (linked in this thread) also mentions multiplexing many "connections" using the same sockets in SPDY. With TCP, a lost packet in any of the mux'ed connections will slow down the others. Using UDP instead of TCP allows increasing bandwidth and decreasing latency. Website bloat is an orthogonal issue and should be addressed but QUIC can mitigate the problems a little.