Re: [aqm] TCP ACK Suppression

David Lang <david@lang.hm> Wed, 07 October 2015 21:22 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 897D91B30F7 for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 14:22:46 -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 5sbSWrjTlSdE for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 14:22:45 -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 5890B1B30F5 for <aqm@ietf.org>; Wed, 7 Oct 2015 14:22:45 -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 t97LMgsi005454; Wed, 7 Oct 2015 14:22:42 -0700
Date: Wed, 7 Oct 2015 14:22:42 -0700 (PDT)
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <D997C02F-974B-447D-BABB-88E1B00C5851@gmail.com>
Message-ID: <alpine.DEB.2.02.1510071416040.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> <alpine.DEB.2.02.1510071103170.29851@nftneq.ynat.uz> <D997C02F-974B-447D-BABB-88E1B00C5851@gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="680960-1608662930-1444252962=:29851"
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/SzqvgQD0lE62TLWN1KGTJq-20so>
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 21:22:46 -0000

On Wed, 7 Oct 2015, Jonathan Morton wrote:

>> On 7 Oct, 2015, at 21:05, David Lang <david@lang.hm> wrote:
>>
>>>> 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?
>
> Let me turn that around:
>
> What should a node which aggregates 1500-byte packets into jumbo frames set 
> the ECN field to on the resulting jumbo packet, if the ECN fields of the 
> original packets had different values?  I’m having some trouble imagining a 
> scenario where such destructive aggregation is permitted, except for TCP 
> proxies which should act as endpoints anyway.  GSO, in particular, requires 
> the headers to be identical in that respect, ensuring that the original 
> packets can be reconstructed (assuming they are MSS sized).

TCP data is supposed to be logically a continuous stream, it should not matter 
to the endpoints how it is packetized. So a conversion to/from jumbo frames 
should be acceptable.

David Lang