Re: [tcpm] Sender control of Delayed ACKs (was Re: More motivating scenarios for tcpm-ack-pull)
Carles Gomez Montenegro <carlesgo@entel.upc.edu> Tue, 28 April 2020 08:53 UTC
Return-Path: <carlesgo@entel.upc.edu>
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 5624D3A1109 for <tcpm@ietfa.amsl.com>; Tue, 28 Apr 2020 01:53:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 GeEEMruT9GsA for <tcpm@ietfa.amsl.com>; Tue, 28 Apr 2020 01:53:11 -0700 (PDT)
Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 108923A1101 for <tcpm@ietf.org>; Tue, 28 Apr 2020 01:53:10 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 03S8qMPD055016; Tue, 28 Apr 2020 10:52:22 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 6A33C1D53C1; Tue, 28 Apr 2020 10:52:21 +0200 (CEST)
Received: from 83.53.208.128 by webmail.entel.upc.edu with HTTP; Tue, 28 Apr 2020 10:52:22 +0200
Message-ID: <f41618b1adb935f5b4f2b970ee0dcb33.squirrel@webmail.entel.upc.edu>
In-Reply-To: <220dabb7-c4bb-d2f2-4b56-29a2de62a71c@bobbriscoe.net>
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>
Date: Tue, 28 Apr 2020 10:52:22 +0200
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: Bob Briscoe <ietf@bobbriscoe.net>
Cc: tcpm IETF list <tcpm@ietf.org>, Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk>
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.3 at dash
X-Virus-Status: Clean
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Tue, 28 Apr 2020 10:52:22 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/QB5J_s1tiWbOuxgYvU7g9YbuuOw>
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: Tue, 28 Apr 2020 08:53:15 -0000
Hi Bob, Thanks a lot for your further feedback below. We will update the document as per your comments after tomorrow's WG meeting. By the way, thanks for suggesting a request for WG adoption. We plan to make the request during our slot in tomorrow's meeting. Cheers, Carles > Carles, > > On 26/03/2020 14:06, Carles Gomez Montenegro wrote: >> Hi Bob, >> >> Thanks a lot once again for all your comments! >> >> As you may have seen, we just published a -01, with the aim to address >> your comments. >> >> Please find below our inline responses: >> >>> Carles & Jon, >>> >>> Yes, if the tcpm WG was prepared to consider adopting this, I'd support >>> it. >>> >>> A few comments: >>> >>> I'm not sure I would limit it to "suppression" of delayed ACKs, and I >>> don't just mean it should include releasing suppression. In many >>> circumstances the sender would be happy with less frequent ACKs than >>> the >>> receiver is generating. E.g. with high performance data transfers, 1/16 >>> would often be fine when there are hundreds of packets in flight. But, >>> because the receiver can't be sure whether the sender would suffer one >>> of the downsides to delaying ACKs, it maintains a conservatively low >>> delayed ACK ratio. >>> >>> So perhaps a better scope (and title) would be "Sender control of >>> Delayed ACKs in TCP"? >>> >>> I've added 'in TCP', because I think it's useful to make the scope >>> concrete. But I think this doc could also be useful for other transport >>> protocols, particularly QUIC. >> Agreed! >> >> We have updated accordingly the document (including the title and >> abstract). >> >>> S3.1 & S3.2 Slow start & High bit rate environments and short data >>> segments >>> >>> However, use of Delayed ACKs reduces the amount >>> of ACKs received by the sender, thus reducing the rate of cwnd >>> growth, increasing transfer time and reducing throughput, when >>> compared with sending an ACK for each incoming data segment. >>> >>> I think ABC (appropriate byte counting) allows the sender to >>> unilaterally address that concern without needing ACK Pull [RFC3465]. >> Thanks for the comment. Version -01 now reflects that ABC could be used >> to >> address the concern, while also mentioning that it remains as an >> experimental mechanism, not fully included in RFC 5681. >> >>> The reference to 'more rapidly get up to speed during slow-start >>> without >>> overshoot' is a bit opaque. Rather than "describing by reference", it >>> needs to describe the lack of ability to send patterns of packets (e.g. >>> chirps) and be able to time the gaps between the ACKs. At minimum, the >>> citation should refer to Appendix B.4, which was the mechanism proposed >>> to do ACK pull at the time. >> Agreed. We have added a more explicit description in -01, and we also >> refer to Appendix B.4. >> >>> S.3.4 Beyond classic ACK transmission behavior >>> >>> It ought to mention that many link technologies (Satellite, DOCSIS, >>> LTE, >>> WiFi, ...?) do TCP ACK thinning 'cos TCP doesn't do it itself, but it >>> improves performance (when the ACK stream becomes the bottleneck for >>> the >>> forward path, because many reverse paths have pathetic bandwidth, esp. >>> if a parallel upload is going on). >>> >>> See "ACK Scaling and Performance on AsymmetricPaths" >>> https://erg.abdn.ac.uk/~downloads/ackscaling.pdf >> Agreed. Added in -01. And 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]. > > Also, I've just been talking with a colleague, who tells me that in WiFi > (sorry, don't know how widely this applies), if there are multiple TCP > ACKs for the same flow in the transmit queue, it will remove them all > except the last when it transmits the queue. Also [Kim06] includes > pseudocode for a model of WiFi ACK thinning. > > > Â [DOCSIS3.1] CableLabs, "MAC and Upper Layer Protocols Interface > (MULPI) Specification, CM-SP-MULPIv3.1", Data-Over-Cable Service > Interface Specifications DOCSIS(R) 3.1, > <https://specification-search.cablelabs.com/CM-SP-MULPIv3.1>. > > [Kim06] Hyogon Kim, Hyogon Kim, Heejo Lee, Heejo Lee, Sangmin Shin and > Inhye Kang, "On the Cross-Layer Impact of TCP ACK Thinning on IEEE > 802.11 Wireless MAC Dynamics" Â Â Â DOI: 10.1109/VTCF.2006.463 In Proc. > 64th IEEE Vehicular Technology Conference, VTC 25-28 (September 2006) > > > > Nit: > s/may allow alleviating congestion on that path/ > Â /may allow congestion on that path to be alleviated/ > > >> >>> 4.2. Per-segment granularity >>> >>> Between per-segment and permanent, there's per-connection suppression. >>> I'm not saying that would be any use, I'm just saying it doesn't have >>> to >>> be permanent. >> Agreed! Added in -01. >> >>> 4.4 Support for enabling generic ACK ratios >>> >>> This reminds me of a subtle additional requirement. When you move from >>> ACK pull to controlling the ACK ratio, there's an important distinction >>> between a sender's packet stopping the receiver delaying the ACK for >>> /that/ packet (as in ACK pull), vs. setting the receiver's Delayed ACK >>> policy for /that and subsequent/ packets. >>> >>> This raises the question, should the mechanism use soft state (repeated >>> in every packet), or connection state (remembered by the receiver)? >>> Which is hinted at in your section on "safe return to normal >>> operation".x >> We have added text in section 4.4, with the aim to incorporate your >> comments above. > > [BB] > > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â The desired generic ACK ratio is intended > to be in > force for the > Â Â Â Â Â Â Â Â Â Â Â Â current data segment, and for subsequent data > segments > (at least, > Â Â Â Â Â Â Â Â Â Â Â Â during a time interval of a duration that may > depend on > several > Â Â Â Â Â Â Â Â Â Â Â Â factors). > > I didn't mean to say "that packet and subsequent packets" should be the > only requirement. The original ACK pull pattern where the pull is just > for "that packet" is also a valid possibility. They are just different > models. If the mechanism ends up using a field in the main TCP header, > then presumably it will be sent on every packet, and therefore there's > no need to say what the behaviour should be in the absence of any > request on subsequent packets. > > >> >>> 4.10+ Extra requirement: Who's in control? >>> >>> The receiver cannot be expected to control ACKs in any way the sender >>> wants, which it will not always be able to honour anyway. So the >>> semantics have to be of a hint, not a request or a command. Then >>> there's >>> the question of whether the receiver just does what it wants, or >>> whether >>> it ought to tell the sender it's not doing what it was asked. >>> >>> It might seem that the the receiver silently not doing what it's told >>> is >>> the simple case. However,ÃÂ it adds complexity to anything trying to >>> rely >>> on the behaviour (e.g. the slow start examples). >> We have added the new requirement, and have edited its content, based on >> your input. > > [BB] Thanks for picking up all my comments so willingly. > > It occurs to me that there's probably not much point in a message from > the receiver saying whether it is complying with the request or not. The > sender can detect which ACKs are arriving, so it knows the truth, > whatever the receiver says it's doing. It sort-of might be useful to > know what the receiver says it's trying to do, to know how the network > might be intervening. But, if ground truth doesn't match what the > receiver says it's doing, the sender doesn't know whether the receiver > is lying, or whether the network is thinning ACKs. > >>> A good first draft. >>> Thank you. >> Once again, thanks a lot for your comments! > > [BB] I suggest you ask the chairs how to go about asking for an adoption > call, given that ought to be able to happen on the ML given we might not > have a f2f meeting for some time. > > Cheers > > > > Bob > >> >> Best regards, >> >> Carles >> >> >>> Bob > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > >
- [tcpm] More motivating scenarios for tcpm-ack-pull Bob Briscoe
- Re: [tcpm] More motivating scenarios for tcpm-ack… Jon Crowcroft
- Re: [tcpm] More motivating scenarios for tcpm-ack… Bob Briscoe
- Re: [tcpm] More motivating scenarios for tcpm-ack… Carles Gomez Montenegro
- Re: [tcpm] More motivating scenarios for tcpm-ack… Jon Crowcroft
- Re: [tcpm] More motivating scenarios for tcpm-ack… Scheffenegger, Richard
- Re: [tcpm] More motivating scenarios for tcpm-ack… Carles Gomez Montenegro
- Re: [tcpm] More motivating scenarios for tcpm-ack… Jeremy Harris
- Re: [tcpm] More motivating scenarios for tcpm-ack… Gorry Fairhurst
- Re: [tcpm] More motivating scenarios for tcpm-ack… Jonathan Morton
- Re: [tcpm] More motivating scenarios for tcpm-ack… Scheffenegger, Richard
- Re: [tcpm] More motivating scenarios for tcpm-ack… Bob Briscoe
- Re: [tcpm] More motivating scenarios for tcpm-ack… Bob Briscoe
- Re: [tcpm] More motivating scenarios for tcpm-ack… Carles Gomez Montenegro
- Re: [tcpm] More motivating scenarios for tcpm-ack… Carles Gomez Montenegro
- Re: [tcpm] More motivating scenarios for tcpm-ack… Bob Briscoe
- Re: [tcpm] More motivating scenarios for tcpm-ack… Jonathan Morton
- [tcpm] Sender control of Delayed ACKs (was Re: Mo… Carles Gomez Montenegro
- Re: [tcpm] More motivating scenarios for tcpm-ack… Carles Gomez Montenegro
- Re: [tcpm] Sender control of Delayed ACKs (was Re… Bob Briscoe
- Re: [tcpm] Sender control of Delayed ACKs (was Re… Rahul Arvind Jadhav
- Re: [tcpm] Sender control of Delayed ACKs (was Re… Bob Briscoe
- Re: [tcpm] Sender control of Delayed ACKs (was Re… Carles Gomez Montenegro