Re: [tcpm] Question on draft-gomez-tcpm-ack-rate-request

Jonathan Morton <chromatix99@gmail.com> Fri, 12 March 2021 12:03 UTC

Return-Path: <chromatix99@gmail.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 E587E3A197E; Fri, 12 Mar 2021 04:03:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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=gmail.com
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 967BiiCMhsYm; Fri, 12 Mar 2021 04:03:23 -0800 (PST)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 93B343A197A; Fri, 12 Mar 2021 04:03:23 -0800 (PST)
Received: by mail-lf1-x129.google.com with SMTP id q25so45320857lfc.8; Fri, 12 Mar 2021 04:03:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xfHNosS7ZKbCLY0GQoIA7b6NcVC0Hs1w9h/DsCmA3KI=; b=DRsY6j/1D3LiW6ny8ftIDawQ3tkpqN1jePwpLynktiNpLiyULJwt/N8KxgZQtFJGdm xck5fstwSIuk9PCUhqrlo0NCjztzVLZU/0T9cM+816C/g0K4szLq9GaeGxKcKXjRB+aE urmGDp7QMxGCBHiKDucLVPqVbFeEHoelUFFfhotgbiDd7IQnQexFbvon3IEuYJSTmTI+ rh6fbbgeMiUSODaqefzzHviNrRKE+Ni2Mx+gMNLJj/t2q2T/8FWaVpiHJmFcl9DcdBK9 3YtwcmCNZIg5Onb89suQ07bnx1fiY29FlUVxy5AbfG+h/ZoC6ovRKuCNc5Bux7ZzkwNw ayug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xfHNosS7ZKbCLY0GQoIA7b6NcVC0Hs1w9h/DsCmA3KI=; b=exbxkrsfnI9G/3vi5L97NlupA9TdaNe+gp59suuFYcmkmDny5WgcMSButtWSaCA3tl a/BCJz1K+qTsxPHU3whkPXCM+VXGsb53sxbypWQp1nS2RmnaorChvtP7mfI1wvuiOvWZ i9TMDyYxe9tSCZad6fCdFGgfghjyQB1RFZ28P/l5euQx4nUGP7qbTwYwabVmwi0zqkPT QBJDuQWabJep2i9dkHlDSk7KlVCPBziSWrjK1yWQjXL56GRZHnWfy384F6wceXnwNfKe MBvOzbjabeVe+eRNk563BxH+jOwvKsu50M2rKf0rZuz7m1M093af9GAFiyzZP5HNorNw hltQ==
X-Gm-Message-State: AOAM5324J101tBhybfNZKH0X2m78VeTIRD0yQIoQMH3ncytNInnqHeN3 1EUTT1rLnWXaqwSW4JGv7yQ=
X-Google-Smtp-Source: ABdhPJwJlp9QrT6ac78aSwUqDKJWUFXEYI3asKEDckzo46mdFzNsSYNRQsKHELTjuAfw6mnJtHlkMA==
X-Received: by 2002:a19:ae0a:: with SMTP id f10mr5024235lfc.118.1615550599773; Fri, 12 Mar 2021 04:03:19 -0800 (PST)
Received: from jonathartonsmbp.lan (87-93-215-52.bb.dnainternet.fi. [87.93.215.52]) by smtp.gmail.com with ESMTPSA id 194sm1733061lfd.116.2021.03.12.04.03.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Mar 2021 04:03:19 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jonathan Morton <chromatix99@gmail.com>
X-Priority: 3 (Normal)
In-Reply-To: <494ffff907b21034b43f3ca8151f79d1.squirrel@webmail.entel.upc.edu>
Date: Fri, 12 Mar 2021 14:03:17 +0200
Cc: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>, "draft-gomez-tcpm-ack-rate-request@ietf.org" <draft-gomez-tcpm-ack-rate-request@ietf.org>, tcpm IETF list <tcpm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CCE0E8B4-3553-4F2D-A26A-54038CA09A0A@gmail.com>
References: <7af3375e51f849c1ad934a758c30279e@hs-esslingen.de> <494ffff907b21034b43f3ca8151f79d1.squirrel@webmail.entel.upc.edu>
To: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/9AOxxq24Q82XVoITzjgr8hqKxaU>
Subject: Re: [tcpm] Question on draft-gomez-tcpm-ack-rate-request
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, 12 Mar 2021 12:03:25 -0000

> On 12 Mar, 2021, at 12:00 pm, Carles Gomez Montenegro <carlesgo@entel.upc.edu> wrote:
> 
>> Example:
>> 
>>      0                   1                   2                   3
>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |     Kind      |     Length    |              ExID             |
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |I|X|Value|
>>     +-+-+-+-+-+-+
>> 
>> The bit "X"=0 would be equivalent to "R"=0, i.e., immediately request
>> ACKs. In that case, the 6 bit field "Value" could encode the value of "N"
>> described in draft-gomez-tcpm-ack-rate-request-02.
>> 
>> The bit "X"=1 would enable delayed ACKs ("R">0) and the 6 bit field
>> "Value" would encode the number that "R" defined in
>> draft-gomez-tcpm-ack-rate-request-02.
>> 
>> The "I" bit would be defined as in draft-gomez-tcpm-ack-rate-request-02.
>> (It may make sense to change the order and or naming of the fields, or
>> other details of the encoding - this is just an example.)
> 
> Yes, your proposal above makes sense!
> 
>> As far as I can see, there *is* a difference between this encoding and the
>> one in draft-gomez-tcpm-ack-rate-request-02: There is one bit less to
>> encode the value of "R", and two bits less to encode the value of "N". But
>> would that matter? Do we really expect values larger than 63 (or 63) for
>> "R" and "N"?
> 
> Yes, that is a good question, and it would be great to hear what the WG
> thinks about that. That is: are there use cases where R or N might need to
> be greater than 63?

My gut feeling is that values up to 63 are sufficient in both cases.

It might be possible to contemplate a different encoding which allocates more range to one use of the field than the other, but this encoding is simple enough to be hard to accidentally misinterpret, and that has to be considered a Good Thing and weighed against the benefits of any alternative.

 - Jonathan Morton