IETF Logo Mail Archive

Re: [tcpm] Sender control of Delayed ACKs (was Re: More motivating scenarios for tcpm-ack-pull)

Rahul Arvind Jadhav <rahul.jadhav@huawei.com> Mon, 30 March 2020 09:33 UTC

Return-Path: <rahul.jadhav@huawei.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250E53A11B1 for <tcpm@ietfa.amsl.com>; Mon, 30 Mar 2020 02:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWDe4p7L5pGg for <tcpm@ietfa.amsl.com>; Mon, 30 Mar 2020 02:33:52 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 588A93A11B3 for <tcpm@ietf.org>; Mon, 30 Mar 2020 02:33:52 -0700 (PDT)
Received: from lhreml702-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 5D59D2379FF2301ED6AC for <tcpm@ietf.org>; Mon, 30 Mar 2020 10:33:49 +0100 (IST)
Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 30 Mar 2020 10:33:49 +0100
Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Mon, 30 Mar 2020 10:33:48 +0100
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.162]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0487.000; Mon, 30 Mar 2020 15:03:39 +0530
From: Rahul Arvind Jadhav <rahul.jadhav@huawei.com>
To: Bob Briscoe <ietf@bobbriscoe.net>, Carles Gomez Montenegro <carlesgo@entel.upc.edu>
CC: tcpm IETF list <tcpm@ietf.org>
Thread-Topic: [tcpm] Sender control of Delayed ACKs (was Re: More motivating scenarios for tcpm-ack-pull)
Thread-Index: AQHWA3fm2Olv6W5hoUGntvdOUrlAOahcRJmAgASZHpA=
Date: Mon, 30 Mar 2020 09:33:39 +0000
Message-ID: <982B626E107E334DBE601D979F31785C5E27382F@BLREML503-MBX.china.huawei.com>
References: <3326ed99-b077-592b-7913-aeb2286912c4@bobbriscoe.net> <13486113479ebcb344247daedda10467.squirrel@webmail.entel.upc.edu> <CAEeTejJC4KLbjLNWmVxPXwDtrC=rjrcOsVnwjEym2uEhJZq7cw@mail.gmail.com> <3f4d3d94-24a8-4ed8-a752-ae5242907d43@gmx.at> <ef6c55535a860b37056cd014ad178416.squirrel@webmail.entel.upc.edu> <db2a849d-a26f-d741-a039-1622c478ee50@gmx.at> <fde0262a-0206-92bf-b529-4043cacc8030@bobbriscoe.net> <391035ee6f57baa407f9be225db8dfbc.squirrel@webmail.entel.upc.edu> <44192613-4e05-bffa-a810-ef261d78d190@bobbriscoe.net> <aff57f8918989339649e324481502f6c.squirrel@webmail.entel.upc.edu> <220dabb7-c4bb-d2f2-4b56-29a2de62a71c@bobbriscoe.net>
In-Reply-To: <220dabb7-c4bb-d2f2-4b56-29a2de62a71c@bobbriscoe.net>
Accept-Language: en-IN, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.46.86.229]
Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5E27382FBLREML503MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/nyxxspTx4leastBYkBkZFyCFzJU>
Subject: Re: [tcpm] Sender control of Delayed ACKs (was Re: More motivating scenarios for tcpm-ack-pull)
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: Mon, 30 Mar 2020 09:33:54 -0000

Hello Bob,
Thanks for the pointer.

[BB]
                Examples of technologies where deployments have
                been reported to do ACK thinning include satellite links, DOCSIS
                cable networks, mobile cellular networks, among others.

For DOCSIS at least I know that it's not just a case of "deployments have been reported". TCP ACK thinning is in the DOCSIS spec [DOCSIS3.1].

[RJ] I couldn’t find any refs towards TCP ACK thinning in the mentioned DOCSIS spec. Not sure if I am missing something? The only sentence I found, “The CM SHOULD support a mechanism by which TCP ACK frames are prioritized or filtered in order to increase TCP session throughput” in section 9.1.2.3.2 but not sure if this is what you were referring?
I am interested in understanding more about what DOCSIS attempts  in the context of ACK thinning. Any details are appreciated.
Thanks in advance.

- Rahul

v2.23.0 | Report a Bug | By Email