IETF Logo Mail Archive

Re: draft-lubashev-quic-partial-reliability

Phil Sorber <sorber@apache.org> Tue, 19 December 2017 03:56 UTC

Return-Path: <sorber@apache.org>
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 F1C67127275 for <quic@ietfa.amsl.com>; Mon, 18 Dec 2017 19:56:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.929
X-Spam-Level:
X-Spam-Status: No, score=-6.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 SDhd1cLM7ZDM for <quic@ietfa.amsl.com>; Mon, 18 Dec 2017 19:56:09 -0800 (PST)
Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id 23E78124E15 for <quic@ietf.org>; Mon, 18 Dec 2017 19:56:09 -0800 (PST)
Received: (qmail 83043 invoked by uid 99); 19 Dec 2017 03:56:08 -0000
Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Dec 2017 03:56:08 +0000
Received: from mail-it0-f41.google.com (mail-it0-f41.google.com [209.85.214.41]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 76F991A010E for <quic@ietf.org>; Tue, 19 Dec 2017 03:56:05 +0000 (UTC)
Received: by mail-it0-f41.google.com with SMTP id o130so7140423itg.0 for <quic@ietf.org>; Mon, 18 Dec 2017 19:56:05 -0800 (PST)
X-Gm-Message-State: AKGB3mKG58+kWX3ACCI++0X4bAX9c0Mhb4D7eGfJOWwoPWiW9LmafUzT /xfQhCbypmAbqpGbUlmSbgPnzmqKxcU7RpkV5w0=
X-Google-Smtp-Source: ACJfBosjfLaKpZCh6d4g0+zdsGiA1cwI6XD80AC7hehJdIh3cO1r/aJKIUGeqCj5T1kMtDdeeC3Y0pvpTZvC5w0NFD0=
X-Received: by 10.36.67.199 with SMTP id s190mr1676177itb.153.1513655763400; Mon, 18 Dec 2017 19:56:03 -0800 (PST)
MIME-Version: 1.0
References: <c1f5a6d8d21f423a93003f7b69dae882@usma1ex-dag1mb5.msg.corp.akamai.com>
In-Reply-To: <c1f5a6d8d21f423a93003f7b69dae882@usma1ex-dag1mb5.msg.corp.akamai.com>
From: Phil Sorber <sorber@apache.org>
Date: Tue, 19 Dec 2017 03:55:52 +0000
X-Gmail-Original-Message-ID: <CABF6JR2dy11R9Lz+f-ky7oWjy5JeMUf4OpkGjsDtPxEkME_qww@mail.gmail.com>
Message-ID: <CABF6JR2dy11R9Lz+f-ky7oWjy5JeMUf4OpkGjsDtPxEkME_qww@mail.gmail.com>
Subject: Re: draft-lubashev-quic-partial-reliability
To: "Lubashev, Igor" <ilubashe@akamai.com>
Cc: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a113faebc16fde40560a9720a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/f1fm9rW2-Qcmb9F6ygcdW9xL0Rc>
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 Dec 2017 03:56:11 -0000

This is interesting and addresses some things that I have had some
conversations with others about as well. I'll try to read and give feedback
in the next couple of weeks.

Thanks.

On Mon, Dec 18, 2017 at 8:40 PM Lubashev, Igor <ilubashe@akamai.com> wrote:

> I’ve just posted a draft on adding partial reliability to QUIC streams.
>
>
>
> Datatracker link:
> https://tools.ietf.org/html/draft-lubashev-quic-partial-reliability
>
> Github link:
> https://github.com/igorlord/draft-lubashev-quic-partial-reliability
>
>
>
> This draft introduces a generic way to add partial reliability to QUIC
> streams using a single new frame: MIN_STREAM_FRAME (and keeping one new
> per-stream variable: Min Stream Offset).
>
>
>
> The high-level idea is that the sender keeps track of messages within a
> stream and can “expire” old messages whenever it wants.  The “expiration”
> is a signal to the transport to not retransmit expired data (and a signal
> to the other endpoint that this data will not be retransmitted).  All
> details are in the draft.
>
>
>
> I am very interested in feedback on this proposal.
>
>
>
>    - Igor
>
>

v2.23.0 | Report a Bug | By Email