[tcpm] Sender Fallback in draft-ietf-tcpm-accurate-ecn-14

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Fri, 12 March 2021 11:58 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 72C5A3A196A for <tcpm@ietfa.amsl.com>; Fri, 12 Mar 2021 03:58:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id bHe7MguJhGsY for <tcpm@ietfa.amsl.com>; Fri, 12 Mar 2021 03:58:40 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk []) by ietfa.amsl.com (Postfix) with ESMTP id 668713A1968 for <tcpm@ietf.org>; Fri, 12 Mar 2021 03:58:40 -0800 (PST)
Received: from GF-MBP-2.lan (fgrpf.plus.com []) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 663861B001D2; Fri, 12 Mar 2021 11:58:37 +0000 (GMT)
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
To: tcpm IETF list <tcpm@ietf.org>
Cc: Mirja Kuehlewind <ietf@kuehlewind.net>
References: <ba4352f7-277a-b476-756a-0a6d44d65152@erg.abdn.ac.uk>
Message-ID: <590bf322-bc0d-5430-98de-41019fb85e00@erg.abdn.ac.uk>
Date: Fri, 12 Mar 2021 11:58:37 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <ba4352f7-277a-b476-756a-0a6d44d65152@erg.abdn.ac.uk>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/00URm1uwptgrAzKq96T6KSh8dQ4>
Subject: [tcpm] Sender Fallback in draft-ietf-tcpm-accurate-ecn-14
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Mar 2021 11:58:42 -0000

I have questions on the sender fallback in use of ECT(?) - not because I 
do not agree with the method, I think the approach is good. However, the 
method here is something that impacts the sender CC method, not the 
feedback method. Maybe this was discussed before - if so remind me - my 
questions relate to this:

/Once a Data Sender has entered AccECN mode it SHOULD check whether
    all feedback received for the first three or four rounds indicated
    that every packet it sent was CE-marked.  If so, for the remainder of
    the connection, the Data Sender SHOULD NOT send ECN-capable packets,
    but it MUST continue to feed back any ECN markings on arriving 

(i) I’m pretty sure this is safe to wait for /the remainder of the 
connection/. Is this possibly unnecessarily restrictive - without 
explaining why, in that some connections are long-lived and do 
experience path changes?

- At least I would like some text about path changes to path that would 
support AccECN, and what happens.

(ii) This isn’t really about AccECN at all, it’s about guidance on the 
use of ECT(?) by a TCP sender's CC .

I think this is intended here *only* is to apply to TCP senders, and I 
think that needs to be made clear? - Although it might also be valuable 
(non-normative?) advice for other transports that also have a similar 
way of reporting CE?

- To me is something that needs to be more explicit, and probably in a 
separate sub-section or something?