Don't retransmit old MAX_STREAM_DATA and MAX_DATA

[janaiyengar]

Closes #806

[ekr]

I am starting to think it's a mistake to phrase this in terms of frames at all. It's the information you want to retransmit. It seems like there are lots of cases where you would be constantly updating your willingness to receive (if, say, you want to continue offering a given buffer size) but you only transmit occasionally. If I have to retransmit, why would I want to advertise stale data rather than the most current data.

[ianswett]

Agreed. Anytime the words "retransmit frame" appear in the text, it's probably an error. And the phrase 'retransmit packet' should occur twice: Once to tell you not to do it and once to tell you can do it for connection close packets only.

[mikkelfj]

What if the connection close packet has other content? Kind Regards, Mikkel Fahnøe Jørgensen On 29 September 2017 at 14.37.26, ianswett (notifications@github.com) wrote: *@ianswett* commented on this pull request. ------------------------------ In draft-ietf-quic-transport.md <#807 (comment)>:

@@ -2420,6 +2420,12 @@ When a packet is detected as lost, the sender re-sends any frames as necessary:

* STOP_SENDING frames MUST be retransmitted, unless the stream has become closed in the appropriate direction. See {{solicited-state-transitions}}. +* The most recent MAX_STREAM_DATA frame for a stream MUST be retransmitted. Any + previous unacknowledged MAX_STREAM_DATA frame for the same stream SHOULD NOT + be retransmitted since a newer MAX_STREAM_DATA frame for a stream obviates the + need for delivering older ones. Similarly, the most recent MAX_DATA frame MUST + be retransmitted; previous unacknowledged ones SHOULD NOT be retransmitted. Agreed. Anytime the words "retransmit frame" appear in the text, it's probably an error. And the phrase 'retransmit packet' should occur twice: Once to tell you not to do it and once to tell you can do it for connection close packets only. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#807 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALzN2jEfOdKqCcVhKBQTurnDVsWUdX_ks5snOSFgaJpZM4Pn6qc> .

[ianswett]

I wouldn't recommend putting other content with a connection close, but I don't think it'd cause issues to retransmit a connection close packet that happened to have other content in it.

…

On Fri, Sep 29, 2017 at 9:36 AM, MikkelFJ ***@***.***> wrote: What if the connection close packet has other content? Kind Regards, Mikkel Fahnøe Jørgensen On 29 September 2017 at 14.37.26, ianswett ***@***.***) wrote: ***@***.**** commented on this pull request. ------------------------------ In draft-ietf-quic-transport.md <#807 (comment)>: > @@ -2420,6 +2420,12 @@ When a packet is detected as lost, the sender re-sends any frames as necessary: * STOP_SENDING frames MUST be retransmitted, unless the stream has become closed in the appropriate direction. See {{solicited-state-transitions}}. +* The most recent MAX_STREAM_DATA frame for a stream MUST be retransmitted. Any + previous unacknowledged MAX_STREAM_DATA frame for the same stream SHOULD NOT + be retransmitted since a newer MAX_STREAM_DATA frame for a stream obviates the + need for delivering older ones. Similarly, the most recent MAX_DATA frame MUST + be retransmitted; previous unacknowledged ones SHOULD NOT be retransmitted. Agreed. Anytime the words "retransmit frame" appear in the text, it's probably an error. And the phrase 'retransmit packet' should occur twice: Once to tell you not to do it and once to tell you can do it for connection close packets only. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#807 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ AALzN2jEfOdKqCcVhKBQTurnDVsWUdX_ks5snOSFgaJpZM4Pn6qc> . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#807 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATJJcf4itEavsPoJrGpBJYoWJoHkwITeks5snPJDgaJpZM4Pn6qc> .

[martinthomson]

As Ian says, don't put anything else in the packet with CONNECTION_CLOSE. There are a few things that I would put in, but only maybe: RST_STREAM (so that the receiver can identify the stream that triggered the error), and PADDING.

[martinthomson]

Taking this for now, on the understanding that we want to properly fix this later.