Re: Proposal: drop QPACK encoder stream framing

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 07 June 2018 20:08 UTC

Return-Path: <spencerdawkins.ietf@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 DCC30127AC2 for <quic@ietfa.amsl.com>; Thu, 7 Jun 2018 13:08:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, 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 48C6Z4IgRigH for <quic@ietfa.amsl.com>; Thu, 7 Jun 2018 13:08:22 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 DC288127332 for <quic@ietf.org>; Thu, 7 Jun 2018 13:08:21 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id s201-v6so3411781ywg.8 for <quic@ietf.org>; Thu, 07 Jun 2018 13:08:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=WbdpEj7saB6JmWB7b+2VLRKDZEISOWz+sbRwBEFtvKg=; b=c9HYGRODS7D3IXIsp+qB/I0kwP3KDL+9jz51tyXv1gqMfbrxjWhnTIxPxrviDH5sNc y75fnwGVKULfouDJFh7mOr95cWKQn1vrJCFJwhbE/SJeUTwionNpkY46QMIuXpgjq9Jw J70Sd2ZWpjHsBRKNjcH+pRwbvvDRbuiBB4gnNXwjDZ9slAp8IWdaTGHAIxC+tHxHJM8w wdNXbCV9Zp09U90/e7UW4evI/6LXNo7cGc9P216EJfFGcCGlN9N3jBV5OQ2XjJQTnZIU nilqVqGUimQuKBTsdR/jHWkyT5HOJaQQlWlA4qxiBmcmjTh2ObnlIPoq+9CUTZYIWa3n wSOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=WbdpEj7saB6JmWB7b+2VLRKDZEISOWz+sbRwBEFtvKg=; b=pLyUKzNaxbYdSUhEQMhH6g0v1TsCySRCQntY4gutM5QLzCm0Vz6zATe4MD34cum8Ua uUZ8l6GzdAOhSGdyYdEDhvtDFYOLXzebFGWZ/2eSqhqPyz52wP4pQn5XCso+y7rc1E4n 5Imnh/s72xXEQLDGRXA7JCnyVsfy8Lekt1vTzUdeH33DimptFdZwiBD+gRI1KrhaZUdd 4wgOT3dum4bHuB7O+y1Fm7gIYwCYWxLIh6cGUbJJnKfcB3azaGcS7+wzAGUayy5+F2Q8 tegorTl9DxUfTLwfWMsD7b88pAuY/yzPsY81oFB+7OowDzX78/QGGw7f6XukdN63M5vI 5loA==
X-Gm-Message-State: APt69E3pChOsDI/EbBXaimjt0P5cdA9Hofu9rcK51Bt5srRZM2NG+dSF oxoEcluW9YipYsrdxy3JjRoyROD0PRnYZ1bwQ7PtAA==
X-Google-Smtp-Source: ADUXVKKrkjSnj/BQ6hzIMArKv+rvXLcT96LcEmamknwZjq41vPzcJCkUa+BiA1PV5YXxjxzJReO0TLJyRzoHLwgh964=
X-Received: by 2002:a0d:c745:: with SMTP id j66-v6mr1947642ywd.27.1528402100548; Thu, 07 Jun 2018 13:08:20 -0700 (PDT)
MIME-Version: 1.0
References: <20180607151112.GA28823@ubuntu-dmitri> <CAKKJt-cCqFUdVUGtGe1oJWzyFVnm7bTneprQ4ShssfVj0cEtKw@mail.gmail.com> <20180607190226.GA4187@ubuntu-dmitri>
In-Reply-To: <20180607190226.GA4187@ubuntu-dmitri>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Thu, 7 Jun 2018 15:08:08 -0500
Message-ID: <CAKKJt-eHMdUgT0G7=fFy=uNrrGHbQW3iu11P-Z2T4JnVoPAOvg@mail.gmail.com>
Subject: Re: Proposal: drop QPACK encoder stream framing
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000046fa26056e12d81f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/6pELkZpFQUw62C7QlGj5omypulY>
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 20:08:27 -0000

Hi, Dmitri,

On Thu, Jun 7, 2018 at 2:02 PM Dmitri Tikhonov <dtikhonov@litespeedtech.com>
wrote:

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

Thanks for this. It's helpful.

Spencer

  - Dmitri.
>