Draft: draft-ietf-quic-transport

Commentary: Fixing 
 changed the rules regarding what kind of packet an endpoint is allowed to send after receiving a non - ack - eliciting packet . The intention of that text used to be to prevent peers from getting stuck in an ACK - loop , but now the text says : Among others , this means that once an endpoint receives a non - ack - eliciting packet , it 's not allowed to send a packet containing only PADDING . This would be valuable for defeating traffic analysis . While it would be possible to hack your way out of this by sending a PING + PADDING packet , I 'm not sure if this was the intention of . 
 To me , the key phrase here is ' in response to ' . If you want to send PADDING for some other reason and the congestion controller allows it , then you can send it . 
 This feels editorial ... 
 I do n't intend to do anything about this one . As  notes , you can use other reasons to justify sending of anything , just do n't justify the sending on the basis of having received a non - ack - eliciting packet or you will get into the sort trouble that does n't end . 
 I think the text is clear that sending PADDING is allowed at any time . I 'm closing this with no action . 
 quic - transport draft 13.2.1 : An endpoint MUST NOT send a packet containing only an ACK frame in response to a non - ACK - eliciting packet ( one containing only ACK and/or PADDING frames ) , points out that this allows one to send an ACK+PADDING packet , which seems to violate the spirit of the rule . This loophole breaks . I believe this may be  if we all know what we meant . 
 Yes , it was intended that ACK should not elicit an ACK+PADDING packet . 
 I agree with this change , but I disagree that this is a satisfactory fix for . 
 This issue should have been 
 LGTM . Though all the " non - ACK - eliciting packets " is a bit of a mouth full .
Paragraph (version A):
Packets containing only ACK frames are not congestion controlled, so
there are limits on how frequently they can be sent.  An endpoint
MUST NOT send more than one ACK-frame-only packet in response to
receiving an ack-eliciting packet (one containing frames other than
ACK and/or PADDING).  An endpoint MUST NOT send a packet containing
only an ACK frame in response to a non-ack-eliciting packet (one
containing only ACK and/or PADDING frames), even if there are packet
gaps which precede the received packet.  Limiting ACK frames avoids
an infinite feedback loop of acknowledgements, which could prevent
the connection from ever becoming idle.  However, the endpoint
acknowledges non-ack-eliciting packets when it sends an ACK frame.
Paragraph (version B):
Packets containing only ACK frames are not congestion controlled, so
there are limits on how frequently they can be sent.  An endpoint
MUST NOT send more than one ACK-frame-only packet in response to
receiving an ack-eliciting packet.  An endpoint MUST NOT send a non-
ack-eliciting packet in response to a non-ack-eliciting packet, even
if there are packet gaps which precede the received packet.  Limiting
ACK frames avoids an infinite feedback loop of acknowledgements,
which could prevent the connection from ever becoming idle.  However,
the endpoint acknowledges non-ACK-eliciting packets when it sends an
ACK frame.