Re: [aqm] TCP ACK Suppression

David Lang <david@lang.hm> Wed, 07 October 2015 18:05 UTC

Return-Path: <david@lang.hm>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969AF1ACDD1 for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 11:05:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 j8RmRt2aA-TC for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 11:05:43 -0700 (PDT)
Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 394921ACDCE for <aqm@ietf.org>; Wed, 7 Oct 2015 11:05:43 -0700 (PDT)
Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t97I5fEq004225; Wed, 7 Oct 2015 11:05:41 -0700
Date: Wed, 7 Oct 2015 11:05:41 -0700 (PDT)
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <alpine.DEB.2.02.1510071055430.29851@nftneq.ynat.uz>
Message-ID: <alpine.DEB.2.02.1510071103170.29851@nftneq.ynat.uz>
References: <alpine.DEB.2.02.1510060748480.8750@uplift.swm.pp.se> <D2394BB6.548C5%g.white@cablelabs.com> <0A452E1DADEF254C9A7AC1969B8781284A7D9B66@FR712WXCHMBA13.zeu.alcatel-lucent.com> <5614D4B8.5060403@kit.edu> <alpine.DEB.2.02.1510071246550.8750@uplift.swm.pp.se> <alpine.DEB.2.02.1510071015430.29851@nftneq.ynat.uz> <5615581C.5010907@rogers.com> <E27CECBF-99E6-4474-9444-A57A83BBC332@gmail.com> <alpine.DEB.2.02.1510071055430.29851@nftneq.ynat.uz>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: MULTIPART/Mixed; BOUNDARY="680960-331319192-1444240954=:29851"
Content-ID: <alpine.DEB.2.02.1510071103171.29851@nftneq.ynat.uz>
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/3LTK4rPwm_wDdpBQtmBqSyPEqig>
Cc: aqm@ietf.org, davecb@spamcop.net
Subject: Re: [aqm] TCP ACK Suppression
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Oct 2015 18:05:44 -0000

On Wed, 7 Oct 2015, David Lang wrote:

> On Wed, 7 Oct 2015, Jonathan Morton wrote:
>
>>> On 7 Oct, 2015, at 20:36, David Collier-Brown <davec-b@rogers.com> wrote:
>>> 
>>> On 07/10/15 01:19 PM, David Lang wrote:
>>>> On Wed, 7 Oct 2015, Mikael Abrahamsson wrote:
>>>> 
>>>>>> Oh, I hope that this is an exception. Such kind of optimizations may 
>>>>>> cause a lot of trouble since a link layer device is interfering with 
>>>>>> transport layer semantics. We all know that exactly these kinds of 
>>>>>> interference eventually end up in problems with end-to-end transparency 
>>>>>> and deployment of new protocol options. At least it interferes with the 
>>>>>> ACK clocking expectation of some congestion control algorithms...
>>>>> 
>>>>> Personally, I think you're going to see more and more of this. There are 
>>>>> mulitple shared access medium where you're allowed to send only part of 
>>>>> the time, and it's someone else who tells you when you may send.
>>>> 
>>>> it doesn't even require that someone else tells you when you may send. It 
>>>> can just be waiting for an available transmit timeslot (Wifi for example)
>>>> 
>>>> collapsing multiple ACKs that are going to be sent at once is almost 
>>>> always going to be a win.
>>> 
>>> I quite agree, but if there is a congestion control implementation "in the 
>>> wild" that assumes it will get a stream of acks, that one's going to need 
>>> some work (:-))
>>> 
>>> Anyone know if that's the case? The comment above suggest it may be...
>> 
>> It’s not “in the wild”, but this sort of thing is a headache for ELR.  It 
>> essentially means that it won’t be able to use AccECN for its feedback 
>> (since AccECN doesn’t allow reconstructing a complex 32-packet history of 
>> ECN codepoints from a single ACK), but must introduce some other mechanism 
>> to feed back the required data to the sender.
>
> but if you are getting all 32 acks at the same time, with no other packets 
> flowing, are you going to be able to do anything sane? do you mark every one 
> of the acks with ECN (sending a super-strong backoff message), or only mark 
> one of the acks (sending a weak backoff message)

Also, how can you tell how many acks you 'should' get? what happens if the 1500 
byte packets get combined into 9000 byte jumbo packets for the final hop? how 
many acks 'should' you get?

David Lang