Re: How to avoid kernel's receive buff full , then UDP packet dropped by kernel?

Ryan Hamilton <rch@google.com> Fri, 29 November 2019 23:52 UTC

Return-Path: <rch@google.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C795F120133 for <quic@ietfa.amsl.com>; Fri, 29 Nov 2019 15:52:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 cKfJ-0_jsyUa for <quic@ietfa.amsl.com>; Fri, 29 Nov 2019 15:52:38 -0800 (PST)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 DA64B120033 for <quic@ietf.org>; Fri, 29 Nov 2019 15:52:37 -0800 (PST)
Received: by mail-wr1-x435.google.com with SMTP id z7so33555189wrl.13 for <quic@ietf.org>; Fri, 29 Nov 2019 15:52:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iXPxZ3Wu65X9eiZ9WyVCuR00ptiRDJyeDmqpWPNE6jU=; b=nrOVNa+WPW8K/SLEoIu9sGQFvYNi6S2sYUKksmyUtpIJWDXZVSc6JE1Dd976TKxplR bFOWqUNXNLyGpfZjZhsyoVSXR0aRipCdKDfvheeuavZG030DLNN26KPVgunPqX5b2mzi aUqGP2+AYrOn3IPgzW5sJ7x6gft8jWvGnAncrwOXMYUpEVPOu72/jYK3vTHaxS1z2Qzv mlIY24CqlKG74Odycllcpap1zlCD5THsrnKDeh7pazD6d831Clqri4cy/fwp6FmgIhiA 7n86c2W52QE0WNfyNceE1Z031Xlzn53jubqQwLgaDSFGjUouCimmRU2zJkgLtOaK4xsB CllA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iXPxZ3Wu65X9eiZ9WyVCuR00ptiRDJyeDmqpWPNE6jU=; b=td0Hrl++o8UeoOaCmfEaXuh76VOXWjmYc7LHyX7cFqHZk2u/faQ8WzPj+jS/qFjf9M 7PbuLYaoSQUgp6LShLAO+7fJunPaKY0rhJSU+OgHfR+uFIFIjvu/fkZLT/VRrktDFAK5 WCy31Zrgwwa1IFHYfGg/jTTqwdy2bJH/I7ESWXJX9UyHARWRPTKZRxDH0c2htt5AtCRE PAW3UidtIDRfibryUpCSNsgc2G1yECFbR25tz+DOiGqb9S9A6MTqrvtId56nS6Ym+Md0 IhfaahkiIvBepJ6rUACzIJBvFmbwS2Td8oKQD/rZJmJ+wNIg+Fh3WsWDFXXPVu4Ncd54 RZFQ==
X-Gm-Message-State: APjAAAXEjc0PNC7H2sJh0Ocb0gYCuxrECRI/Edt1Bk4Mv+dE+fd8bh98 mQlNpXAXxm0lNPljzKWe/Rm8RorFMqTepcchmyVA2w==
X-Google-Smtp-Source: APXvYqxIkMjq8CSoZ6Rsbj3slj8mybhutvAOe1uqB1K/5N9QIt42nyg0xxLMocJazrZBBrEp4jOF4QcDYugv2eoUHxE=
X-Received: by 2002:a05:6000:50:: with SMTP id k16mr55402801wrx.145.1575071555833; Fri, 29 Nov 2019 15:52:35 -0800 (PST)
MIME-Version: 1.0
References: <CAG9+TpZgm1zbW2Zq9oPCprmgUr-Rh29RTmGyEcVfE+T-i1WvaA@mail.gmail.com>
In-Reply-To: <CAG9+TpZgm1zbW2Zq9oPCprmgUr-Rh29RTmGyEcVfE+T-i1WvaA@mail.gmail.com>
From: Ryan Hamilton <rch@google.com>
Date: Fri, 29 Nov 2019 15:52:24 -0800
Message-ID: <CAJ_4DfTk11C60LsRhv8Fr_jypxQiweyx0hQnumY_fQHBey-42Q@mail.gmail.com>
Subject: Re: How to avoid kernel's receive buff full , then UDP packet dropped by kernel?
To: Jiuhai Zhang <jiuhai.zhang@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009558bd059884ecb1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/0p3_hM-3C2oo6xk233aYarTfsng>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Nov 2019 23:52:40 -0000

On the server side of a QUIC connection, the UDP socket (and hence the
kernel receive buffer) is shared across multiple connections. As such it'd
be incredibly complicated to come up with a system to handle this and would
likely result in unnecessarily throttling throughput. On the client side
(where there is once QUIC connection per socket) this is unlikely to happen
if the receive buffer is larger than the BDP of the link. Of course, in
reality, if the application is reading from the socket frequently enough,
this is likely a non-issue.

On Fri, Nov 29, 2019 at 4:53 AM Jiuhai Zhang <jiuhai.zhang@gmail.com> wrote:

> Is there any good idea to solve this? How can we do flow control like TCP
> receive window size? User space can not get how many receive buff is used
>