Re: Spin bit - semantics - rtt and loss
<alexandre.ferrieux@orange.com> Fri, 23 March 2018 06:55 UTC
Return-Path: <alexandre.ferrieux@orange.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 C7D331289B0 for <quic@ietfa.amsl.com>; Thu, 22 Mar 2018 23:55:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.301
X-Spam-Level:
X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 7QsK706hdfyI for <quic@ietfa.amsl.com>; Thu, 22 Mar 2018 23:55:10 -0700 (PDT)
Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5AF5124239 for <quic@ietf.org>; Thu, 22 Mar 2018 23:55:09 -0700 (PDT)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 88AF0409B9; Fri, 23 Mar 2018 07:55:08 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 6F8AD1A0068; Fri, 23 Mar 2018 07:55:08 +0100 (CET)
Received: from lat6466.rd.francetelecom.fr (10.168.234.2) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 23 Mar 2018 07:55:08 +0100
Message-ID: <8654_1521788108_5AB4A4CC_8654_341_3_5AB4A4CC.6070306@orange.com>
Date: Fri, 23 Mar 2018 07:55:08 +0100
From: alexandre.ferrieux@orange.com
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111113 Thunderbird/8.0
MIME-Version: 1.0
To: "Lubashev, Igor" <ilubashe=40akamai.com@dmarc.ietf.org>
CC: "quic@ietf.org" <quic@ietf.org>
Subject: Re: Spin bit - semantics - rtt and loss
References: <9168a7b6700d49d6b7454f8c91eebce2@ustx2ex-dag1mb5.msg.corp.akamai.com>
In-Reply-To: <9168a7b6700d49d6b7454f8c91eebce2@ustx2ex-dag1mb5.msg.corp.akamai.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.168.234.2]
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/fDTdkd1U6DzOp62Bpwq7cvLdp1E>
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: Fri, 23 Mar 2018 06:55:12 -0000
Hi Igor, Indeed packet loss is important to track. Your proposal is an instance of the "square sequence" proposed earlier by Kazuho. He suggested a much longer period (hundreds); you're exploring lower values. Each range has issues: too long turns into a large temporal imprecision for sparse flows (like ACKs); too short blurs the signal in case of tail drops (many contiguous losses). Also, these methods only give upstream losses (between the sender and the midpoint). For this reason we propose a more ambitious 7-bit solution here: Spin Counters http://snaggletooth.akam.ai/IETF-101-HotRFC/10-Ferrieux.pdf Would that help ? On 23/03/2018 01:12, Lubashev, Igor wrote: > Since we decided to put some work into spin bit, albeit in a separate document > from V1, here are some thoughts. > > It is nice that spin bit can be used to estimate rtt. I am sure that it is > useful to many well-meaning people. It is not very useful to me, though. > > When I debug network problems, they are much more likely to be about lost > packets. And I like to be able to know packet loss frequency and pattern very > accurately. (I am assuming an encrypted packet number, or the problem would be > trivial.) > > I would prefer, if we have a spin bit, for it to spin not every rtt but every, > say, 10 packets that an endpoint sends. Client sends 10 packets with 0 and then > 10 packets with 1, repeat. Sever does the same. > > So maybe two spin bits -- one for rtt and one for loss? I would assume that loss > bit would assist in rtt estimation in case of loss. > > Thoughts? > > - Igor _________________________________________________________________________________________________________________________ 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.
- Spin bit - semantics - rtt and loss Lubashev, Igor
- Re: Spin bit - semantics - rtt and loss alexandre.ferrieux
- RE: Spin bit - semantics - rtt and loss Lubashev, Igor
- Re: Spin bit - semantics - rtt and loss Mikkel Fahnøe Jørgensen
- Re: Spin bit - semantics - rtt and loss Mikkel Fahnøe Jørgensen
- Re: Spin bit - semantics - rtt and loss alexandre.ferrieux
- Re: Spin bit - semantics - rtt and loss alexandre.ferrieux
- R: Spin bit - semantics - rtt and loss Fioccola Giuseppe
- Re: Spin bit - semantics - rtt and loss Eggert, Lars
- R: Spin bit - semantics - rtt and loss Fioccola Giuseppe
- Re: Spin bit - semantics - rtt and loss Eggert, Lars
- R: Spin bit - semantics - rtt and loss Fioccola Giuseppe