You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I used quiche as QUIC client to contact a quic-go server.
The quic-go server sends an instant acknowledgment to the ClientHello, but then is slow to follow up the handshake and holds a large certificate.
Scenario:
The client correctly uses the estimated RTT to send probe packets in the form of Initials with PING frames.
Once the server continues to reply with the first batch of the Handshake packets (PKN: 0 and 1; Wireshark no 10, 11) after a long delay, these are acknowledged by quiche.
However, subsequent Handshake packets (PKN 2 and 3 of the server; Wireshark no 12, 14), are dropped by quiche.
I believe the reason for dropping packets 12 and 14 is that they contain Initial ACKs, for which the keys have already been discarded (see client-server log: dropped epoch state).
quiche seems to drop the entire UDP datagram, which might contain additional QUIC packets.
Dropping the information requires an additional round trip, to detect and re-transmit the data (Wireshark no. 18, 20).
This can also be observed in Qlog. Here, the Handshake packets (PKN: 2 and 3) are missing.
Expected behavior:
Do not drop entire datagrams.
Since the header protection does not cover the long packet type and length fields, it should be possible to skip the contained Initial, but parse coalesced packets as long as the keys are available, which would render the client more efficient.
I used quiche as QUIC client to contact a quic-go server.
The quic-go server sends an instant acknowledgment to the ClientHello, but then is slow to follow up the handshake and holds a large certificate.
Scenario:
The client correctly uses the estimated RTT to send probe packets in the form of Initials with PING frames.
Once the server continues to reply with the first batch of the Handshake packets (PKN: 0 and 1; Wireshark no 10, 11) after a long delay, these are acknowledged by quiche.
However, subsequent Handshake packets (PKN 2 and 3 of the server; Wireshark no 12, 14), are dropped by quiche.
Client log:
I believe the reason for dropping packets 12 and 14 is that they contain Initial ACKs, for which the keys have already been discarded (see client-server log:
dropped epoch state
).quiche seems to drop the entire UDP datagram, which might contain additional QUIC packets.
Dropping the information requires an additional round trip, to detect and re-transmit the data (Wireshark no. 18, 20).
This can also be observed in Qlog. Here, the Handshake packets (PKN: 2 and 3) are missing.
Expected behavior:
Do not drop entire datagrams.
Since the header protection does not cover the long packet type and length fields, it should be possible to skip the contained Initial, but parse coalesced packets as long as the keys are available, which would render the client more efficient.
What do you think?
Attached is the pcap, qlog and client output.
quiche-coalesced-packets.pcapng.gz
client-3f2d2ea78cab71732a6858b967c0293e3944b8dd.qlog.gz
client-log.txt
The text was updated successfully, but these errors were encountered: