tree a517f53f128f41dd7443d520c2cf8e685f075244
parent e483839a4384462276cf24295097c9d927bdfc09
author Junho Choi <1229714+junhochoi@users.noreply.github.com> 1589549286 -0700
committer GitHub <noreply@github.com> 1589549286 +0100
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJevpjmCRBK7hj4Ov3rIwAAdHIIAJ7hSWeqvFJui4NtY9DpbfCh
 vpe3wsej6pIJnSh7o04phNzlQV7Ze0yj60vk6andSsbUeeDrdWzGKFwbJ9BBX9XA
 3Vj2yRpHQr4gXM5YVwMsAV196SOLAPKRlDJuPQ/BCF7ZW2TYBwRCeehMUez7Elbm
 /D92d01c5z7a325bPuaiWm6OlDqdBn8sHfxyR1WQnatU4F47YwE7VxYulP3DEkrz
 S+9SuhppksAAQGHbp9bbR+o+nv8fM4wzJ0Pc6cMqDHapHqJ9ZkxOrCVsRbabnxBt
 TfiBMZC6JMMO4d5AvVKN7qqErxQpCEU6sVIenBvODlegcaglJeiGJfz6IGp1p04=
 =JJym
 -----END PGP SIGNATURE-----
 

retransmit MAX_STREAM_DATA frame if lost

Currently we are not retransmitting MAX_STREAM_DATA frame so
when the client lost the packet containing MAX_STREAM_DATA,
the server doesn't know it can read more when it hits the
flow limit. In this case we can't transfer more on this
stream.

quic-transport draft 13.3 says that MAX_STREAM_DATA need to be
sent with updated value when the frame is lost.

In this PR we only cares about MAX_STREAM_DATA frame but
it seems like many frame types are not retransmitted properly.

Losing MAX_STREAM_DATA frame is more problematic than other
frames such as MAX_DATA because it's stream specific so when
we lost it there is no chance for the server to know unless
retransmitted.

For example MAX_DATA is frequently updated with other streams,
so there is more chance for the server to know when it was
bundled with other packet.

How to reproduce: I am able to reproduce with the following
environment:
- Server: `cargo run --release --bin quiche-server -- --root . --listen 0.0.0.0:4433`
- Client: `cargo run --release --bin quiche-client -- --no-verify --dump-responses tmp/ -n 80`

Client is MacOS Host and Server is linux VM in the same machine.