RE: draft-lubashev-quic-partial-reliability
Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Tue, 19 December 2017 17:40 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 18E4112D7F5 for <quic@ietfa.amsl.com>; Tue, 19 Dec 2017 09:40:50 -0800 (PST)
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, UNPARSEABLE_RELAY=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 wXj9uZclmjNs for <quic@ietfa.amsl.com>; Tue, 19 Dec 2017 09:40:48 -0800 (PST)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 5F39E1241F5 for <quic@ietf.org>; Tue, 19 Dec 2017 09:40:48 -0800 (PST)
Received: by mail-io0-x234.google.com with SMTP id e204so14420349iof.12 for <quic@ietf.org>; Tue, 19 Dec 2017 09:40:48 -0800 (PST)
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=tB5Qsvm2dIP4heNA1xh9BUYETXmJiKerrpCCDpd8E/A=; b=CT5oJk6P/GtPpit8LbHWTSjNuLV7UhdGeskS6keXrPXCmoIOmuZRgbLbt4cNbpAV1B vQb1LpuDSW8jMnFmiTfvAQ7awtoDw0JchlapOT0bIdiK7znbI+YssGJwX9GifWKgLFZM Z+XE2Q2PQW/R0KIv90HB4+mPcUmIgFARFRD2rMRl+W0i6Odzw9tlt1XhcZlr1GeGiUeW 63gtBEpgxBKvTpYYa9OW2iKWIVyprFpKw7BIjtz4h2IeNQGlWmHqKuqwqsR8A17vmU2I z4/KiIS/A/Tyka2ZUftAEWTsIuujY8AvTN7c58n83uOzfe7Ixbj6TLBMEgn/TjXKZ5/F a2fA==
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=tB5Qsvm2dIP4heNA1xh9BUYETXmJiKerrpCCDpd8E/A=; b=l7L2SRHtd9C10Ha+ZwFsutipo26++f9RTbuDQcWRFPnHzq+b64CLRT27XMOC+outH/ 7fK2tynLWZfY1ZFXy0Z0d04E9y/U/PKuB0LER0hhSnJEODpUND90NlfLFSrEuxWGFYB/ NplC3E6qDJAgaOF4KBuOZtefYQRdrNp8Qr6F0zChHDZblD8yLOHdMpuYSo0SUb3M1U3F O6WTWJDhBH2S3L/ZWQTHjwqhsEySiNCokAgT7CUX2C9M8yj3A4P8oeptdOkedPK0DlUx kQ0gfUUSeVikCf3b+BmHmL8sxF+0T1PUkf6iaKhbRbW7mZhwC1pqZ2mUiYLn03yXyaCn ob8w==
X-Gm-Message-State: AKGB3mI0JjDqt/xJsdS2I3kjiIGnC4SxcgvNsc5EHrbb9q5q3YK+K/WF l4U6gjPE+qCiWCCu/l6REB8dHtNWS9dgSzjYsDw=
X-Google-Smtp-Source: ACJfBovCCsIETdwz8sNKXSabL34BsBDOY2sT3QO7/w1J5Kn1j8kLSqDB+gtbF54sXiOd9eREMZI8Kd6yWxojn+Q63oE=
X-Received: by 10.107.69.20 with SMTP id s20mr4895963ioa.239.1513705247637; Tue, 19 Dec 2017 09:40:47 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 19 Dec 2017 09:40:46 -0800
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BAB1B44@bgb01xud1012>
References: <c1f5a6d8d21f423a93003f7b69dae882@usma1ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BAB1A4A@bgb01xud1012> <85d7dc28d3bb40a38873f4d32a16fd71@usma1ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BAB1B01@bgb01xud1012> <CAN1APddU53Jzfy998NtOqVZC8ZdXYGEZf042VKw7yMGCixq-bg@mail.gmail.com> <7CF7F94CB496BF4FAB1676F375F9666A3BAB1B44@bgb01xud1012>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Tue, 19 Dec 2017 09:40:46 -0800
Message-ID: <CAN1APdfxjybVYpVizktyPfABBb+Y=Wmzxpo3PotrTEv=tTQ4eg@mail.gmail.com>
Subject: RE: draft-lubashev-quic-partial-reliability
To: Lucas Pardue <lucas.pardue@bbc.co.uk>, "Lubashev, Igor" <ilubashe@akamai.com>, "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="089e082866a89486880560b4f769"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/hjHtZL_A_vmTP41mOWm7-iqj7DY>
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 17:40:50 -0000
Another thought: The partial reliability problem is really like a reverse ACK problem. You can send a frame similar to ACK, be referring to you own streams rather than the peers packets. For any stream where the conceptual MIN_STREAM_DATA is 0, not transmission is made. Otherwise all unclosed streams have an entry in a frame carrying many streams at once. This might be delivered unreliable similar to ACK, since old reverse ACK are not that interesting. You loose some details about sent vs unsent, but peer can deduce that because a stream does not have gaps. (A stream could pretend to have lost some data by never sending it if it gets behind, it it is the same thing). This would use much less space achieving largely the same concept as with MIN_STREAM_DATA frames for one stream at time. Kind Regards, Mikkel Fahnøe Jørgensen On 19 December 2017 at 18.22.16, Lucas Pardue (lucas.pardue@bbc.co.uk) wrote: Mikkel wrote: > As to client vs server asymmetri: It strongly suggest not to make a distinction here because there are many symmetric peer to peer use cases and also opposite cases: server to client with partially reliable video, client to server with partially reliable game state, server to server with partially reliable gossip protocol to statistically advance a common state (e.g. "I have processed so many bytes now, how about you?”). Yes, early specialisation is a route to disappointment. There are other discussions around unnecessary asymmetry at this level. Regards Lucas ---------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ---------------------
- draft-lubashev-quic-partial-reliability Lubashev, Igor
- Re: draft-lubashev-quic-partial-reliability Phil Sorber
- RE: draft-lubashev-quic-partial-reliability Lucas Pardue
- RE: draft-lubashev-quic-partial-reliability Lubashev, Igor
- RE: draft-lubashev-quic-partial-reliability Lucas Pardue
- RE: draft-lubashev-quic-partial-reliability Mikkel Fahnøe Jørgensen
- RE: draft-lubashev-quic-partial-reliability Lucas Pardue
- RE: draft-lubashev-quic-partial-reliability Mikkel Fahnøe Jørgensen
- RE: draft-lubashev-quic-partial-reliability Lubashev, Igor
- Re: draft-lubashev-quic-partial-reliability Roberto Peon
- RE: draft-lubashev-quic-partial-reliability Mikkel Fahnøe Jørgensen
- Re: draft-lubashev-quic-partial-reliability Christian Huitema
- Re: draft-lubashev-quic-partial-reliability Mikkel Fahnøe Jørgensen
- Re: draft-lubashev-quic-partial-reliability Ian Swett
- RE: draft-lubashev-quic-partial-reliability Ingemar Johansson S
- Re: draft-lubashev-quic-partial-reliability Ian Swett
- Re: draft-lubashev-quic-partial-reliability Roberto Peon
- RE: draft-lubashev-quic-partial-reliability Lubashev, Igor
- Re: draft-lubashev-quic-partial-reliability Colin Perkins
- Re: draft-lubashev-quic-partial-reliability Christian Huitema
- RE: draft-lubashev-quic-partial-reliability Lubashev, Igor
- RE: draft-lubashev-quic-partial-reliability Lubashev, Igor
- RE: draft-lubashev-quic-partial-reliability Lubashev, Igor
- Re: draft-lubashev-quic-partial-reliability Eggert, Lars