Draft: draft-ietf-quic-recovery

Commentary: Also changes NewReno to Reno because of pedantry ( not from  ) . 
 I think this is design , so it 's in limbo at the moment . Also , I need to re - read RFC8085 and ensure that MUST is viable . 
 Yup , the issue this address should be marked design . 
 The proposed commit says : " If an endpoint uses a different controller than that specified in this document , it MUST conform to the congestion control guidelines specified in { { ! RFC8085 } } . " RFC 8085 's section 3.1 appears to be the salient piece here , along with its reference to RFC 2914 . A more direct pointer might be useful . I also note that you have a MUST pointer to what amounts to a set of guidelines which are all SHOULD or RECOMMENDED , which is a level lower . The result is likely to be a little less strict than the naive reader might believe . 
 If there are MUSTs we believe are important from 8085 and apply to QUIC and are not already MUSTs in other portions of the QUIC specs , I 'd suggest we move those explicitly into this document and then either non - normatively reference 8085 or use a SHOULD for the rest of the document ? 
 I 'd always believed the intent was for the design for QUIC to fall within the scope of BCP145 , which provides the check - list of SHOULD and MUST requirements for UDP - based protocol mechanisms . Moving blocks of requirements language and surrounding context that relate to QUIC from BCP145 , seems like creating a lot of work , with very little positive outcomes . Citing this as normative to an implementation seems like it avoids much of this , and also much reduces the need for detailed checking in last call . Is there a reason to " move " to the QUIC document itself ? 
 I suspect that  is looking to create a stronger requirement for congestion control than BCP145 has .  is full of SHOULD , with no MUST . 
 RFC8085 has basically only SHOULDs because it tries to cover all kind of cases of UDP - based protocols . So if we can be more specific for QUIC that would be good . However , QUIC is also meant as a general purpose protocol so I 'm not sure we can . I think it is most important to have a pointer to RFC8085 . Not sure if any other requirements can be made ( other than do n't break the Internet ) unfortunately ... 
 Rabbit - hole warning . There is n't a real set of requirements anywhere for congestion control articulated any better than what 's in 8085 .  and I looked through existing documents , realized that we 're lacking here , leading to  's . I do n't think it makes sense to move text out of 8085 here . The entire point of a normative reference is so we do n't do that . Is there any specific text that you have in mind , The MUST here is so that an implementer is required to consider the UDP guidelines in 8085 , but each one of those SHOULDs is evaluated individually . Simply saying SHOULD conform to 8085 is quite different than that . 
  , can I read your reply to  as " I agree , but there are no MUSTs we want to include , since the SHOULDs is BCP145 are the best we can do " ? If so , maybe the right thing to do is close this issue with just the more precise pointer . I do believe , however , it would then be better to recast the sentence to make the pronounce / antecedent clearer . For example : If an endpoint uses a different controller than that specified in this document , the chosen controller MUST conform to the congestion control guidelines specified in Section 3.1 of { { ! RFC8085 } } . There are other ways to phrase it , of course . That would alleviate my concern that a naive reader might believe that they could roll their own behavior ; that 's particularly worrying when the very first item in 3.1 allows this : If an application or protocol chooses not to use a congestion- controlled transport protocol , it SHOULD control the rate at which it sends UDP datagrams to a destination host , in order to fulfill the requirements of [ RFC2914 ] . It 's all too easy to read that as allowing simple packet - pacing to suffice for QUIC here . If the reader knows that they have to pick a known congestion controller , we 'll be better off . 
 Thanks ,  , I take your point and your suggestion is a good one . I 've reworded it as you suggested . 
 Thanks for the suggestion  . To confirm , by citing the section you 're normatively citing only that section , not the entire doc . My concern is that 8085 is fairly long , and a good bit of it does n't really pertain to QUIC . 
 The docs call out that the design is based on ( new)Reno . That is good and suitable for a PS . I have no problem here . However , there are several places where the text is very permissive " MAY ... " that suggests the PS can implement this or anything else . This combination seems awkward for a PS . I 'd hoped that we could allow experimentation with new CC 's but say SHOULD use an IETF - specified congestion control method , or something text close to that , and change the MAYs into something more helpful . I think this is an easy piece of text to get correct . 
 Please check appendices , e.g. " Constants used in loss recovery are based on a combination of RFCs , papers , and common practice . Some may need to be changed or negotiated in order to better suit a variety of environments . " that final sentence needs thought . 
 If this goes into late - stage , it should be design . 
 I would like to suggest that RFC8085 is normative . This RFC was written as BCP for UDP usage , and QUIC implementations need to comply with that or describe the difference and reach consensus about why it differs . 
 I see RFC 8085 in the list of normative references already . Was there something in particular that you think we should be explicitly depending on ? 
 ... Or , I realize now , does this comment apply to the recovery document ? 
 This was intended for the recovery doc , but maybe the fact transport already normatively references 8085 makes this decision easier ? 
  , the comment still applies then . What specific items in RFC 8085 would this need to depend on ? We do n't just add normative dependencies without that . 
 Yes , this comment targets recovery . I think the editors can propose text referring to the draft - there is no intended change to the technical spec . 
 I 'm sorry , I perhaps was n't clear . This is not stated as an issue . " This document does n't cite X " is n't an issue . Is there something specific that is in RFC 8085 that is needed to address an issue ? 
 I suspect what I have in PR 3248 ( ) ought to address this . I think  wanted to have normative reference for congestion control conformance . 
 Yes , and WFM - see single comment on the PR . 
 If this goes into late - stage , it should be design .
Paragraph (version A):
QUIC's congestion control is based on TCP NewReno RFC6582.  NewReno
is a congestion window based congestion control.  QUIC specifies the
congestion window in bytes rather than packets due to finer control
and the ease of appropriate byte counting RFC3465.
Paragraph (version A):
QUIC hosts MUST NOT send packets if they would increase
bytes_in_flight (defined in vars-of-interest) beyond the available
congestion window, unless the packet is a probe packet sent after a
PTO timer expires, as described in pto.
Paragraph (version A):
Implementations MAY use other congestion control algorithms, such as
Cubic RFC8312, and endpoints MAY use different algorithms from one
another.  The signals QUIC provides for congestion control are
generic and are designed to support different algorithms.
Paragraph (version B):
This document specifies a Reno congestion controller for QUIC
RFC6582.
Paragraph (version B):
The signals QUIC provides for congestion control are generic and are
designed to support different algorithms.  Endpoints can unilaterally
choose a different algorithm to use, such as Cubic RFC8312.
Paragraph (version B):
If an endpoint uses a different controller than that specified in
this document, the chosen controller MUST conform to the congestion
control guidelines specified in Section 3.1 of RFC8085.
Paragraph (version B):
The algorithm in this document specifies and uses the controller's
congestion window in bytes.
Paragraph (version B):
An endpoint MUST NOT send a packet if it would cause bytes_in_flight
(see vars-of-interest) to be larger than the congestion window,
unless the packet is sent on a PTO timer expiration (see pto).