IETF Logo Mail Archive

RE: Idea for packet numbers

"MORTON, ALFRED C (AL)" <acmorton@att.com> Tue, 25 July 2017 14:34 UTC

Return-Path: <acmorton@att.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 29FE1131CDC for <quic@ietfa.amsl.com>; Tue, 25 Jul 2017 07:34:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 3jqE9CKADLcd for <quic@ietfa.amsl.com>; Tue, 25 Jul 2017 07:34:23 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A667E131CD4 for <quic@ietf.org>; Tue, 25 Jul 2017 07:34:23 -0700 (PDT)
Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v6PEPq8f047362; Tue, 25 Jul 2017 10:34:17 -0400
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049297.ppops.net-00191d01. with ESMTP id 2bx7959553-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Jul 2017 10:34:17 -0400
Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id v6PEYGTN011977; Tue, 25 Jul 2017 09:34:16 -0500
Received: from dalint02.pst.cso.att.com (dalint02.pst.cso.att.com [135.31.133.160]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id v6PEY7Ke011882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Jul 2017 09:34:08 -0500
Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by dalint02.pst.cso.att.com (RSA Interceptor); Tue, 25 Jul 2017 14:33:54 GMT
Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v6PEXsqM011731; Tue, 25 Jul 2017 09:33:54 -0500
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v6PEXhcD010847; Tue, 25 Jul 2017 09:33:43 -0500
Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-blue.research.att.com (Postfix) with ESMTP id DDDA6F05B9; Tue, 25 Jul 2017 10:33:42 -0400 (EDT)
Received: from njmtexg4.research.att.com ([fe80::8cd:baa3:219e:5bd4]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0361.001; Tue, 25 Jul 2017 10:33:42 -0400
From: "MORTON, ALFRED C (AL)" <acmorton@att.com>
To: Ian Swett <ianswett@google.com>, "Swindells, Thomas (Nokia - GB/Cambridge, UK)" <thomas.swindells@nokia.com>
CC: Magnus Westerlund <magnus.westerlund@ericsson.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, IETF QUIC WG <quic@ietf.org>, Dmitri Tikhonov <dtikhonov@litespeedtech.com>
Subject: RE: Idea for packet numbers
Thread-Topic: Idea for packet numbers
Thread-Index: AQHTAT74Pm6HB4E+oUyHojrh9ct+26JcjwOAgAF4cgCAA8bLAIAC9FKA///aNiA=
Date: Tue, 25 Jul 2017 14:33:42 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CF46BC67BC@njmtexg4.research.att.com>
References: <c7941a67-6eaa-cd58-d0e2-a764478aa5b0@ericsson.com> <CAN1APdfwCoEieon8H98TOXBmsiwoHQfpsknfMB4hteU5gi9sMg@mail.gmail.com> <20170721093732.GA31705@ubuntu-dmitri> <DB5PR07MB1237B7C130AE23585EFF4CB084B80@DB5PR07MB1237.eurprd07.prod.outlook.com> <CAKcm_gNNPC9eUMoBynXuz0p_YZHRsbK6ToaqoT7+u5NGAwf9sw@mail.gmail.com>
In-Reply-To: <CAKcm_gNNPC9eUMoBynXuz0p_YZHRsbK6ToaqoT7+u5NGAwf9sw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.16.251.241]
Content-Type: multipart/alternative; boundary="_000_4D7F4AD313D3FC43A053B309F97543CF46BC67BCnjmtexg4researc_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-25_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707250229
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/_HKqLd335qIo6H1g5xWVE6VMYmI>
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, 25 Jul 2017 14:34:26 -0000

Hi Ian, Thomas,

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ian Swett
Sent: Tuesday, July 25, 2017 8:25 AM
To: Swindells, Thomas (Nokia - GB/Cambridge, UK)
Cc: Magnus Westerlund; Mikkel Fahnøe Jørgensen; IETF QUIC WG; Dmitri Tikhonov
Subject: Re: Idea for packet numbers

Some thoughts.

1) Sending packet numbers in order is not required, but the farther out of order packets get, the more acks the receiver is going to send, the larger they'll be, and the more complex loss detection is.  In particular, you won't be able to rely on QUIC's packet numbers being in time order.  TLDR; It's easier to send packets in order than it is to correctly deal with the implications of sending them out of order.
<snip>
[ACM]
Although this thread is on longer packet numbers,
I think it’s worth pointing out that
routine reordering at the Sender would have
implications for the single-bit alternate marking
(Spin-bit) approach. The boundary between
packets marked “0” and “1” would not be reliable;
there would appear to be very short RTTs along with longer RTTs:

  ... 0 0 0 1 1 0 1 1 1 1 1 ...
            ^ ^
   ^ = reordered
The single bit doesn’t have enough info to
restore order. Avoid reordering if possible.

Al

v2.23.0 | Report a Bug | By Email