[tcpPrague] GRO for AccECN, DCTCP feedback and ECN feedback

Bob Briscoe <ietf@bobbriscoe.net> Sat, 23 March 2019 12:29 UTC

To: "Tilmans, Olivier (Nokia - BE/Antwerp)" <olivier.tilmans@nokia-bell-labs.com>, "Lebrun, David" <Dav.Lebrun@gmail.com>
Cc: TCP Prague List <tcpPrague@ietf.org>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <bae90d73-b472-593b-1026-446660c76846@bobbriscoe.net>
Date: Sat, 23 Mar 2019 12:52:16 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------28DA4B8AA82378DB430D3301"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/rzdKxbvx-hG-91I1D7m3UXz31KU>
Subject: [tcpPrague] GRO for AccECN, DCTCP feedback and ECN feedback
Precedence: list

Olivier, David,

To record our current discussions on this in the hackathon:

I think the only thing that software or hardware GRO have to do is mask 
the three 'ACE' TCP flags (AE, CWR & ECE) in the TCP header, so they 
will coalesce packets irrespective of the 3 ECN flags.

Currently
* CWR==1 flushes GRO
* a change in ECE flushes GRO

If we are going to mask both of them, we need to understand how much 
benefit each one gives for each of AccECN, DCTCP-style and classic ECN 
feedback:

  * DCTCP
      o ECE: if a change to ECE is held back while coalescing, the same
        packets will still be considered within the same RTT (because an
        RTT is defined up to when the packet at the start of the RTT is
        ACK'd). So DCTCP's accumulation of the ECE changes will still
        give exactly the same EWMA result. The only difference will be a
        longer RTT, which is the known tradeoff with segmentation offload.
      o CWR: ignored - no problem
  * AccECN
      o All 3 ACE flags: Same tradeoff as for ECE with DCTCP
  * Classic ECN
      o CWR: stops setting ECE once CWR arrives. If it sends ECE for a
        bit longer, no problem
      o ECE: it will get the leading edge of a new ECE volly later, so
        it will respond later.


Conclusions:
* If a machine implements only Classic ECN feedback, do not mask the 3 
ECN flags
* If a machine implements DCTCP-style feedback (in a controlled 
environment), masking the 3 ECN flags for GRO does good and no harm
* If a machine implements AccECN feedback, masking the 3 ECN flags for 
GRO does good and no harm

Mixtures of connections:
* On a machine that implements AccECN or DCTCP-style feedback and 
therefore masks the ACE field, If an individual connection has to fall 
back to Classic ECN, it will exhibit a delayed response to ECE.

Is this OK?




Bob


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

[tcpPrague] GRO for AccECN, DCTCP feedback and EC… Bob Briscoe