IETF Logo Mail Archive

Re: [tcpm] More motivating scenarios for tcpm-ack-pull

Bob Briscoe <in@bobbriscoe.net> Fri, 13 December 2019 17:29 UTC

Return-Path: <in@bobbriscoe.net>
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 1D72C120854 for <tcpm@ietfa.amsl.com>; Fri, 13 Dec 2019 09:29:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
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 3kfBDWNofeHA for <tcpm@ietfa.amsl.com>; Fri, 13 Dec 2019 09:29:01 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 C623C1208DC for <tcpm@ietf.org>; Fri, 13 Dec 2019 09:29:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TWjpO03YobBgzvYe1pfukFRyhoXT5swmqnMU6jFnECs=; b=xTC584sEu5fwjBoRVnnnN4KVh5 NQC7eHKMfIwx/c+JmGH02S8HKeuBLR4LILEd3d2PNxzQ9SVL7m0shPDJ/yi4iOp8Qfv1OExWjKDh8 HCrnwHpd6RMGJMz86jIzpQBp//O8vGLxIyPGt/rkCFQ0E8fxESQcVo8f7oN1UdBUf8uWoH2McnmZ0 leeGhZ3P0k3dDJwxYu7926SvB6d925sL4BvaWrxkhVG9oUfQkNhOadnp5J97YSCsYxKD6xc4As+Fj eAqwd3A34oXUZY6ueIF6rw/irlaNzAcg60Tpom+v+fzPqj207oI3TkKOQErLgbvn8Pa7TKEt4wmL/ YflXtoSA==;
Received: from 92.40.249.2.threembb.co.uk ([92.40.249.2]:45939 helo=[172.20.10.2]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <in@bobbriscoe.net>) id 1ifokN-0001TX-5B; Fri, 13 Dec 2019 17:28:59 +0000
To: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
Cc: "Scheffenegger, Richard" <rs.ietf@gmx.at>, tcpm IETF list <tcpm@ietf.org>, Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk>
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>
From: Bob Briscoe <in@bobbriscoe.net>
Message-ID: <7a071358-74e6-c88f-6f88-b45941b90991@bobbriscoe.net>
Date: Fri, 13 Dec 2019 17:28:58 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <db2a849d-a26f-d741-a039-1622c478ee50@gmx.at>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/2l1HUShXAinTBAkY2S_23DEs9gs>
Subject: Re: [tcpm] 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: Fri, 13 Dec 2019 17:29:04 -0000

Carles, Jon,

Another motivating scenario for ack-pull (or similar) brought to my 
attention by Richard Scheffenegger and Neal Cardwell:

Re: [PATCH net-next] tcp: ack immediately when a cwr packet arrives
https://lists.openwall.net/netdev/2018/07/25/10




Bob


On 10/12/2019 13:37, Scheffenegger, Richard wrote:
>
> I believe your list here misses the AckCC option of RFC5690 (which is
> only informational, not even experimental). Am Ack Ratio option of 1
> followed by a an Ack Ratio of n could serve the same purpose...
>
> Note that there have been multiple investigations showing good
> traversability of new options across middleboxes nowadays.
>
> Best regards,
>    Richard
>
>
> Am 07.12.2019 um 12:30 schrieb Carles Gomez Montenegro:
>> ess how the patch you mention offers a way
>> to trigger immediate ACKs, and the related context and benefits.
>>
>> Perhaps a combination or (re)use of existing TCP header fields (e.g.
>> CWR/PSH as per your suggestion below, or the Urgent pointer as suggested
>> earlier by Bob) could be a way to enable triggering immediate ACKs.
>>
>> A concern with these techniques is that they are limited to some extent.
>> For example, some applications produce small segments with the PSH flag
>> set and benefit from Delayed ACKs (e.g. to piggyback ACKs and 
>> replies). In
>> those cases, even regardless of the CWR flag, triggering immediate ACKs
>> will avoid achieving performance benefits of Delayed ACKs.
>>
>> In contrast, a dedicated resource (e.g. a TCP header reserved bit, as we
>> propose in the draft) will not suffer such limitations. However, that
>> resource needs to be allocated.
>>
>> Summarizing, there may be two approaches to enable ACK Pull:
>>
>> 1.- Overloading semantics of existing TCP header fields.
>> 2.- Dedicating a resource.
>>
>> Then the question is, considering pros and cons of both approaches: 
>> which
>> one do we prefer?
>>
>> It would be great to hear the WG feedback on the above question!
>>
>> Thanks,
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

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

v2.23.0 | Report a Bug | By Email