Merge pull request #28 from tfpauly/congestion_details

Editorial changes on congestion control

draft-pauly-quic-datagram.md

@@ -97,6 +97,9 @@ may allow loss recovery to occur more quickly for QUIC data.
 allowing applications to be aware of whether a datagram was successfully
 received.
 
+- QUIC datagrams are subject to QUIC congestion control, allowing
+applications to avoid implementing their own.
+
 These reductions in connection latency, and application insight into
 the delivery of datagrams, can be useful for optimizing audio/video
 streaming applications, gaming applications, and other real-time
@@ -242,13 +245,12 @@ dropped by the receiver if the receiver cannot process them.
 
 ## Congestion Control
 
-DATAGRAM frames are subject to a QUIC connection's congestion control.
-Specifically, if a DATAGRAM frame is enqueued to be sent by the application,
-but sending a packet with this frame is not allowed by the congestion control
-window as specified in {{!I-D.ietf-quic-recovery}}, the packet cannot be sent.
-The sender implementation MUST either drop the frame without sending it
-(at which point it MAY notify the application) or else delay sending the frame
-until the window opens.
+DATAGRAM frames employ the QUIC connection's congestion controller. As a
+result, a connection may be unable to send a DATAGRAM frame generated by the
+application until the congestion controller allows it
+{{!I-D.ietf-quic-recovery}}. The sender implementation MUST either delay
+sending the frame until the controller allows it or drop the frame without
+sending it (at which point it MAY notify the application).
 
 Implementations can optionally support allowing the application to specify
 a sending expiration time, beyond which a congestion-controlled DATAGRAM