Re: [tcpm] Review of draft-ietf-tcpm-alternativebackoff-ecn-05

[Naeem Khademi <[e-mail]>]

Hi Michael

Thanks a lot for the feedback. We have submitted the -06 version based on your reviews (https://www.ietf.org/internet-drafts/draft-ietf-tcpm-alternativebackoff-ecn-06.txt). Here are some inline responses to your comments:

On Jan 7, 2018, at 12:18 AM, Scharf, Michael (Nokia - DE/Stuttgart) <[e-mail]<mailto:[e-mail]>> wrote:

Authors, all,

I have read draft-ietf-tcpm-alternativebackoff-ecn-05. I found some minor issues that should be easy to fix; in many cases the issues are editorial. Yet, I believe a document update would be useful. See below [ms].

Thanks

Michael (with no hat on)


*******************************

Abstract

   Recent Active Queue Management (AQM) mechanisms allow for burst
   tolerance while enforcing short queues to minimise the time that
   packets spend enqueued at a bottleneck.

[ms] Nit: I am not sure if the term “recent” is really needed. IMHO any AQM, including old vanilla RED, can have this property, if it is properly configured. As a result, I think the sentence would also be correct without the word “recent”. This would somewhat avoid the question (in particular in the abstract) how to handle bottlenecks that use e.g. vanilla RED instead of a “recent” AQM.

NKH: fixed.



1.  Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

[ms] Nit: Maybe the new wording in RFC8174 could be used. As an editorial nit, Section 1 and 2 could be swapped, but the order may be a matter of taste.

NKH: done.



4.1.  Why Use ECN to Vary the Degree of Backoff?

   When packet
   loss is inferred using the retransmission timer and the given packet
   has not yet been resent by way of the retransmission timer (regarded
   as a notification of congestion), Standard TCP sets the ssthresh to
   the maximum of half of the FlightSize and 2*SMSS [RFC5681], which
   causes the TCP congestion control to go back to allowing only a BDP
   of packets in flight -- just sufficient to maintain 100% utilisation
   of the bottleneck on the network path.

[ms] This reference of RFC5681 and eq. (4) therein only mentions the reaction to RTO (Section 3.1 in RFC5681) but omits the use in Fast Retransmit/Fast Recovery (Section 3.2 in RFC5681). Thus, the reference is a bit misleading, since this section actually seems to be about Fast Retransmit/Fast Recovery. And, as a purely editorial remark, I think the sentence is long and hard to parse. I think an alternative wording would be possible along the lines of:

<ms>
   According to [RFC5681], when a TCP sender detects segment loss
   using the retransmission timer and the given segment has not yet been
   resent by way of the retransmission timer, the value of ssthresh must be
   set to no more of the maximum of half of the FlightSize and 2*SMSS. The
   same equation is also used during Fast Retransmit/Fast Recovery
   [RFC5681]. As a result, the TCP congestion control only allows one BDP
   of packets in flight. This is just sufficient to maintain 100% utilisation
   of the bottleneck on the network path.
</ms>

NKH: used the proposed wording.

4.2.  Focus on ECN as Defined in RFC3168

   Some transport protocol mechanisms rely on ECN semantics that differ
   from the original ECN definition [RFC3168] -- for example, Congestion
   Exposure (ConEx) [RFC7713] and Datacenter TCP (DCTCP)
   [I-D.ietf-tcpm-dctcp] need more accurate ECN information than that
   offered by the original feedback method.  Other mechanisms (e.g.,
   [I-D.ietf-tcpm-accurate-ecn]) allow the sender to adjust the rate
   more frequently than once each path RTT.  Use of these mechanisms is
   out of scope for this document.

[ms] I think [I-D.ietf-tcpm-accurate-ecn] specifies a scheme to provide more than one feedback signal per RTT. It is not exactly clear to me what is meant by “adjusting the rate more frequently”. Editorial nits: DCTCP is published as RFC 8257. And I think the subsection title could be repeated in the main text (“This specification focuses on…”).

NKH: the block of text reads as the following now:

   Some transport protocol mechanisms rely on ECN semantics that differ
   from the original ECN definition [RFC3168].  For instance, Accurate
   ECN [I-D.ietf-tcpm-accurate-ecn] permits more frequent and detailed
   feedback.  Use of mechanisms (such as Accurate ECN, Datacenter TCP
   (DCTCP) [RFC8257], or Congestion Exposure (ConEx) [RFC7713]) is out
   of scope for this document.  This specification focuses on ECN as
   defined in [RFC3168].



4.3.  Choice of ABE Multiplier

   ABE decouples the reaction of a TCP sender to inferred packet loss
   and ECN-signalled congestion when in the congestion avoidance phase
   by differentiating the scaling factor used in Equation 4 in
   Section 3.1 of [RFC5681].

[ms] Editorial nit: This sentence seems somewhat broken (“when”?). Maybe an alternative would be:

<ms>
   ABE decouples the reaction of a TCP sender to inferred packet loss
   and ECN-signalled congestion in the congestion avoidance phase.
   To achieve this, ABE uses different the scaling factor in Equation 4 in
   Section 3.1 of [RFC5681].
</ms>

NKH: fixed based on the suggested text.

   beta_{ecn} depends on how the response of a TCP connection to shallow
   AQM marking thresholds is optimised. beta_{loss} reflects the
   preferred response of each congestion control algorithm when faced
   with exhaustion of buffers (of unknown depth) signalled by packet
   loss.  Consequently, for any given TCP congestion control algorithm
   the choice of beta_{ecn} is likely to be algorithm-specific, rather
   than a constant multiple of the algorithm's existing beta_{loss}. The
   recommended beta_{ecn} value in this document is only applicable for
   Standard TCP congestion control.

[ms] In this section one has to reverse-engineer what “recommended beta_{ecn} value in this document” means. Why not make this explicit? In addition, with some editorial reordering this section could be easier to read, e.g., as follows:

<ms>
  The recommendation in Section 3 in this document corresponds to a value
  of beta_{ecn}=0.8. This recommended beta_{ecn} value is only applicable for
  the standard TCP congestion control [RFC5681]. The selection of
  beta_{ecn} enables tuning the response of a TCP connection to shallow
  AQM marking thresholds. beta_{loss} characterizes the response of a
  congestion control algorithm to packet loss, i.e., exhaustion of buffers
  (of unknown depth). Different values for beta_{loss} have been suggested
 for TCP congestion control algorithms.  Consequently, beta_{ecn} is likely
  to be an algorithm-specific parameter rather than a constant multiple
  of the algorithm's existing beta_{loss}.
</ms>

NKH: inserted the proposed text.



5.  ABE Requirements

[ms] Edorial nit: An alternative title would maybe “ABE Deployment Requirements”.

NKH: done.


   If the method is only deployed by some senders, and not by others,
   the senders that use this method can gain some advantage, possibly at
   the expense of other flows that do not use this updated method.
   Because this advantage applies only to ECN-marked packets and not to
   packet loss indications, in the worst case (e.g., an ABE-compliant
   TCP sender using beta_{ecn} = 1.0) the ECN-Capable bottleneck will
   still fall back to dropping packets, and the result is no different
   than if the TCP sender was using traditional loss-based congestion
   control.

[ms] beta_{ecn} = 1.0 can imply that a TCP sender does not react *at all* to ECN marks, right? If so, I would suggest to reword this section in order to avoid the expression “ABE-compliant” for the case beta_{ecn} = 1.0. For instance, the second sentence could be reworded to something like  “Because this advantage applies only to ECN-marked packets and not to packet loss indications, an ECN-Capable bottleneck will still fall back to dropping packets if an TCP sender using ABE is too aggressive, and the result is no different…”

NKH: changed to the proposed text.


   ABE also makes one congestion-response each RTT that congestion is
   signalled, and therefore there is no response to loss within the same
   round-trip time, since ABE has already made a reduction of the
   congestion window. ABE will however respond for each round-trip time
   that congestion continues to be signaled.

[ms] Editorial nit: These sentences are hard to parse.

NKH: changed it to the following. Hope it reads better now:

   ABE also responds to congestion once per RTT, and therefore it does
   not respond to further loss within the same RTT, since ABE has
   already reduced the congestion window.  If congestion persists after
   such reduction, ABE continues to reduce the congestion window in each
   consecutive RTT.


   The result of this Internet experiment will include an investigation
   of cases such as the ones listed above, and be reported by
   presentation to the TCPM WG (or IESG) or an implementation report at
   the end of the experiment.

[ms] I am not sure if we really need this paragraph on process details, e.g., whether there will be a presentation. To me, it would be sufficient just to identify what cases and issues need to be investigated as part of the experiment. For what it is worth, as individual contributor, I think a TCPM presentation summarizing the outcome of the experiment would be sufficient for such a short document. But unless e.g. the IESG insists in such wording, I don’t see a need to specify the process inside the document.

NKH: changed the text to the following:

   The result of this Internet experiment ought to include an
   investigation of the implications of experiencing an ECN-CE mark
   followed by loss within the same RTT.  At the end of the experiment,
   this will be reported to the TCPM WG (or IESG).

Cheers,
Naeem