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, 07 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. >
- Re: Proposal: drop QPACK encoder stream framing Ian Swett
- Re: Proposal: drop QPACK encoder stream framing Roberto Peon
- Re: Proposal: drop QPACK encoder stream framing Roberto Peon
- Proposal: drop QPACK encoder stream framing Dmitri Tikhonov
- Re: Proposal: drop QPACK encoder stream framing Spencer Dawkins at IETF
- Re: Proposal: drop QPACK encoder stream framing Spencer Dawkins at IETF
- Re: Proposal: drop QPACK encoder stream framing Dmitri Tikhonov
- Re: Proposal: drop QPACK encoder stream framing Kazuho Oku
- Re: Proposal: drop QPACK encoder stream framing Martin Thomson
- Re: Proposal: drop QPACK encoder stream framing Ian Swett
- Re: Proposal: drop QPACK encoder stream framing Alan Frindell
- Re: Proposal: drop QPACK encoder stream framing Kazuho Oku
- Re: Proposal: drop QPACK encoder stream framing Alan Frindell
- Re: Proposal: drop QPACK encoder stream framing Kazuho Oku
- Re: Proposal: drop QPACK encoder stream framing Dmitri Tikhonov
- RE: Proposal: drop QPACK encoder stream framing Mike Bishop
- Re: Proposal: drop QPACK encoder stream framing Alan Frindell
- Re: Proposal: drop QPACK encoder stream framing Dmitri Tikhonov
- Re: Proposal: drop QPACK encoder stream framing Dmitri Tikhonov