IETF Logo Mail Archive

RE: Splitting transport and application error code spaces

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Thu, 17 August 2017 06:14 UTC

Return-Path: <mikkelfj@gmail.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 1471F124E15 for <quic@ietfa.amsl.com>; Wed, 16 Aug 2017 23:14:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Level:
X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 g5Ceep7PYBFt for <quic@ietfa.amsl.com>; Wed, 16 Aug 2017 23:14:40 -0700 (PDT)
Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 7B48F1323B1 for <quic@ietf.org>; Wed, 16 Aug 2017 23:14:40 -0700 (PDT)
Received: by mail-vk0-x22d.google.com with SMTP id j189so19264058vka.0 for <quic@ietf.org>; Wed, 16 Aug 2017 23:14:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=UfDW7oWMD3TGt7Tx1KjQFMea2CXpiGQfzaZ1kaDp4IQ=; b=QLOTsQKX6o3u/2ixHweS+tqv1UZ8+XjI/VGKZRGz80zhd11cTXvjc6eLzoBmAbG3sa UKeX3aw+yvO6Yt1RJvzz+H5+KNttGOfH9dKMif+JXITf3zCPfRBA/ACqhSliWJaiN1XR Cda5wN4tPSJ400OVXckcecj+40osH0UojVwT8RCRp/SMMOruh/XJSfu5/qNb5y970zdN Lw1rjI8DFxiECSZ16un64SKRGy5HnTEiFddA3mmRyxyChhhi0IYH5J9KkJ68adYxMTaD T9o5ff4KEfW0G2GiWC9t9us3Weg0hM3Spr4HK7rFc6UMKiB73iXl/1JocOxRsE3JttZR 5Nhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=UfDW7oWMD3TGt7Tx1KjQFMea2CXpiGQfzaZ1kaDp4IQ=; b=cKg0T8nKRJuqfKtT6XhcBhjD0f2FqCBjvVWLx1obUCZJl+g328neMKRuRT1sG0uzmz xq15KL4hd1+lGKOWh6QeHAeCNyqvekOB+Fe79S7I7ofraI5kmexyNpIeU3O7v+/amUzu WrMEwqIwlT7Dyf0MHoaFpJMIpkxTTGs9DMmLKa+mB1HTwfKBpeI49UZiThtFUqo4iH3M Pc6sLcRj7ycZz7mBQQ1TgrTjWjYFclmNVxgiXbriSqSN3KEhGZIvO32VEt09+Ztk9P47 KCCKcqSiaIUyy66mu33Ec1ZnKmZ23zpaiLq3YB2/H822f0gRMOlpfz7wG2G99ElOsyJB iEhw==
X-Gm-Message-State: AHYfb5hRsIofFKxbhZU9TAtg/JBlcwjm2VczqZ8Ns6EEIjmdSMnAQQgQ xZvFwqDLWpDOBoJqH507ESXNhvW42Q==
X-Received: by 10.31.54.215 with SMTP id d206mr2896833vka.24.1502950479595; Wed, 16 Aug 2017 23:14:39 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 17 Aug 2017 02:14:38 -0400
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <4ad8822827db4086a06442e2543cf9ac@usma1ex-dag1mb5.msg.corp.akamai.com>
References: <CABkgnnXcjaqXeRLq=+W98HnubFSEy_DWB7PbaK8GEDUK+Wvetg@mail.gmail.com> <CY4PR21MB0136EE9B4C91C296860A38F687890@CY4PR21MB0136.namprd21.prod.outlook.com> <CABkgnnU6gP++XeByfz3ML75VCuowrDA94DvjijZxL=sRCBiOSA@mail.gmail.com> <CAGD1bZYv8LDuyOH=tP1wDk+Ja+=Yy1MYAGLUxtyB2DpBLXdqwQ@mail.gmail.com> <CABkgnnXDc8Fzh0Y6yB9BUWxtXi2kcfKTS+=znPPvuppHRdA3ZQ@mail.gmail.com> <MWHPR21MB0141C504874E7704D62BF388878D0@MWHPR21MB0141.namprd21.prod.outlook.com> <CAGD1bZbUu63JH7EvJWHdOFuNG+qivkvx_dMv=H4Vjnu1rz5tUQ@mail.gmail.com> <CAN1APdfDOCahTpyzTOn7m5pL41LubUMVe_Di5oGQ0rg-TbszPQ@mail.gmail.com> <CABkgnnXDQxuznEv2+OztOUke2FM4Ni00FAeCvErXOugDFp=68Q@mail.gmail.com> <4ad8822827db4086a06442e2543cf9ac@usma1ex-dag1mb5.msg.corp.akamai.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Thu, 17 Aug 2017 02:14:38 -0400
Message-ID: <CAN1APdfrEk1c_9n6iKTE-zgS4u=H+wpHqdO-jm1R2AJ0g6eBYA@mail.gmail.com>
Subject: RE: Splitting transport and application error code spaces
To: "Lubashev, Igor" <ilubashe@akamai.com>, "martin.thomson@gmail.com" <martin.thomson@gmail.com>
Cc: "michael.bishop@microsoft.com" <michael.bishop@microsoft.com>, "jri@google.com" <jri@google.com>, "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a11439272738ffd0556eced5c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ndvbeIs31i80keNEVR4oWHfiuLE>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 17 Aug 2017 06:14:43 -0000

>  An application on a busy system that has written 100K to the transport
might not receive and process the STOP_SENDING request and then ask for a
stream reset in time to save a large chunk of unnecessary data from being
transmitted.

That is a good point. It is rather relevant in high volume async
transmission scenarios. It can easily be much more than 100K via mmap
transmit references. In some cases that application might not even want to
know about the stream after forwarding a file handle to the transport.
STOP_SENDING might be initiated by sub-process termination.

In other words, there can a be simple process/resource control layer
between transport and the application that does not know about data frame
formats but still manage resources. Without STOP_SENDING at transport level
this might be difficult to implement in a generic fashion.


On 17 August 2017 at 07.54.19, Lubashev, Igor (ilubashe@akamai.com) wrote:

The response to STOP_SENDING may be faster if it were a part of the
transport (especially if QUIC transport is implemented on a kernel level).
An application on a busy system that has written 100K to the transport
might not receive and process the STOP_SENDING request and then ask for a
stream reset in time to save a large chunk of unnecessary data from being
transmitted.

Other than this, I can see how moving this frame to the application is a
minor transport simplification.

-----Original Message-----
*From:* Martin Thomson [martin.thomson@gmail.com]
*Received:* Wednesday, 16 Aug 2017, 9:46PM
*To:* Mikkel Fahnøe Jørgensen [mikkelfj@gmail.com]
*CC:* Jana Iyengar [jri@google.com]; QUIC WG [quic@ietf.org]; Mike Bishop [
michael.bishop@microsoft.com]
*Subject:* Re: Splitting transport and application error code spaces

On 16 August 2017 at 17:32, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
wrote:
> If STOP_SENDING is moved a basic application will no longer have a
language
> to communicate intent.
> This is perhaps a broader issue - but the question is: what are the
minimum
> primitives a basic application with no advanced higher level protocol
needs
> in order to move data on multiple streams? It relates to adding bidi
streams
> on top of uni streams.

The assertion here is that STOP_SENDING isn't a necessary primitive.
And it isn't generated or consumed by the transport, even if the
effects (RST_STREAM) are.

It is useful in HTTP, so HTTP can define it.  We might see something
like that if someone ported (for example) websockets to QUIC.  I can't
see it being used for DNS.  I might speculate and say the same about
RTP, but that's so nebulous I'd likely be wrong.

v2.23.0 | Report a Bug | By Email