Subject: New Issue: Loss detection: Overloading of is_retransmittable

From: Magnus Westerlund <[email-masked]>
Date: Tue, 6 Jun 2017 10:11:10 +0200

Hi,

In draft-ietf-quic-recovery-03 there appear to me to be an overloading 
of the use of the "is_retransmittable" flag. It appears to be used both 
for the purpose to indicate if there is a frame that can and need be 
retransmitted and if that frame should be counted as lost and impact 
congestion control. I think these two purposes should be separated and 
clarified as being two different ones. The reason is that if we create 
extensions that will not require retransmission of frames but needs to 
be included in the congestion control response a significant rewrite 
would be needed. I also think it would clarify things for some of the 
control frames also if they should be included or not, even if not 
regularly retransmitted.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Ian Swett <[email-masked]>
Date: Tue, 6 Jun 2017 07:36:47 -0400

Thanks for the thorough review and filing in issue for this.

On Tue, Jun 6, 2017 at 4:11 AM, Magnus Westerlund <
[email-masked]> wrote:

> Hi,
>
> In draft-ietf-quic-recovery-03 there appear to me to be an overloading of
> the use of the "is_retransmittable" flag. It appears to be used both for
> the purpose to indicate if there is a frame that can and need be
> extensions that will not require retransmission of frames but needs to be
> included in the congestion control response a significant rewrite would be
> needed. I also think it would clarify things for some of the control frames
> also if they should be included or not, even if not regularly retransmitted.
>
> Cheers
>
> Magnus Westerlund
>