Subject: [ippm] Fwd: New Version Notification for draft-trammell-ippm-spin-00.txt

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 9 Jan 2019 12:36:33 +0100

Greetings, and happy new year IPPM!

As an individual, no hats:

Following up on some of the discussion we've had on the spin bit as a signal (as opposed to as a protocol feature of QUIC) on the IPPM list, I've submitted a draft describing the Spin Bit and the supplemental Valid Edge Counter signal in a transport-independent way, showing how it has been added to QUIC and a (possibly controversial, but definitely implementable and deployable) way to add it to TCP. 

I'd like to ask the WG's opinion on whether it would like to pursue work on the measurement of spin signals (including, e.g., heuristics for recovering RTT samples from spin observations on networks with lots of reordering, as a replacement for VEC) within IPPM.

Thanks, cheers,

Brian, hatless

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-trammell-ippm-spin-00.txt
> Date: 9 January 2019 at 12:08:32 CET
> To: "Brian Trammell" <[email-masked]>
> 
> 
> A new version of I-D, draft-trammell-ippm-spin-00.txt
> has been successfully submitted by Brian Trammell and posted to the
> IETF repository.
> 
> Name:		draft-trammell-ippm-spin
> Revision:	00
> Title:		An Explicit Transport-Layer Signal for Hybrid RTT Measurement
> Document date:	2019-01-09
> Group:		Individual Submission
> Pages:		14
> URL:            https://www.ietf.org/internet-drafts/draft-trammell-ippm-spin-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-trammell-ippm-spin/
> Htmlized:       https://tools.ietf.org/html/draft-trammell-ippm-spin-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-trammell-ippm-spin
> 
> 
> Abstract:
>   This document defines an explicit per-flow transport-layer signal for
>   hybrid measurement of end-to-end RTT.  This signal consists of three
>   bits: a spin bit, which oscillates once per end-to-end RTT, and a
>   two-bit Valid Edge Counter (VEC), which compensates for loss and
>   reordering of the spin bit to increase fidelity of the signal in less
>   than ideal network conditions.  It describes the algorithm for
>   generating the signal, approaches for observing it to passively
>   measure end-to-end latency, and proposes methods for adding it to a
>   variety of IETF transport protocols.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 9 Jan 2019 13:23:09 +0000

Hi Hatless Brian,

I think it is worthwhile to pursue Tx-independent 
Spin-bit-like-signal metrics and measurements.

As input to the process, Emile Stephan and I examined
how the current TCP-passive measurement material in
the Registry Initial Contents draft would need to be
modified for Spin-bit, and we captured the results of
our discussion in the Slides for the IPPM Registry drafts 
presented at the London IETF last year (101).

When there's a spare minute, we can take a look and 
see what aspects are covered/not-covered in your 
current draft.

regards from Paris-Saclay,
Al

> -----Original Message-----
> From: ippm [mailto:[email-masked]] On Behalf Of Brian Trammell
> (IETF)
> Sent: Wednesday, January 9, 2019 6:37 AM
> To: IETF IPPM WG <[email-masked]>
> Subject: [ippm] Fwd: New Version Notification for draft-trammell-ippm-
> spin-00.txt
> 
> Following up on some of the discussion we've had on the spin bit as a
> signal (as opposed to as a protocol feature of QUIC) on the IPPM list,
> I've submitted a draft describing the Spin Bit and the supplemental Valid
> Edge Counter signal in a transport-independent way, showing how it has
> been added to QUIC and a (possibly controversial, but definitely
> implementable and deployable) way to add it to TCP.
> 
> I'd like to ask the WG's opinion on whether it would like to pursue work
> on the measurement of spin signals (including, e.g., heuristics for
> recovering RTT samples from spin observations on networks with lots of
> reordering, as a replacement for VEC) within IPPM.
> 
> Thanks, cheers,
> 
> Brian, hatless
> 
> 
> > Begin forwarded message:
> >
> > URL:            https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_internet-2Ddrafts_draft-2Dtrammell-2Dippm-2Dspin-
> 2D00.txt&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=thpFnhu2Ui2AT6VgzJFpmdDnYX0Kx
> f6yGQ7ys3kZW_8&s=vu0ggCIjBhWcxUtFvirJCdM9mcOYa_WTjgEsPu9JS8k&e=
> > Status:         https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dtrammell-2Dippm-
> 2Dspin_&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=thpFnhu2Ui2AT6VgzJFpmdDnYX0Kx
> f6yGQ7ys3kZW_8&s=y8wIYvnk0uYIPzv6kt_uaNu7iWFgo6lyM0ni2oKC8mI&e=
> > Htmlized:       https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dtrammell-2Dippm-2Dspin-
> 2D00&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=thpFnhu2Ui2AT6VgzJFpmdDnYX0Kx
> f6yGQ7ys3kZW_8&s=kBIhxR27tuQYuTF2x3gJ4xllcRRL5bE9n4VszgAa4r8&e=
> > Htmlized:       https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_html_draft-2Dtrammell-2Dippm-
> 2Dspin&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=thpFnhu2Ui2AT6VgzJFpmdDnYX0Kx
> f6yGQ7ys3kZW_8&s=Ff6c3_nubeFyUnjZBR6VA8cjG_NEqiOOr_cpbKW30vU&e=
> >
> >
> > Abstract:
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=thpFnhu2Ui2AT6VgzJFpmdDnYX0Kx
> f6yGQ7ys3kZW_8&s=SuHAnbL6jmsW9x_1RX1jLJJPjy5J4IULAD8M3KuEK-M&e=

---

From: "Scharf, Michael" <[email-masked]>
Date: Wed, 9 Jan 2019 14:06:28 +0000

Any TCP-related text on spin bits in IPPM would in my option need to be agnostic to ...

(1) whether the signal would be specified for TCP (e.g., as experiment)

(2) whether the signal would be standardized for TCP (e.g., as proposed standard)

(3) how the signal would be encoded in TCP (e.g., new as option or by other some other means)

If adding the signal to TCP was doable by a minor TCP extension, in my personal point of view the TCP specification would be owned by TCPM. If this topic was not considered a minor extension of TCP, process questions may have to be addressed, e.g., whether a disruptive TCP extension would require a BoF or research in IRTF.

The easiest solution for IPPM would be to keep all documents entirely independent of the answers to (1), (2), and (3). 

I have add the TCPM list in CC to ensure that the TCPM community is in the loop.

Michael
(with no hat)

> From: ippm [mailto:[email-masked]] On Behalf Of MORTON, ALFRED C
> (AL)
> Sent: Wednesday, January 9, 2019 2:23 PM
> To: Brian Trammell (IETF); IETF IPPM WG
> Subject: Re: [ippm] Fwd: New Version Notification for draft-trammell-
> ippm-spin-00.txt
> 
> Hi Hatless Brian,
> 
> https://www.ietf.org/mailman/listinfo/ippm

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 9 Jan 2019 17:02:28 +0100

hi Michael,

Agree completely (indeed, look at the IANA considerations for the present revision of the document) -- the reasons we wrote this up for TCP is (1) we implemented it in the context of the IMC paper and it seems to work pretty well, (2) it points to a way to maintain passive RTT measurability for TCP in the event that timestamp deployment is reduced for efficiency/privacy reasons (see the associated thread last year, on tcpm, iirc), and (3) it might be nice if measurement boxes deployed to generate RTT samples from QUIC traffic could use the same methodology for TCP traffic.

I'd like to see if there's any traction for the idea of doing this in TCP for real before proposing the change in TCPM, though, hence this document going to IPPM.

Indeed, I think the final state of this document (should IPPM decide to pursue it) would be focused only on abstract mechanisms and the measurement techniques they enable, leaving the definition of how to generate the signal for each transport to draft-ietf-quic-transport (where the spin bit language will eventually be merged) for QUIC and a TCPM draft for TCP.

Cheers,

Brian, hatless

> On 9 Jan 2019, at 15:06, Scharf, Michael <[email-masked]> wrote:
>