Re: [tcpm] tcp window size

"Scheffenegger, Richard" <rs.ietf@gmx.at> Mon, 22 July 2019 20:29 UTC

Return-Path: <rs.ietf@gmx.at>
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 2C3A11200CE for <tcpm@ietfa.amsl.com>; Mon, 22 Jul 2019 13:29:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 C-IMMEW88EBQ for <tcpm@ietfa.amsl.com>; Mon, 22 Jul 2019 13:29:17 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 6D3CA1200A3 for <tcpm@ietf.org>; Mon, 22 Jul 2019 13:29:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1563827354; bh=DXCXq70CkLbxO/Of6xwnjaTaEKov17iFLqBn4iHjw5U=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=itzu+YTMATmnjy0VSzy4YAzpbUQJtUPzesZ+clxvyHIuGJ2exDqB7tIlh7uJoFwoG DNoW6AgDY1jTPdOuZ9QatVf8GPoD7NLx6GPKSQoMQnkjy7Yu7+MGC4gEvWfhlf4HNd gqZm6YfSuReh8QS/ykSzWVX6AcINHz+hw+Z/unJU=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [31.133.136.206] ([31.133.136.206]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LdKs1-1iGVD02b4b-00iQkT; Mon, 22 Jul 2019 22:24:03 +0200
To: Yuchung Cheng <ycheng=40google.com@dmarc.ietf.org>, Marc <gaardiolor@gmail.com>
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
References: <CAPxJK5CO3HBX=-ajd0=M6hXwdbEPwANheExQZtQeac+J3BwM2A@mail.gmail.com> <CAK6E8=dhqEGLOyTwW522b2nNua=KdQdv-MgyM_ioj05i3+ARKA@mail.gmail.com>
From: "Scheffenegger, Richard" <rs.ietf@gmx.at>
Message-ID: <c02818a5-2dc9-bc7d-23eb-c646dedee161@gmx.at>
Date: Mon, 22 Jul 2019 16:23:58 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CAK6E8=dhqEGLOyTwW522b2nNua=KdQdv-MgyM_ioj05i3+ARKA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:bf4buxSezGAS3U/c6f0Ujuh04S4BDRqQdcUYhcFZm7F+YP1+YSD WX4ONdea8t7c1bMzFnWoxUsv35mvwJHoF61E/yIiFiEBK+MfVyq/R9obusPwiUIIeYm8H8n E3tlf2T3DakcCu3wxRWERK0/xLyIOKm2pw1H2En40V/lAyIaSR6cSDZP8to7yGWTIzYSI9A I/a90ZoiGP60aSbhhXzGg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Jge6AN7TpSE=:eP160HLdz+2ILImFeLFJPc rX67YFLTDU+060jQQ+0LrkGhG5PClzpJQ/GaCh7japeqN4ZUhR6qZ15Nw6aPi2E52wG7SDbVU aRBPl2tTx1KUmWRPv0U5C/yQZqf66lPYnemfPrcSihKGiQhOvnxphC5LcbJVvtmREbqe2Qhch FRuuFNYKJbtcLyu/zlEVd9F7G2olkY4gBLM2/+giz1HB0SUHZOjd+AJ40aBiMy7d1wiWAWFhK /BNPW8ngbCxumsnBhvsucKW7gWizqHhrJDJ41u3q7o5PKZGz891jD3zh215N6YVidDL488zwc 6F3nsG8++ImzciWC0Z3wE2d09Cq34f6bIEeGHAEDO6FaERtrtU/UsVIt6tP2CU0w9XIIYXhxq M0FKlcEMmbTl6eLfOJl9hfKF+u0+LMtxxIpDquIV7oJHHP8fz/DQNeI79KjV2YR34RZF/uHOU YnmJoEtKSdITKtqci4xAj44kWkR0wSw1O0OfUyGeh/ibJ/HYzznnAQpT+oQIseahXI5gv6BJP wWFrBqCeMpBi73Ot5lQjL2oTwdei1CbYBqXXSJvlL5Gz0Kfb/VquY4Gl5jPvecbLyT35mQ8gI v7HaDEPd3kfIuClGU/vqfMQMg7ySu6jWIibj9tytNvDoaMVLFAZmHZdYK1zx+G4GcPolbib6f sbZuSsW7wRGqPTz2PtXvfge9Ql/3snK3cxRL8iqbn4qikGnWu9YM0d9PbKyioA2xRglVcCb3B +WAx+NANZJsF2M01PH89POdxKxnA7ZbKxdvUWNRCXi+0i6HD3ashwKS4R8UO+CpmaxFnocDHt L5J1Yz7xfVw0BsxPCLWO1wI9XPNjWk3TrsrlUMHBPGOtH6ivqINm8QLmjEYWQr1w/5tTtFa7G eKX+wL/dUXSTGhknqejcBL/FUO++zNrUISF4qg7hHBu/mKvqHzsZwgb+wp2bDG8LdES8qM5ys kdS7VZtkFsIORvYhuUTQtamTn+RU1Bh+qQG5Ta+VJwTLbi3YSXyFFO92KHkcp93xe+kOWjc5a CMZx4CCPiPRZZJYb9ReiaC21MCK0oZqh4rNh2Sul9smFglP/ieJPAcobUGx23vBIGiGZP85n+ 6GYZs+2/lsVD/U=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/5p8Q8vHcusQrDviSDWVd2Gs3Usw>
Subject: Re: [tcpm] tcp window size
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: Mon, 22 Jul 2019 20:29:19 -0000

Marc,

remember that in effect, the smaller between the sender's send buffer,
and the receiver's announced receive window can be used at a maximum,
since the sender has to hold on to any data until it receives positive
confirmation of delivery - in case the data has to be retransmitted
after a packet drop...

Regards,
    Richard

Am 20.05.2019 um 12:53 schrieb Yuchung Cheng:
> On Mon, May 20, 2019 at 9:23 AM Marc <gaardiolor@gmail.com> wrote:
>>
>> Hello experts,
>>
>> I've been trying to find definitive information about tcp window size
>> negotiation, and if it exists at all.
>>
>> Take a browser that downloads a file (receiver) and a webserver (sender). If
>> - both sender and receiver support window scaling
>> - the receiver advertises a TCP winsize of 256KB
>> - the sender advertises a window size of 32KB
>> - the sender has enough space in its TCP send buffer
>> (/proc/sys/net/ipv4/tcp_wmem on linux)
>>
>> How much 'outstanding unacked data' is the sender allowed to have,
>> 32KB or 256KB ?
>>
>> I can't see any logic for it being limited to the window size of the
>> sender (32KB), I think it depends on both the receiver winsize and the
>> sender TCP Send Buffer Size, but I need to be sure.
>>
>> Reading https://tools.ietf.org/html/rfc793 also suggests there is no
>> such thing like window size 'negotiation' and each end of a TCP
>> connection just advertises its own to indicate how much data it can
>> receive, independently.
>>
>> Is that correct ?
> That's correct. It's FYI not negotiated.
>>
>> Thanks!
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>