Re: partially unreliable quic streams

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Tue, 19 September 2017 07:45 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 26939126DFE for <quic@ietfa.amsl.com>; Tue, 19 Sep 2017 00:45:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, 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 fb7aEw2iBcxi for <quic@ietfa.amsl.com>; Tue, 19 Sep 2017 00:45:00 -0700 (PDT)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 CBBEA133057 for <quic@ietf.org>; Tue, 19 Sep 2017 00:44:59 -0700 (PDT)
Received: by mail-io0-x231.google.com with SMTP id z187so7915233ioz.12 for <quic@ietf.org>; Tue, 19 Sep 2017 00:44:59 -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; bh=uBA/5EUSIl+5tSYFDd5+ejHtizpv7EgWsyGoNjAUDo4=; b=C+2b4v9LGUc1a4xfSNIP8FlQIL5h0HDn8qah7vP2Ch/s+cdo+0qKy2Tm+kM2fKWGyg rKMyEVhQdqkMR32qrRDMuCcbu5JXatSm1tjVcuHxonuLVaWylndmrunRLeyrw8x37FjN 5gtRPddH07VZyPnW+QL5eseKT0bMn0+vg+wbbn0a83dQXYPrPCAIdnPICKJLrIT9Q7Fk ZxHfxQS1jbOjeF6M5Y0O1JZPcEFRAddZJtjd4vxLJVZajF9fr2wpmcQkv89NigMqGiKI H5pISfWj2lpLwVpaJHi4KEzVhJiY9oJcdsefDDCgcQjEdViiJ/HxEliQEdA0OxsxTZB8 06wA==
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; bh=uBA/5EUSIl+5tSYFDd5+ejHtizpv7EgWsyGoNjAUDo4=; b=ImUXa/ve+RvbwUmuxjkIW0sFAHorsuIf2ZgmlvmD2vHl72TDQfLbdcUbCC69CmlCCn 3OhqFAtXdJfY7C4ViksDC6OuGptklX8tCeK+rXB2m+ac6MiZ2aWbC/vwUwJUJUUHpxy3 Kd+LqaMtjT5qkJF3TdVaiN3sjVmKsMPTtysP01ntANpfLJlfwqb98uIZRuFtlqRsAt8G cgFXYXpdMppqgBCTi70oQ0I/Vm9oTf3aZY8Cv0LHWecRRK1zcO4A0GU0BcwkcvLmfEgJ gVFf9zj1L8Kh0ruAWtq11Yp/nYbdH9rm/NRpXkvgYcvaEXMpS4+RECv7me6qHyW7jrL/ X0sg==
X-Gm-Message-State: AHPjjUggQL6ghprMkNoaRPReZl65TnKgfdui/e71LB+W9Ol/Khntlm5g kjsuZvnYzP5+mdX8iAgxMMk8ziDxKYkb1jIlbjI=
X-Google-Smtp-Source: AOwi7QAk5DQxcCpeGGtyRN5msY+2CGnER61TmUlnlj7oWV5lsZ0v8d9ChQm9NASpr0OCYe5byDsqZXYQShR+vpjG5qE=
X-Received: by 10.107.166.206 with SMTP id p197mr657977ioe.63.1505807099189; Tue, 19 Sep 2017 00:44:59 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 19 Sep 2017 00:44:58 -0700
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <CAN1APddnAmjc2LuMReCHXMSABD1_6nHkn47_BD1KcmD8Z4ENUw@mail.gmail.com>
References: <CAN1APddnAmjc2LuMReCHXMSABD1_6nHkn47_BD1KcmD8Z4ENUw@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Tue, 19 Sep 2017 00:44:58 -0700
Message-ID: <CAN1APdcf7zgryrdWnv5jwkUX6p0ZEgKUWyoSsB1KH0S6SkGCxQ@mail.gmail.com>
Subject: Re: partially unreliable quic streams
To: ott@in.tum.de, anja@inet.tu-berlin.de, quic@ietf.org, philipp@inet.tu-berlin.de, mirko@inet.tu-berlin.de, balac@inet.tu-berlin.de
Content-Type: multipart/alternative; boundary="001a1141d0823f5c4705598609ba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/lG7kSFC5yMUe0NqI_xRthyc_GRA>
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: Tue, 19 Sep 2017 07:45:01 -0000

Sorry, forgot all authors

Kind Regards,
Mikkel Fahnøe Jørgensen


On 19 September 2017 at 09.21.58, Mikkel Fahnøe Jørgensen (
mikkelfj@gmail.com) wrote:

Hi Anja und Jörg


Regarding
https://tools.ietf.org/html/draft-tiesel-quic-unreliable-streams-00

I’m not sure where this draft fits into to the QUIC design process process
since my understanding is that unreliable streams is for a later charter in
the design process.

A quick read through the draft makes me wonder if you considering some
partial reliable ideas that have emerged out of the currently unfinished
concept of unidirectional streams and if you can incorporate these ideas
into your draft?

Essentially the idea is each stream is sequence of messages which are
reliable but suffer head of line blocking when each message is separated by
an application specific message header. In the simplest form the stream is
just one message.

For unreliable streams, the concept is inverted: each stream is a single
message which starts an application specific unreliable stream identifier
embedded in the stream/message. The ordering of messages is given by the
QUIC level stream id which always increases (effectively a message id in
this context) but there is no head of line blocking nor any delivery
ordering because each message is independent.

Thus the space consumed is the same for the two concepts but the
interpretation is different.

An implementation can further cooperate by not retransmitting sufficiently
old or otherwise outdate messages. Currently QUIC has no way to explicitly
configure this and dropping retransmission of frames might affect
congestion control. Therefore in its current form QUIC cannot properly
unreliable streams, only prevent head of line blocking.

It is worth noting that with once message per stream there can be many
messages per packet which can significantly increase the messages per
second rate and therefore also requires efficiently management of stream
state - such as discarding send state immediately after sending FIN (except
retransmission machinery).


Kind Regards,
Mikkel Fahnøe Jørgensen