RE: flow control and DATAGRAM

"Lubashev, Igor" <ilubashe@akamai.com> Mon, 29 October 2018 22:50 UTC

Return-Path: <ilubashe@akamai.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 7E1CD131021 for <quic@ietfa.amsl.com>; Mon, 29 Oct 2018 15:50:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.17
X-Spam-Level:
X-Spam-Status: No, score=-1.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 HSCZ3RnKCvrz for <quic@ietfa.amsl.com>; Mon, 29 Oct 2018 15:50:20 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 605D61277CC for <quic@ietf.org>; Mon, 29 Oct 2018 15:50:20 -0700 (PDT)
Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.23/8.16.0.23) with SMTP id w9TMklEW018559; Mon, 29 Oct 2018 22:50:08 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=CFb0dUov7XwlgtsPR2xJge8rQEqBsH4uV5MKwbEm3+c=; b=jZQfc4lFHDjDli1JDTHMj5wnuMDs807Y05fJsqk+IYU/wQ6XS7eqPctqjpWXQnSby8t7 yH0xjWVxbgAvZHnrbPTfldp8isWkIwcj8NCgdW6S1bQGgpnnyGq/pyVrLVS9xuBPgXdG x730BVD8Db5pPy021/IfY9vsQfHb3B+x9uU12resWtew10N/to5kjamiSy/bCaigDxGK KZRI/OnxJRNp+JfBcC++txQjvzAJoisCWQH6FYXVze7RxQuPKEjM/B/AEfYWdtDRldxT 42D3o5XfFfTTu9fPwZjMZXxJCSUr1cENCLTuTel/aMZ89r8SGuzPr5pmR4kzUpo2vLx7 Og==
Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2ndgbebtva-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 29 Oct 2018 22:50:08 +0000
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w9TMZAaw020419; Mon, 29 Oct 2018 18:50:08 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2nckbw99np-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 29 Oct 2018 18:50:07 -0400
Received: from usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 29 Oct 2018 18:50:06 -0400
Received: from usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) by usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) with mapi id 15.00.1365.000; Mon, 29 Oct 2018 18:50:06 -0400
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Christian Huitema <huitema@huitema.net>
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>
Subject: RE: flow control and DATAGRAM
Thread-Topic: flow control and DATAGRAM
Thread-Index: AQHUb0aOcr0oK2RjxUS//IweRKrnD6U2a2QAgAAvQ4CAAEeKAIAABpaA///KoZCAAF6fgP//wVTQ
Date: Mon, 29 Oct 2018 22:50:06 +0000
Message-ID: <a32685f0c2644b74a37e9598700a734c@usma1ex-dag1mb6.msg.corp.akamai.com>
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> <A8DFD881-924E-4838-8056-9FDBC9D3791D@huitema.net>
In-Reply-To: <A8DFD881-924E-4838-8056-9FDBC9D3791D@huitema.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.38.233]
Content-Type: multipart/alternative; boundary="_000_a32685f0c2644b74a37e9598700a734cusma1exdag1mb6msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-29_13:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810290199
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-29_13:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810290201
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/7CBQiuk8l3_OhB9UBu5aKH70mb4>
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:50:23 -0000

I think we are in an agreement here.  One design alternative is no flow control (only congestion control) for datagrams.  But in that case, the assertion below does not hold, since the second bullet is false for “poll/read”-based implementations (or any other implementation that is not based on “callback-on-network-receive-thread” model).

> 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)


  *   Igor

From: Christian Huitema <huitema@huitema.net>;
Sent: Monday, October 29, 2018 6:29 PM
To: Lubashev, Igor <ilubashe@akamai.com>;
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>;
Subject: Re: flow control and DATAGRAM


On Oct 29, 2018, at 2:28 PM, Lubashev, Igor <ilubashe@akamai.com<mailto: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