Subject: [tcpm] Review of draft-ietf-tcpm-alternativebackoff-ecn-02

From: "Bless, Roland (TM)" <[email-masked]>
Date: Mon, 23 Oct 2017 12:12:31 +0200

Hi,

as promised at the last IETF meeting, here is my (lengthy)
review of draft-ietf-tcpm-alternativebackoff-ecn-02.

In summary:
1) more precise terminology, e.g., better distinction between buffer and
queue,
   also use same terminology as in RFC 5681 (largely done in -02 already).

2) state more clearly that the concrete recommendations are tailored to
   specific congestion controls and be more open to other congestion
control variants

3) the abstract is too long

and section 4 contains a bit redundancy w.r.t. sections 2 and 3.

in more detail
1) I would prefer to use _buffer_ for the maximum memory space that is
   allocated for potentially enqueued packets and _queue_ for the
   amount of actually queued packets, i.e., current buffer
   occupancy. Therefore, IMHO it makes sense to speak of shallow
   buffers and short queues, but not of "shallow queues". In
   particular, an AQM tries to keep the (longer-term) queue short in a
   buffer while accepting transient bursts -- the behavior therefore
   also differs from a "shallow buffer".

2) the main point of this draft is: it makes sense to behave different to
   CE-ECN marked packets than to packet loss. One benefit is to
   achieve higher utilization by adjusting the backoff to be less. The
   recommendation for two backoff factors is specific for two
   congestion controls, CUBIC and New Reno. For other congestion
   controls it may also make sense to adapt differently, but the draft
   doesn't provide any recommendations for them. In general, there can
   be lots of different congestion controls that do not need this kind
   of modification to keep the utilization high.

3) The abstract should be corrected according to 1 and shortened,
   such as: 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. This can cause
   noticeable performance degradation for TCP connections traversing
   such a bottleneck, especially if they are only a few or their
   bandwidth-delay-product is large.  An Explicit Congestion
   Notification (ECN) signal indicates that an AQM mechanism is used
   at the bottleneck, and therefore the bottleneck network queue is
   likely to be short.  This document therefore proposes an update to
   the TCP sender-side ECN reaction in congestion avoidance to reduce
   the congestion window by a smaller amount than the congestion
   control algorithm's reaction to loss.

------------------
Walk through:

Section 2.
==========

>   Research has demonstrated the benefits of reducing network delays due
>   to excessive buffering [BUFFERBLOAT]; this has led to the creation of
>   new AQM mechanisms like PIE [RFC8033] and CoDel [CODEL2012]
>   [I-D.CoDel], which avoid causing the bloated queues that are common
>   with a simple tail-drop behaviour (also known as a First-In First-
>   Out, FIFO, queue).

The first sentence is confusingly put: "reducing network delays due to
excessive buffering", better rephrase. Moreover, I'd like to see a
more precise description of the problem here: The main problem is here
that existing loss-based congestion controls complete fill available
bottleneck buffer capacity. So it's primarily _not_ the tail-drop
behavior causing bloated queues, but the congestion control. There
exist two approaches to reduce the queues: use different a different
congestion control (modify end points) or enforce short queues in
routers by using AQMs (modify intermediate systems). So a delay-based
congestion control can use a tail-drop FIFO queue and still avoid
excessive queuing delays, i.e., not even requiring an AQM to control
the queue.

>  These AQM mechanisms instantiate short queues that are designed to
>  tolerate packet bursts.

More precisely:
These AQM mechanisms aim to keep a sustained queue short while
tolerating transient (short-term) packet bursts.

>  However, congestion control mechanisms
>  cannot always utilise a bottleneck link well where there are short
>  queues.

=> However, currently used loss-based congestion control mechanisms

>  to compensate for TCP halving the "cwnd" and "ssthresh" variables in
>  response to a lost packet [RFC5681].

see 1), cwnd is set to FlightSize/2, not cwnd/2 (RFC5681 is quite
specific about this).

>  This requires the bottleneck
>  queue to be able to store at least an end-to-end bandwidth-delay

queue => buffer

>  product (BDP) of data, which effectively doubles both the amount of
>  data that can be in flight and the round-trip time (RTT) experience
>  using the network path.

it effectively doubles the RTT only if the buffer is completely
filled, usually the queue is varying over time.

>  ABE improves the
>  performance when routers use shallow buffered AQM mechanisms.

See 1), e.g., "when routers use AQM controlled buffers that allow
for short queues only."

Section 3.
==========
>  This specification describes an update to the congestion control
>  algorithm of an ECN-capable TCP transport protocol.

See 2.) This statement is very generic, whereas the recommendation is
quite specific to CUBIC and NewReno. It may be useful for other congestion
controls as well if they require also a more moderate response/backoff
in order to keep the utilization high. Their backoff modification may
however, be different. Moreover, there exist other congestion controls
that don't suffer from underutilization if they react to a congestion
signal.

>  It RECOMMENDS that a TCP
>  sender multiplies the cwnd by 0.8 and reduces the slow start
>  threshold (ssthresh) in congestion avoidance following reception of a
>  TCP segment that sets the ECN-Echo flag (defined in [RFC3168]).

See previous comment: here you should be explicit about the particular
congestion controls where the recommended behavior and parameter can
be applied to. Moreover, "cwnd= max (FlightSize * beta_{ecn}, 2 * SMSS)",
which is a bit different from cwnd= cwnd  * beta_{ecn} (this is what
the text suggests).

Section 4.
==========
>   performance gains in lightly-multiplexed scenarios, without losing

"lightly-multiplexed scenarios" means presumably that only a few flows
traverse the considered bottleneck, but how many are "a few" then?
three or nine or twenty?
Later on it is defined as
"lightly-multiplexed case (few concurrent connections)",
better mention this at first use already.>

>  loss is detected (regarded as a notification of congestion), Standard
>  TCP halves the cwnd and ssthresh [RFC5681], which causes the TCP
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
See 1), roughly speaking yes, but not quite correct. Moreover, packet
loss can be detected by various ways, e.g., by using the retransmission
timer
or not; the congestion control response may differ then, too.

>  delay target in routers and use congestion notifications to constrain
>  the queuing delays experienced by packets, rather than in response to

if AQMs set CE, they hope for an appropriate action, however,
they'll limit the queueing delays by actively dropping packets.

>  that were not necessarily configured to emulate a
>  shallow queue

see 1), short queue vs. shallow buffer

>  However, it interacts badly for a lightly-multiplexed
>  case (few concurrent connections) over a path with a large BDP.
>  Conventional TCP backoff in such cases leads to gaps in packet
>  transmission and under-utilisation of the path.

Maybe combine these two sentences:

However, in a lightly-multiplexed case (few concurrent connections)
over a path with a large BDP, conventional TCP backoff leads to
gaps in packet transmission and under-utilisation of the path.

>  hence the CE-mark likely came from a bottleneck with a shallow queue.

controlled and short queue

>  Reacting differently to an ECN CE-mark than to packet loss can then
>  yield the benefit of a reduced back-off, as with CUBIC [I-D.CUBIC],
>  when queues are short, yet it can avoid generating excessive delay
>  when queues are long.

I'm not sure that I understood the gist in this statement, better
rephrase and split up into two sentences?

> For non-ECN-enabled
> TCP connections,

Not fully clear what this means. Are the end-systems ECN capable, but
the routers in between do not mark? Or does it mean that at least one
end-system isn't ECN capable?

>     ssthresh_(t+1) = max (FlightSize_t * beta_{loss}, 2 * SMSS)

RFC 5681 doesn't use any notation with "t". If you are using t, you
should specify what it means. My suggestion is to avoid introducing
it and to use the same terminology as in RFC 5681.

I think that the beginning of section 4.3 belongs more to section 3
while that rest fits to the section title (discussion of the ABE
multiplier).

Section 5.
===========

> 5.  Status of the Update

I don't understand the purpose of this section or the section
title is weird at least.
Is it meant to describe required changes? The use this as section
title.

> congestion-control algorithms, it does not require any change to the

everywhere else it is "congestion control" without dash.

>   The currently published ECN specification requires that the
>   congestion control response to a CE-marked packet is the same as the
>   response to a dropped packet [RFC3168].  The specification is
>   currently being updated to allow for specifications that do not
>   follow this rule [I-D.ECN-exp].  The present specification defines
>   such an experiment and has thus been assigned an Experimental status
>   before being proposed as a Standards-Track update.

This is largely a repetition from the introduction.

>  Because this advantage applies only to ECN-marked packets and not to
>  loss indications, the new method cannot lead to congestion collapse.

I'm not sure that I can follow here. There are several forms of congestion
collapse and the classical one causes unnecessary retransmissions by a
timer mismatch. Maybe you can elaborate a bit more here.

Section 8.
==========

>  http://heim.ifi.uio.no/naeemk/research/ABE/ This code was used to

Full stop missing here (presumably to avoid problems with the URL).
Maybe put the (most important) changes into an appendix? I'm not sure
how long this URL will be valid after the RFC has been published.

Regards,
 Roland