Re: The first octet

Ian Swett <ianswett@google.com> Wed, 08 August 2018 13:57 UTC

Return-Path: <ianswett@google.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 76375130DC0 for <quic@ietfa.amsl.com>; Wed, 8 Aug 2018 06:57:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.51
X-Spam-Level:
X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 1wX5tPv_OEpI for <quic@ietfa.amsl.com>; Wed, 8 Aug 2018 06:57:23 -0700 (PDT)
Received: from mail-yw1-xc31.google.com (mail-yw1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (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 6B3DF12F1A6 for <quic@ietf.org>; Wed, 8 Aug 2018 06:57:23 -0700 (PDT)
Received: by mail-yw1-xc31.google.com with SMTP id z143-v6so1575175ywa.7 for <quic@ietf.org>; Wed, 08 Aug 2018 06:57:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AMbmLfoGp3DocVksAWoIVW+y6M5RxMP3p/4ihr+hn64=; b=ogzIXL0V5lEk+h/yiEm2Ha/AC7KOb1/E40qSwJCnMJ7QIq+5apOLiYDFZiHew/dKHm h7ZK1PN4o5tOyylg8cPNnD06dZqtt3PNd66tN3wtaUP30bJhydpLFnW8cFWIoYtt6Ayr lEkzNBOLase1fGKzY5vN1A/m2Xz4FKFjqusXuy9sPwMN6JUisnY2tCZURjiz9IKBo6We ueu2WWga8jpojsAsFG4K0gWEI+Qfi8lcaQzBwcJ4nvmHEXhjxlcVzBnEts9AK7Jz+l1t 211zXJrPVCNqiPoDNuZFD1T+OPvKyq7N++6qFkIOQ5Tg/Vgo19HuhJi5iU2uLnUUDSV9 4weg==
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:cc; bh=AMbmLfoGp3DocVksAWoIVW+y6M5RxMP3p/4ihr+hn64=; b=F/LDhq5MpVU/YPz4lzZDPwKvrlYVbrbzW/nFsdKCzRJmlGTPNJF2zGGlnaGoo0iFVy Zveqq2utoN1Pa7LFa1d1NKZbiHV6aAxWwRpkF0j0apb3dOjdsoD5y6D6CYV2dtRox7I+ 1scfpQq4W8/Q3EvtjdoCmrnsb6MSuv32aqDeb63lEYpq4NuZGftdBrh8WJ44qghBZxfB uW6hs6pHm/Z/GncDk81qlfHXEYPIESydXGsrAL2GGiWeuzzxipqbLf8M3M0QxN3IBWUK fLyhBcwEUJwqRw/NX2z9ivwwHM4iAQaHrAfKRY5PlC6NJ8tjHXrykqIY8OxOsvQ7htdk tS9A==
X-Gm-Message-State: AOUpUlFSWP8yj69pbeAhEGrcSpQGBvojUamk0QLPXrJarEPNEwIXXe+q hxacolvxt49hz/m9gtnidLW+CC4i/EwLfplBo98XHjeSeeA=
X-Google-Smtp-Source: AA+uWPzFzR/sN1pvo0u7LNCLUWqnjZM1HAlHpNL3H+ITLjBVye5SwTEEY2Sd0fqAKZq2pwEK4qGYq5Lnn6dEem0ALio=
X-Received: by 2002:a81:5a42:: with SMTP id o63-v6mr1544995ywb.148.1533736642161; Wed, 08 Aug 2018 06:57:22 -0700 (PDT)
MIME-Version: 1.0
References: <CABkgnnVFYMjWDk6zEEA8T_6qg+6qO9yAwVF70foMj4bXEdBaqQ@mail.gmail.com> <CANatvzwRcaE48mXpjTbeUtA4QLG-iJtXnDqjP5BjBm-RMPWodQ@mail.gmail.com> <CABkgnnUegjp1r6iRMRRqYretRFZBjHHdkiCxaLi56ywpkogufA@mail.gmail.com> <13948_1533714633_5B6AA0C9_13948_54_1_7bcd9ecb-c425-ecba-3caf-7bf004beb7d9@orange.com> <CABkgnnV3KPoAR3s_Qq6hVHK7yuQb4cNBrOCNYvtjjbxXw_-5Zg@mail.gmail.com> <26969_1533734553_5B6AEE99_26969_131_1_373ed656-1dba-9b82-5c8b-eb2b7a5c9ad0@orange.com> <CAKcm_gPJBpjJbiRa4GTs_RDQcwJBCgza+eX+BMdJKC4Dffmd9g@mail.gmail.com> <24749_1533735863_5B6AF3B7_24749_220_1_604c6e2a-2ded-ed00-3089-3e4db36996a6@orange.com> <6E58094ECC8D8344914996DAD28F1CCD8BB1FD@DGGEMM506-MBX.china.huawei.com>
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD8BB1FD@DGGEMM506-MBX.china.huawei.com>
From: Ian Swett <ianswett@google.com>
Date: Wed, 8 Aug 2018 09:56:52 -0400
Message-ID: <CAKcm_gP99yXctFRe7mZwabOeBN-KkknVRu3_4xewK4T4MXzZ-w@mail.gmail.com>
Subject: Re: The first octet
To: Roni Even <roni.even@huawei.com>
Cc: alexandre.ferrieux@orange.com, IETF QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>, Kazuho Oku <kazuhooku@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000bd03c00572ece31a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/k_atdmv_liVNNLoYq82uzpheOe4>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.27
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: Wed, 08 Aug 2018 13:57:26 -0000

Thanks Roni, agreed, let's focus on the issues Martin raised.

On Wed, Aug 8, 2018 at 9:55 AM Roni Even (A) <roni.even@huawei.com> wrote:

> Hi,
> In London the spin bit and VEC were not discussed in the session, my take
> from the offline discussions we had was that currently we experimented with
> good results only the spin bit. It also seemed that the current VEC as
> proposed in Brians's draft is not good enough and we intend to look at
> other algorithms that will provide better results for packet loss using the
> 2 bits.
> I think that this discussion is pre mature and that it should be discussed
> in the future
> Roni
>
> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of
> alexandre.ferrieux@orange.com
> Sent: Wednesday, August 08, 2018 4:44 PM
> To: Ian Swett
> Cc: IETF QUIC WG; Martin Thomson; Kazuho Oku
> Subject: Re: The first octet
>
> Sure:
>
>   - spin+VEC are documented in draft-trammel-spin-03
>
>   - 7 bits for packet loss were presented at
>       http://snaggletooth.akam.ai/IETF-101-HotRFC/10-Ferrieux.pdf
>
> Re "I'm curious why you'd even want them": please clarify which applies:
>
>   (a) you recognize the criticality of loss location, but you have a
> cleverer algorithm to do the same with fewer than 7 bits
>
>   (b) you don't believe network operators need to locate losses
>
>
> On 08/08/18 15:29, Ian Swett wrote:
> > I'm having a hard time understanding why you'd need 7 bits to measure
> > packet
> > loss(1 seems sufficient in most cases), can you send a link to the
> > spin + VEC and 7 bit proposals you mentioned?
> >
> > I'll also note I think the chances the WG will agree to 7 bits is
> > extremely close to 0, but I'm curious why you'd even want them.
> >
> > On Wed, Aug 8, 2018 at 9:22 AM <alexandre.ferrieux@orange.com
> > <mailto:alexandre.ferrieux@orange.com>> wrote:
> >
> >     On 08/08/18 12:05, Martin Thomson wrote:
> >      >
> >      > I know you discussed taking more bits and even bytes, but the case
> >      > hasn't been made in this working group to my knowledge.  I
> certainly
> >      > don't think that's justified; it improved fidelity of
> measurements,
> >      > but the spin bit appears to be pretty good at that without the
> extra
> >      > overheads.
> >
> >     Fidelity is indeed the criterion to decide 1 (spin bit) vs 3 (spin
> bit + VEC)
> >     for RTT measurements, right.
> >
> >     However, measurements also include packet loss, which is typically
> more
> >     widespread than delay in big pipes (which don't have enough RAM to
> keep a
> >     packet
> >     for too long at line rate). And spin+VEC do not address packet loss
> at all,
> >     hence our 7-bit spin counter proposal shown in London.
> >
> >     I admit that 7 is hefty if you're starting from Christian's songle
> spin bit ;
> >     however:
> >
> >        - I assume nobody will emit any doubt about the criticality of
> >     non-delay-related (big pipe) loss location. Unless everybody here
> has perfect
> >     networks and ideal reporting, that is.
> >
> >        - Stick the spin bit on top of these 7, make that an extra
> easurement
> >     byte and
> >     you've got your three spare bits again in the first byte.
> >
> >
> >
> > ______________________________________________________________________
> > ___________________________________________________
> >
> >     Ce message et ses pieces jointes peuvent contenir des informations
> >     confidentielles ou privilegiees et ne doivent donc
> >     pas etre diffuses, exploites ou copies sans autorisation. Si vous
> avez recu
> >     ce message par erreur, veuillez le signaler
> >     a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages
> >     electroniques etant susceptibles d'alteration,
> >     Orange decline toute responsabilite si ce message a ete altere,
> deforme ou
> >     falsifie. Merci.
> >
> >     This message and its attachments may contain confidential or
> privileged
> >     information that may be protected by law;
> >     they should not be distributed, used or copied without authorisation.
> >     If you have received this email in error, please notify the sender
> and
> >     delete this message and its attachments.
> >     As emails may be altered, Orange is not liable for messages that
> have been
> >     modified, changed or falsified.
> >     Thank you.
> >
>
>
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message par
> erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>