Re: Proposal: drop QPACK encoder stream framing

Dmitri Tikhonov <dtikhonov@litespeedtech.com> Thu, 07 June 2018 19:03 UTC

Return-Path: <dtikhonov@litespeedtech.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 CCC1D1310E9 for <quic@ietfa.amsl.com>; Thu, 7 Jun 2018 12:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.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 Gjl-pRWjbswQ for <quic@ietfa.amsl.com>; Thu, 7 Jun 2018 12:03:07 -0700 (PDT)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 B03B41311A5 for <quic@ietf.org>; Thu, 7 Jun 2018 12:02:34 -0700 (PDT)
Received: by mail-qt0-x22d.google.com with SMTP id x34-v6so10982230qtk.5 for <quic@ietf.org>; Thu, 07 Jun 2018 12:02:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=dDdCKLswTqMvSgQIuSEoNcfsCxm7gib5ldudLmMy4kI=; b=UvbuGamgZ1k9bxRY48HpgEY4Mx8cUc43L5ERk85BBFzSY86zLq/hXUNualSTn9fGhp y1tSV47Ft71nqTNPZIP6PaU8CYJwXoY1b/zy+A4E9zVKobP7Tgdx4mSgZAp9/vr5o7J0 /kkSb3/4AYy3MOYzh6QqmfrHwA6VNpl4Gb3dSSNOheTo7XdbCGn45C21+V+zxeYu41t6 ODyXHufrB9cy0B1S8TjfSXRz4RnLDNjJSJoSWsvpb8s/WlZjl9YRfIWJSuw+zaXZcbtY Rain6UAzkOTdwAKl2GTCyZY5XTnVAZsMfq0IEE3TBKT5l76Aw3r5eCwk1/QxF7j0tH47 xxpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=dDdCKLswTqMvSgQIuSEoNcfsCxm7gib5ldudLmMy4kI=; b=lgcBXymbeLgfl0rCUCfXz011btSyDfvGAqAhYeSsg5ojijKRoGytrE1f9N4vmb8e5Z BwGeQaj7s2P1uQTMZsvc7CaF4dbaHDRTxpAwY4sF+87SLUPZszHsiyT2aFx8Ifz/ka0q 6Dst2uykEmQeYJdVtVITpC7P5mhWqQNWiIpu9iZmjCtiObvBl3usWcE6EqOB1xBEoM8v Srf1uziTU00m1+dyqUZpS/ofR9ih1E3dBEGM8inkm8EkhENBcWa4i28aPBMGXC7L49Zg L9m8XxyP5UgtAPT5h4ez3JmUQRr0Ip6EHnX4XLpTwyrWuYl/lXWPQzUXTw5PjdtjTwAG PrNA==
X-Gm-Message-State: APt69E3lx3QG3NTl3S3AIDxSKpxpViRj1AMPrFn2ItQuLxqTpopS3fG8 EU+dHbZ/KmnZorrICWXhxblbzQ==
X-Google-Smtp-Source: ADUXVKJfaWFPYOFKxmdfZpyJKdVZU6DXAScWMrfVfGMqvnuiUIz74q7uOX0j0uc4y9oiTkuYK+a0kg==
X-Received: by 2002:ac8:329:: with SMTP id q41-v6mr3066464qtg.369.1528398153770; Thu, 07 Jun 2018 12:02:33 -0700 (PDT)
Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id h23-v6sm13065213qtn.79.2018.06.07.12.02.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jun 2018 12:02:33 -0700 (PDT)
Date: Thu, 7 Jun 2018 15:02:27 -0400
From: Dmitri Tikhonov <dtikhonov@litespeedtech.com>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: Proposal: drop QPACK encoder stream framing
Message-ID: <20180607190226.GA4187@ubuntu-dmitri>
Mail-Followup-To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, IETF QUIC WG <quic@ietf.org>
References: <20180607151112.GA28823@ubuntu-dmitri> <CAKKJt-cCqFUdVUGtGe1oJWzyFVnm7bTneprQ4ShssfVj0cEtKw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKKJt-cCqFUdVUGtGe1oJWzyFVnm7bTneprQ4ShssfVj0cEtKw@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/QkBsJCc2fibm5uMmULV0jR8rfj4>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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, 07 Jun 2018 19:03:15 -0000

Hi Spencer,

On Thu, Jun 07, 2018 at 11:55:23AM -0500, Spencer Dawkins at IETF wrote:
> This is me as an individual, asking a question, and NOT making an informed
> observation or suggestion ... but I was curious.

[snip]

> I note that TSVWG  currently has two FECFRAME docs in WGLC now:
> 
> (1) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/
> 
> (2) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/
> 
> The intent for these documents is to add support for sliding window FEC
> codes to the RFC 6363 FEC Framework, which was limited to block FEC codes.

I have to admit, I have never seen RFC 6363 or the FECFRAME drafts until
today.  With that said, I believe I understand on high level what they
are about after reading the abstracts.

> I don't know whether there is any relationship between your proposal
> (moving from framing to a stream for compression) and the work currently in
> TSVWG. I have some guesses, but not well-informed guesses, so thought I
> should ask.

There is no relationship to the QPACK framing in question.  The QPACK
framing mechanism used to write encoder instructions to the encoder
QUIC stream is there solely as an aid to the decoder -- evidently
with the aim of making the QPACK decoder easier to implement (or to
port existing HPACK decoders).

Google experimented with FEC in gQUIC but the bandwidth overhead
proved to outweigh any advantages offered by ability to reconstruct
lost packets and the effort was abandoned, IMMSMC, in 2015.

Using FEC in IETF QUIC is something that is interesting to think about.
For example, one could envision adding FEC to a critical stream, such
as the QPACK encoder stream above, to cope with packet loss.  The
challenges posed by such approach would be non-trivial and likely
require changes to the transport layer.

  - Dmitri.