Re: flow control and DATAGRAM

Christian Huitema <huitema@huitema.net> Mon, 29 October 2018 22:29 UTC

Return-Path: <huitema@huitema.net>
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 2E069131030 for <quic@ietfa.amsl.com>; Mon, 29 Oct 2018 15:29:05 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 SMOI8aaGLhyc for <quic@ietfa.amsl.com>; Mon, 29 Oct 2018 15:29:03 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4D29127133 for <quic@ietf.org>; Mon, 29 Oct 2018 15:29:02 -0700 (PDT)
Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx35.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1gHG1r-0001db-Np for quic@ietf.org; Mon, 29 Oct 2018 23:29:00 +0100
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1gHG1l-0003Zb-CK for quic@ietf.org; Mon, 29 Oct 2018 18:28:57 -0400
Received: (qmail 20901 invoked from network); 29 Oct 2018 22:28:51 -0000
Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.56.42.225]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <ianswett@google.com>; 29 Oct 2018 22:28:50 -0000
Content-Type: multipart/alternative; boundary=Apple-Mail-116CD75E-F367-49B3-B076-0B94A107B7D9
Mime-Version: 1.0 (1.0)
From: Christian Huitema <huitema@huitema.net>
X-Mailer: iPhone Mail (16A404)
In-Reply-To: <344a8a30b95441af988b675c2f887965@usma1ex-dag1mb6.msg.corp.akamai.com>
Date: Mon, 29 Oct 2018 15:28:49 -0700
Cc: Tommy Pauly <tpauly@apple.com>, Jana Iyengar <jri.ietf@gmail.com>, Ian Swett <ianswett@google.com>, QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
Content-Transfer-Encoding: 7bit
Message-Id: <A8DFD881-924E-4838-8056-9FDBC9D3791D@huitema.net>
References: <CABkgnnU26aYD=TybuD0FZGYtfEa6np-Sk3Jo6t7LRp0wzKh3Lg@mail.gmail.com> <CAKcm_gMDOyJC0AwOo2knN6AMxVbySjGsrLvjcC9A8UA9xcvcWw@mail.gmail.com> <19D3595B-8845-45B6-A60D-9E934DD49FAC@apple.com> <CACpbDcfk+GXb3aL5LG0wQM87thRGO5Y4Q+9cbXf5YuW1=jWCig@mail.gmail.com> <B7BE2454-2A4D-4323-B0A5-0D73BD4B819F@apple.com> <344a8a30b95441af988b675c2f887965@usma1ex-dag1mb6.msg.corp.akamai.com>
To: "Lubashev, Igor" <ilubashe@akamai.com>
Subject: Re: flow control and DATAGRAM
X-Originating-IP: 168.144.250.232
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.23)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5hjWGYCzUh7YG8fkBxPHR8h602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVi+vRj6yzEgvVZTGazwRo55s7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB6nkU4uouGtaIPSwAALHVjh/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJE2d52fY0d/1mkgffWkdO 4QEiRQv+PVjjwa+Z5RFCOMTc/0DL0kGticgfK7BXdIl5xnsMi381k+gKZDYa33nZ/Q2hElfCmYHd K/F6jFUrRk5k354Leo8WHhg9Xcph2esmZk4AVtnYApSiFQp1w3dnUoiPn/2xNqt6sQVacVXeY6AU 1zqm/evfkH8cHl25+qKdJvWZ9M/O6eVqbri1Q0O8/x2vWOKTBJk2Pbgs7SLYxsDtOMdZHeKLxpi2 To9NNZ6PS0eJxHqSOPlqEdtb5t20uHG5BnVj6tDKYf18xfK0O5gaJ/Nk40anfxYE/e+AHCqTw6nI oDr0sXUZ7YZoZ/GZ+u+WjISfXGa/P6JeP9Rx/xr6vvsamCqhsCKWQTQWW5aiOYN2LGYOY+RZZ70I EJvMPP9qwM7RXpJS8RjTdyh2j5BSM6Vge5/tyLofFHTUZzjpzRBCCyVCnQKBwcrUTMoPTDRj9D8H LKHAKpPGP8EPnuBvlPE9yn4+7R7hw716lUpV
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/BvZ5pDlBCd98pNT3lv-6e6azQmY>
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: Mon, 29 Oct 2018 22:29:05 -0000


> On Oct 29, 2018, at 2:28 PM, Lubashev, Igor <ilubashe@akamai.com> wrote:
> 
> > ACK to a packet containing a DATAGRAM frame means:
> > - The packet made it across the network to the QUIC endpoint on the other side
> > - The QUIC implementation will deliver the DATAGRAM frame to application (it won't drop it locally)
> > 
> > Does that make sense?
>  
> This only makes sense, if there is an effective flow control for DATAGRAMs.  The spec should be implementable by poll/read QUIC implementations as well as by callback-on-network-receive-thread implementations.  Unless there is an effective flow control, a buffering QUIC implementation must be able to discard DATAGRAMs, if the receiver app is not catching up.  The receiver would then have to ignore all non-DATAGRAM frames in that packet, since it would be unable to ACK the packet.  If the receiver is processing DATAGRAMs and STREAMs at different speeds, deliberate discards of packets containing DATAGRAMs would interfere with the congestion control, effectively HOL blocking STREAMs.

On the other hand, Datagram will be used to carry the media flows currently carried over RTP, and RTP does not include any kind of flow control. 

The known weakness of RTP is the lack of integrated congestion control between data and media, do that a parallel data download can jeopardize  the quality of the real time media. But that's an argument for counting the datagrams in the congestion control window, not an argument for flow control.

There is an argument for controlling the rate at which media is sent. But that's typically done at the app layer, by negotiating codecs and compression parameters.

-- Christian Huitema