Addressing issues raised by Ian Sweet on 180611. Editorial improvemen…

…ts, new psuedo code function.

draft-ietf-quic-recovery.md

@@ -417,9 +417,9 @@ to accelerate loss recovery.  The receiver SHOULD send an immediate ACK
 when it receives a new packet which is not one greater than the
 largest received packet number.
 
-Also, reception of an packet marked as ECN Congestion Experience
+Similarly, reception of an packet marked as ECN Congestion Experience
 (ECN-CE) SHOULD be acknowledged immediately to quicker react to
-congesiton events. Additional ECN-CE marks received during the same
+congestion events. Additional ECN-CE marks received during the same
 recovery period are also immediately acknowledged to correctly account
 for ECN-CE marks in the recovery period.
 
@@ -904,9 +904,9 @@ experimentation in using other response functions as discussed in
 
 The ACK_ECN frame defined in {{QUIC-TRANSPORT}} does not provide
 information on which of the newly acknowledged packets that
-was marked with ECN-CE. Therefore, it will be assumed that
-the congestion event starts at the highest acknowledged packet
-number.
+was marked with ECN-CE. Because newly received marks cause an ACK_ECN be sent
+immediately, is is assumed the congestion event starts at the highest newly
+acknowledged packet number.
 
 ## Slow Start
 
@@ -1009,12 +1009,11 @@ kLossReductionFactor (default 0.5):
 Variables required to implement the congestion control mechanisms
 are described in this section.
 
-ack_ce_cntr:
+previous_ecn_ce_ctr:
 : The ACK_ECN counter for ECN-CE marks previously processed. Used to
   determine when one or more packet acknowledged by the ACK_ECN frame
   was marked with ECN-CE.
 
-
 bytes_in_flight:
 : The sum of the size in bytes of all sent packets that contain at least
   one retransmittable frame, and have not been acked or declared
@@ -1044,7 +1043,7 @@ variables as follows:
    bytes_in_flight = 0
    end_of_recovery = 0
    ssthresh = infinite
-   ack_ce_cntr = 0
+   previous_ecn_ce_ctr = 0
 ~~~
 
 ### On Packet Sent
@@ -1063,7 +1062,7 @@ Invoked from loss detection's OnPacketAcked and is supplied with
 acked_packet from sent_packets.
 
 ~~~
-   InRecovery(packet_number)
+   InRecovery(packet_number):
      return packet_number <= end_of_recovery
 
    OnPacketAckedCC(acked_packet):
@@ -1085,19 +1084,24 @@ acked_packet from sent_packets.
 
 Invoked by an increment in the number of CE marked packets, as
 indicated by a newly received ACK_ECN frame when compared to
-ack_ce_cntr.
+previous_ecn_ce_ctr.
 
 ~~~
-   OnPacketsMarked(ce_counter):
-     if (ce_counter > ack_ce_cntr):
-       // update ack_ce_cntr
-       ack_ce_cntr = ce_counter
-     if (!InRecovery(largest_acked_packet)):
+   CongestionEvent(packet_number):
+     // Start a new recovery epoch if the event packet is larger
+     // than the end of the previous recovery epoch.
+     if (!InRecovery(packet_number)):
        // Start a new congestion epoch
        end_of_recovery = largest_sent_packet
        congestion_window *= kMarkReductionFactor
        congestion_window = max(congestion_window, kMinimumWindow)
        ssthresh = congestion_window
+
+   OnPacketsMarked(ce_counter):
+     if (ce_counter > previous_ecn_ce_ctr):
+       // update previous_ecn_ce_ctr
+       previous_ecn_ce_ctr = ce_counter
+     CongestionEvent(largest_newly_acked.packet_number)
 ~~~
 
 
@@ -1114,11 +1118,7 @@ are detected lost.
      largest_lost_packet = lost_packets.last()
      // Start a new recovery epoch if the lost packet is larger
      // than the end of the previous recovery epoch.
-     if (!InRecovery(largest_lost_packet.packet_number)):
-       end_of_recovery = largest_sent_packet
-       congestion_window *= kLossReductionFactor
-       congestion_window = max(congestion_window, kMinimumWindow)
-       ssthresh = congestion_window
+     CongestionEvent(largest_lost_packet.packet_number)
 ~~~
 
 ### On Retransmission Timeout Verified

draft-ietf-quic-transport.md

@@ -1422,9 +1422,8 @@ Explicit Congestion Notification (ECN) {{!RFC3168}} is feature that allows for
 non-destructive congestion notification by a network node.  That is, packets are
 marked instead of being discarded by routers and other devices along a network
 path. QUIC endpoints perform capability verification on connection establishment
-as well as connection migration. The feature can be used unidirectional or
-bidirectional depending or disabled temporarily depending on endpoint and path
-capabilities.
+as well as connection migration. ECN can be used unidirectionally,
+bidirectionally, or disabled depending on endpoint and path capabilities.
 
 The capability check makes use of the ACK_ECN frame in {{frame-ack-ecn}}. Each
 endpoint individually performs an ECN capability check for its send path. The
@@ -1442,16 +1441,15 @@ endpoint, an ACK_ECN frame is transmitted back. This ACK_ECN frame indicates how
 many packets that are marked ECT(0), ECT(1) or ECN-CE. Thus the endpoint can
 determine if the endpoints and path is ECN capable.
 
-The ACK_ECN frame will, when received, confirm that the path direction supports
-ECN if the counters show a correct amount of packets received for a valid and
-expected counter combination. ECT marked packets can become remarked as CE along
-the path between the peers. The ACK_ECN counters are added together and compared
-to total number of ACKed packets, if the sum of the counters are equal too or
-larger than the number of ACKed packets then the path is ECN capable. This
-capability check thus has verified that one direction of the path between the
-peers is free from issues with ECN bleaching and that the application does not
-experience problems with access to the ECN field in the IP header. In this case
-the marking of the generated packets with ECT continues.
+When ACK_ECN is received, the counter values can be used to confirm the expected
+number of marks were received. ECT marked packets can become remarked as CE
+along the path between the peers. The ACK_ECN counters are added together and
+compared to total number of ACKed packets, if the sum of the counters are equal
+too or larger than the number of ACKed packets then the path is ECN capable.
+This capability check thus has verified that one direction of the path between
+the peers is free from issues with ECN bleaching and that the application does
+not experience problems with access to the ECN field in the IP header. In this
+case the marking of the generated packets with ECT continues.
 
 If an ACK frame (not the ACK_ECN frame) is used to acknowledge reception of
 packets that was marked as ECT in the sender, or if the comparision of the
@@ -1467,19 +1465,18 @@ not the case **\[ED note, have not seen any clear statement in the drafts]**,
 then it should be verified that the number of ECT marked packets are equal to or
 larger that the amount of ECT marked packets that have been transmitted.
 
-### Continous Verification of ECN {#ecn-continous-verification}
+### Continuous Verification of ECN {#ecn-continuous-verification}
 
-If the ECN capabiity check was successful and the endpoint continus to send ECT
-marked packets then continous verification is applied. This is to detect any
-cases when ECN field is bleached, that is, zeroed out by a network node, likely
-as the result of a routing changes since the ECN capability check.
+If the ECN capability check was successful and the endpoint continues to send
+ECT marked packets then continuous verification is applied. This is to detect
+any cases when ECN field is bleached, that is, zeroed out by a network node,
+likely as the result of a routing changes since the ECN capability check.
 
-For each ACK_ECN frame that is received, the total number of ACKed packets are
-updated by adding those outstanding packets that was acknowledged by this
-ACK_ECN frame. Then the total number of ACKed packets are compared with the sum
-of the ECN counters. If ACKed packets are larger than the sum, then some ECN
-failure has occured and ECN should be disabled. ECN is also disabled in case an
-ACK frame is received acknowleging any ECT sent packet.
+For each received ACK_ECN frame, the total number of newly acknowledged packets
+can be compared to the total increase in ECN counters. If the increase in ECN
+counters is less, then an ECN failure has occurred and ECN should be disabled.
+ECN is also disabled in case an ACK frame is received acknowledging any ECT sent
+packet.
 
 
 ## Proof of Source Address Ownership {#address-validation}
@@ -2960,10 +2957,6 @@ ACK Block (repeated):
 
 ### Sending ACK Frames
 
-ACK Frames MAY be sent when all packets to be acknowledge had an IP header with
-the ECN field marked as Not-ECT. If any packets where marked as ECT or ECN-CE
-the ACK_ECN Frame ({{frame-ack-ecn}}) MUST be used instead.
-
 Implementations MUST NOT generate packets that only contain ACK frames in
 response to packets which only contain ACK frames. However, they MUST
 acknowledge packets containing only ACK frames when sending ACK frames in
@@ -3037,14 +3030,18 @@ number of packets that were received with the corresponding ECN codepoint in
 the IP header. If the header is not readable from the application, the
 codepoint 00 (Not-ECT) MUST be assumed.
 
-ACK_ECN Frame MUST be used when when an endpoint is acknowleging a packet where
+ACK_ECN Frame MUST be used when when an endpoint is acknowledging a packet were
 the IP header ECN field was marked as ECT(0), ECT(1) or ECN-CE when received.
-The ACK_ECN frame is used by the reeiver to echo the value of these counters
+ACK Frames ({{frame-ack}}) MAY be sent when all packets to be acknowledged
+had an IP header with the ECN field marked as Not-ECT.
+
+The ACK_ECN frame is used by the receiver to echo the value of these counters
 back to the sender of these packets. This allows the sender to utilize these
 counter values for congestion control. The ACK_ECN frame contains all the
 elements of the ACK frame ({{frame-ack}}) with the addition of an ECN block
 appended at the end.
 
+
 ~~~
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
@@ -4418,8 +4415,7 @@ large number of streams.
 
 ## Explicit Congestion Notification Attacks
 
-The ECN bits {{!RFC3168}} are an unauthenticated signal from the network. An
-on-path attacker may manipulate the value of the field. Thus, affecting the
+An on-path attacker may manipulate the value of the field, affecting the
 congestion avoidance behavior of the sender. By clearing any CE marks the
 connection can help drive a bottle neck queue into a loss regime. By setting
 the ECN field to CE marking it can drive down the senders congestion window
@@ -4428,11 +4424,10 @@ by dropping packets for the connection. Section 18 and 19 of {{!RFC3168}}
 discusses the effects of undesired manipulation of the ECN field in more
 details.
 
-If a receiver would not have packet duplication detection and not discard any
-duplicates an off-path attacker that can receive copies of the connection's
-packets can manipulate the senders congestion avoidance state. If packet
-duplicates are dropped, the off-path attacker will need to race the original
-packet to be successful in this attack.
+If a receiver does not discard duplicate packets, an off-path attacker can
+retransmit packets with ECN bits set and manipulate the senders congestion
+avoidance state. If duplicate packets are dropped, the off-path attacker will
+need to race the original packet to be successful in this attack.
 
 # IANA Considerations