Re: [tsvwg] [ippm] Why measure RTT passively?
Tom Herbert <tom@herbertland.com> Wed, 19 September 2018 21:17 UTC
Return-Path: <tom@herbertland.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 AE435130EA1 for <quic@ietfa.amsl.com>; Wed, 19 Sep 2018 14:17:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 MffVYrEn-zwN for <quic@ietfa.amsl.com>; Wed, 19 Sep 2018 14:17:54 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 6E85F131047 for <quic@ietf.org>; Wed, 19 Sep 2018 14:17:51 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id d131-v6so3831480qke.11 for <quic@ietf.org>; Wed, 19 Sep 2018 14:17:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=bvdjiY0RQUqbg7SoK22ho5xYq3EcyVOS3qnAO4Kdc8I=; b=he/0nBdyn3+GvQ2w4WEiqV2emkmXvEsPLzdjVphpRQgbU3kvI+yESk0VCgIIcAJlsq Ns6APSF3ezygY5teq0ZuGoyI7pO2AR3Kb119zOmUKjfhysm6idUand6GU4CSrZFkg54I VP7ZeXlqb2n2LR5l9KMjJ/9p72aWnVh2qQQ2VISvWKvrFM+aXWQHiQ6Zdf4q86oUAKic 5HGzepPXLkNQGrLZIbpkjgkfJDDQQR1qJd+4ofG+hh2xodM97iSMD75fZLi/HkqEUHXS zWr5w9r2lcwpDhz2qnKkWstjnin1ZDMqdHFmICixSD2Ny0MRJtrl7gNa2PO8jpzvJNOv KvIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bvdjiY0RQUqbg7SoK22ho5xYq3EcyVOS3qnAO4Kdc8I=; b=FJyJp4feZ3rxhVhYAwy/pWlKqo3Q0uRV1bJDzZk085VPlXgG9dYc7rnEqfPC+M7q35 e4NJEh0vUL1xX3aD2E8sjOMYdbt2/BRGnvnIlsjXqbgcPk1Q9jF5iHLthP+9YZ2/Ir8R DMXCL2Xa0vAkyAaSqTS3DACEDC7uzH8v/b6n3UseHNviGJDPwhidYUy6Z3pTyN0cDn4j v+NgQhukzh+hHZf7WzeSX05W0LUajH5SIUgt/q7sJ5aaYW8Hhh/mHUtx2TOV0sBT7Sd8 Go3501NkpKUPgMPylsZ3OXiUeyIF04LZa6g0X3G/d0kksGKQ+mw4VXlfoq+YXFm4eeb7 TMew==
X-Gm-Message-State: APzg51ASWvDwKtnpRS+TwQUOVkjXtYbKIwN7F+ACmm2cjgLlIUQh5WP1 LPAi6STq4Av5Hcl05SoCHO3+UHBhk1Ml+yKzJUTi9g==
X-Google-Smtp-Source: ANB0Vda9UrgT1m2I8122lfDdLWbvK4O2EZgVHb8q5+qYPQVT1mBzPOenU3+9dciUk2QIdHIifVCvQOZVK8jDGk+vGKU=
X-Received: by 2002:a37:a357:: with SMTP id m84-v6mr25317990qke.121.1537391870404; Wed, 19 Sep 2018 14:17:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:2a94:0:0:0:0:0 with HTTP; Wed, 19 Sep 2018 14:17:49 -0700 (PDT)
In-Reply-To: <5b05303b-317c-2405-9299-5aabeebe501d@gmail.com>
References: <D8EC0860-BA95-48D9-BE42-933426B60417@trammell.ch> <CALx6S34qm5j+UntuuT=pvMc-C_yOasL5s1DHD7CY4uFHR8zRyQ@mail.gmail.com> <CAKKJt-fqOmoBSqrhHhWg07kV3CqUfpTT1QOeuUhtJpPV7hZNYw@mail.gmail.com> <BD9E270A-0CDD-4F8D-9628-EC3D5359D1AE@huitema.net> <4cc8764d-736b-5f54-0769-d26b98a8e2a3@erg.abdn.ac.uk> <5b05303b-317c-2405-9299-5aabeebe501d@gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 19 Sep 2018 14:17:49 -0700
Message-ID: <CALx6S34QTweA9QYHygoiB4gWcNKLKgRQnijx+Jn0iq7j3UWAZA@mail.gmail.com>
Subject: Re: [tsvwg] [ippm] Why measure RTT passively?
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Christian Huitema <huitema@huitema.net>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, IETF QUIC WG <quic@ietf.org>, tsvwg <tsvwg@ietf.org>, IETF IPPM WG <ippm@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/jV9jhbBy98fDc07x07P2rps5cUA>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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, 19 Sep 2018 21:17:58 -0000
On Wed, Sep 19, 2018 at 1:49 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: > On 2018-09-20 01:56, Gorry Fairhurst wrote: >> On 19/09/2018 13:24, Christian Huitema wrote: >>> >>>> On Sep 18, 2018, at 7:59 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote: >>>> >>>> Forget that I'm an AD, because I'm not wearing any hats, but I'm having a really difficult time explaining to other people internally how a spin bit that's not in the IP header, but is part of a mostly-encrypted transport header, is better than putting something in an IP (extension? iOAM?) header that would be transport-independent. >>> The one advantage of the bit in transport header is that it is authenticated end to end. The other advantage is that it is automatically tied to a transport flow and its five tuple. Then there is the reality that IP header bits are commonly rewritten by a variety of middleboxes. >>> >>> The downside is that different encrypted transports will most likely end up adopting different encodings and conventions. >>> >>> But of course we could also repurpose one of the TOS bits >> Do you mean the DSCP field? - That would sound like a very odd proposal. > > To be clear, there are no free bits in the DSCP field, there are only > free codepoints in the 6-bit space. And of course since DSCP values > explicitly act as a QoS request, they also implicitly change the > one-way latency and therefore the RTT. So the DSCP bits would be > remarkably bad as a tool for RTT measurement. > > Brian C > >>> or one of the flow header bits for the purpose, to mirror the transport level bit. Mirror instead of replace: that would alleviate the need of parsing transport headers, but still allow end to end detection of IP header rewriting. Neither are there any flow label bits available. Re-purposing even a single bit would adversely effect deployed use cases where flow label is being used for packet steering or other purposes. Using the flow label for packet marking was discussed in https://tools.ietf.org/html/draft-fioccola-spring-flow-label-alt-mark-01 Tom >>> >>> -- Christian Huitema >> >> Gorry >> >> . >> >
- Why measure RTT passively? Brian Trammell (IETF)
- Re: [tsvwg] Why measure RTT passively? Tom Herbert
- Re: [ippm] [tsvwg] Why measure RTT passively? Spencer Dawkins at IETF
- Re: [tsvwg] Why measure RTT passively? Michael Tuexen
- Re: [ippm] [tsvwg] Why measure RTT passively? Christian Huitema
- Re: [tsvwg] Why measure RTT passively? Brian Trammell (IETF)
- Re: [tsvwg] [ippm] Why measure RTT passively? Gorry Fairhurst
- Re: [tsvwg] Why measure RTT passively? Willy Tarreau
- Re: [tsvwg] Why measure RTT passively? Brian Trammell (IETF)
- Re: [tsvwg] Why measure RTT passively? Willy Tarreau
- Re: [tsvwg] Why measure RTT passively? Tom Herbert
- Re: [tsvwg] Why measure RTT passively? Mikkel Fahnøe Jørgensen
- Re: [tsvwg] Why measure RTT passively? Tom Herbert
- Re: [ippm] [tsvwg] Why measure RTT passively? Tom Herbert
- Re: [tsvwg] [ippm] Why measure RTT passively? Brian E Carpenter
- Re: [tsvwg] [ippm] Why measure RTT passively? Tom Herbert
- Re: [tsvwg] [ippm] Why measure RTT passively? Mikkel Fahnøe Jørgensen
- Re: [tsvwg] [ippm] Why measure RTT passively? alexandre.ferrieux
- Re: [tsvwg] [ippm] Why measure RTT passively? Christian Huitema
- Re: [tsvwg] [ippm] Why measure RTT passively? alexandre.ferrieux
- Re: [tsvwg] [ippm] Why measure RTT passively? Brian E Carpenter