4 ms·

I have a problem with QUIC. As everyone implementing this knows, TCP and UDP headers have very similar structure and the difference mostly lies within different

I have a problem with QUIC. As everyone implementing this knows, TCP and UDP headers have very similar structure and the difference mostly lies within different treatment of packets in these two. QUIC will increase the size of transport and this affects capped customers. Why is QUIC chosen despite this major flaw? :Not everyone uses gigabit fiber:

deleted 8y ago
[deleted]
mholt 8y ago
I don't have hard measurements, but maybe fewer round trips still results in a net decrease in transfer. Also clients don't have to use QUIC.
nabla9 8y ago
I think the correct comparison is QUIC vs TCP+TLS.
- deleted 8y ago
  [deleted]
- ldng 8y ago
  And vs SCTP. A deep dive impartial comparison at different usecase/workload would be great.
zAy0LfpBZLC8mAC 8y ago
> QUIC will increase the size of transport and this affects capped customers. Will it? The TCP header is 20 bytes, the UDP header is 8 bytes. And in as far as packets are bigger, will it actually cause more traffic? For example, you have muliplexing of streams over one connection without head of line blocking, while with HTTP over TCP you need multiple TCP connections and thus multiple TLS connections for that, for example. Also, QUIC allows you to change UDP endpoints without the need to establish a new connection. I wouldn't be so sure it needs more bandwidth. Now, arguably, building directly on IP would be better, but that is unfortunately an option that ISPs and other manufacturers and operators of middleboxes have destroyed, so I think you can't really blame QUIC for that. There really is no realistic way to evolve beyond the limitations of TCP unless you build on UDP. If QUIC succeeds and if we manage to move to IPv6 and get rid of NAT, though, I guess there might be a chance to one day see "QUIC on IP"--as far as the protocol is concerned, it should be trivial to adopt it for direct IP transport.
benkuhn 8y ago
It looks like the opposite to me? TCP minimum header is 20 bytes.[1] QUIC "short header" (after key negotiation) looks like it can go down to 2 bytes for non-roaming connections with a 1-byte packet number, if the server allows the omit_connection_id, and 10 bytes otherwise.[2] Add the UDP header (8 bytes[3]) and you're at 10-21 bytes. So if you both supply a connection ID and a 4-byte packet number you're just barely at the same transport overhead as TCP; otherwise it's less. (The QUIC "long header" is longer but that's a fixed cost and shouldn't matter too much for overhead.) Or am I missing something? [1]: https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure https://en.wikipedia.org/wiki/Transmission_Control_Protocol#... [2]: https://tools.ietf.org/html/draft-ietf-quic-transport-08#section-5.2 https://tools.ietf.org/html/draft-ietf-quic-transport-08#sec... [3]: https://en.wikipedia.org/wiki/User_Datagram_Protocol#Packet_structure https://en.wikipedia.org/wiki/User_Datagram_Protocol#Packet_...
Arnt 8y ago
Because it's not obviously a flaw, and since it's not obvious you'll have to supply arguments if you want people to believe it's a major flaw. QUIC is supposed to send fewer packets for the same payload, at least that's what I've heard. I don't follow it closely. Assuming that's true, if you want people to believe that QUIC packets are bigger and that the increased size more than compensates for their reduced number, you'll have to supply arguments. Packet traces for a few typical connections would be good arguments. Assuming it's false, you'll need much the same kind of argument. (FYI I've written ten RFCs and like to think I've learned the RFC processes by now.)
deleted 8y ago
[deleted]

deleted 8y ago

[deleted]

mholt 8y ago

I don't have hard measurements, but maybe fewer round trips still results in a net decrease in transfer. Also clients don't have to use QUIC.

nabla9 8y ago

I think the correct comparison is QUIC vs TCP+TLS.

deleted 8y ago
[deleted]
ldng 8y ago
And vs SCTP. A deep dive impartial comparison at different usecase/workload would be great.

zAy0LfpBZLC8mAC 8y ago

> QUIC will increase the size of transport and this affects capped customers. Will it? The TCP header is 20 bytes, the UDP header is 8 bytes. And in as far as packets are bigger, will it actually cause more traffic? For example, you have muliplexing of streams over one connection without head of line blocking, while with HTTP over TCP you need multiple TCP connections and thus multiple TLS connections for that, for example. Also, QUIC allows you to change UDP endpoints without the need to establish a new connection. I wouldn't be so sure it needs more bandwidth. Now, arguably, building directly on IP would be better, but that is unfortunately an option that ISPs and other manufacturers and operators of middleboxes have destroyed, so I think you can't really blame QUIC for that. There really is no realistic way to evolve beyond the limitations of TCP unless you build on UDP. If QUIC succeeds and if we manage to move to IPv6 and get rid of NAT, though, I guess there might be a chance to one day see "QUIC on IP"--as far as the protocol is concerned, it should be trivial to adopt it for direct IP transport.

benkuhn 8y ago

It looks like the opposite to me? TCP minimum header is 20 bytes.[1] QUIC "short header" (after key negotiation) looks like it can go down to 2 bytes for non-roaming connections with a 1-byte packet number, if the server allows the omit_connection_id, and 10 bytes otherwise.[2] Add the UDP header (8 bytes[3]) and you're at 10-21 bytes. So if you both supply a connection ID and a 4-byte packet number you're just barely at the same transport overhead as TCP; otherwise it's less. (The QUIC "long header" is longer but that's a fixed cost and shouldn't matter too much for overhead.) Or am I missing something? [1]: https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure https://en.wikipedia.org/wiki/Transmission_Control_Protocol#... [2]: https://tools.ietf.org/html/draft-ietf-quic-transport-08#section-5.2 https://tools.ietf.org/html/draft-ietf-quic-transport-08#sec... [3]: https://en.wikipedia.org/wiki/User_Datagram_Protocol#Packet_structure https://en.wikipedia.org/wiki/User_Datagram_Protocol#Packet_...

Arnt 8y ago

Because it's not obviously a flaw, and since it's not obvious you'll have to supply arguments if you want people to believe it's a major flaw. QUIC is supposed to send fewer packets for the same payload, at least that's what I've heard. I don't follow it closely. Assuming that's true, if you want people to believe that QUIC packets are bigger and that the increased size more than compensates for their reduced number, you'll have to supply arguments. Packet traces for a few typical connections would be good arguments. Assuming it's false, you'll need much the same kind of argument. (FYI I've written ten RFCs and like to think I've learned the RFC processes by now.)

deleted 8y ago

[deleted]