< draft-cfb-ippm-spinbit-new-measurements-00.txt   draft-cfb-ippm-spinbit-new-measurements-01.txt >
IPPM Working Group M. Cociglio IPPM Working Group M. Cociglio
Internet-Draft Telecom Italia Internet-Draft Telecom Italia
Intended status: Experimental G. Fioccola Intended status: Experimental G. Fioccola
Expires: September 1, 2019 Huawei Technologies Expires: January 2, 2020 Huawei Technologies
F. Bulgarella F. Bulgarella
R. Sisto R. Sisto
Politecnico di Torino Politecnico di Torino
February 28, 2019 July 1, 2019
New Spin bit enabled measurements with one or two more bits New Spin bit enabled measurements with one or two more bits
draft-cfb-ippm-spinbit-new-measurements-00 draft-cfb-ippm-spinbit-new-measurements-01
Abstract Abstract
This document introduces additional measurements by using the same This document introduces additional measurements by using the same
spin bit signal as defined in [I-D.trammell-ippm-spin]. The spin bit spin bit signal as defined in [I-D.trammell-ippm-spin]. The spin bit
signal alone is not enough to evaluate correctly in every network signal alone is not enough to evaluate correctly in every network
condition the RTT of a flow. In order to solve this problem, it is condition the RTT of a flow. In order to solve this problem, it is
theorized the possibility of introducing an additional validation theorized the possibility of introducing an additional validation
signal called delay bit, similar to what is done done by the Valid signal called delay bit, similar to what is done done by the Valid
Edge Counter (VEC), but using just one bit instead of two. An Edge Counter (VEC), but using just one bit instead of two. An
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 1, 2019. This Internet-Draft will expire on January 2, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
2. Spin bit and Delay bit mechanism . . . . . . . . . . . . . . 3 2. Spin bit and Delay bit mechanism . . . . . . . . . . . . . . 3
2.1. Delay Sample generation . . . . . . . . . . . . . . . . . 5 2.1. Delay Sample generation . . . . . . . . . . . . . . . . . 5
2.1.1. The recovery process . . . . . . . . . . . . . . . . 5 2.1.1. The recovery process . . . . . . . . . . . . . . . . 5
2.2. Delay Sample reflection . . . . . . . . . . . . . . . . . 6 2.2. Delay Sample reflection . . . . . . . . . . . . . . . . . 6
3. Using the Spin bit and Delay bit for Hybrid RTT Measurement . 7 3. Using the Spin bit and Delay bit for Hybrid RTT Measurement . 7
3.1. End-to-end RTT measurement . . . . . . . . . . . . . . . 7 3.1. End-to-end RTT measurement . . . . . . . . . . . . . . . 7
3.2. Half-RTT measurement . . . . . . . . . . . . . . . . . . 7 3.2. Half-RTT measurement . . . . . . . . . . . . . . . . . . 7
3.3. Intra-domain RTT measurement . . . . . . . . . . . . . . 7 3.3. Intra-domain RTT measurement . . . . . . . . . . . . . . 7
4. Observer's algorithm and Waiting Interval . . . . . . . . . . 8 4. Observer's algorithm and Waiting Interval . . . . . . . . . . 8
5. Adding a Loss bit to Delay bit and Spin bit . . . . . . . . . 9 5. Adding a Loss bit to Delay bit and Spin bit . . . . . . . . . 9
5.1. Round Trip Packet Loss measurement . . . . . . . . . . . 9 6. Round Trip Packet Loss measurement . . . . . . . . . . . . . 9
6. Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. RTT dependent Packet Loss using one bit . . . . . . . . . 10
6.1. QUIC . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. RTT independent Packet Loss using two bits . . . . . . . 10
6.2. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7.1. QUIC . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 7.2. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
[I-D.trammell-ippm-spin] defines an explicit per-flow transport-layer [I-D.trammell-ippm-spin] defines an explicit per-flow transport-layer
signal for hybrid measurement of end-to-end RTT. This signal signal for hybrid measurement of end-to-end RTT. This signal
consists of three bits: a spin bit, which oscillates once per end-to- 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 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 for loss and reordering of the spin bit to increase fidelity of the
signal in less than ideal network conditions. signal in less than ideal network conditions.
skipping to change at page 8, line 10 skipping to change at page 8, line 10
Taking advantage of the half-RTT measurements it is also possible to Taking advantage of the half-RTT measurements it is also possible to
calculate the intra-domain RTT which is the portion of the entire RTT calculate the intra-domain RTT which is the portion of the entire RTT
used by a QUIC flow to traverse the network of a provider (or part of used by a QUIC flow to traverse the network of a provider (or part of
it). To achieve this result two observers, able to watch traffic in it). To achieve this result two observers, able to watch traffic in
both directions, must be employed simultaneously at ingress and both directions, must be employed simultaneously at ingress and
egress of the network to be measured. At this point, to determine egress of the network to be measured. At this point, to determine
the delay between the two observers, it is enough to subtract the two the delay between the two observers, it is enough to subtract the two
computed upstream (or downstream) RTT components. computed upstream (or downstream) RTT components.
The spin bit is an alternate marking generated signal and the only
difference than RFC 8321 [RFC8321] is the size of the alternation
that will change with the flight size each RTT. So it can be useful
to segment the RTT and deduce the contribution to the RTT of the
portion of the network between two on-path observers and it can be
easily performed by calculating the delay between two or more
measurement points on a single direction by applying RFC 8321
[RFC8321].
4. Observer's algorithm and Waiting Interval 4. Observer's algorithm and Waiting Interval
Given below is a formal summary of the functioning of the observer Given below is a formal summary of the functioning of the observer
every time a delay sample is detected. A packet containing the delay every time a delay sample is detected. A packet containing the delay
bit set to 1: bit set to 1:
o if it has the same spin bit value of the current period and no o if it has the same spin bit value of the current period and no
delay sample was detected in the previous period, then it can be delay sample was detected in the previous period, then it can be
used as a left edge (i.e., to start measuring an RTT sample), but used as a left edge (i.e., to start measuring an RTT sample), but
not as a right edge (i.e., to complete and RTT measurement since not as a right edge (i.e., to complete and RTT measurement since
skipping to change at page 9, line 29 skipping to change at page 9, line 38
These packets bounce between Client and Server to complete two rounds These packets bounce between Client and Server to complete two rounds
and an Observer counts the marked packets during the two rounds and and an Observer counts the marked packets during the two rounds and
compares the counters to find Round Trip(RT) losses. compares the counters to find Round Trip(RT) losses.
The problem to be solved is to choose the right number of packets to The problem to be solved is to choose the right number of packets to
mark to avoid marked packets congestion on the slowest traffic mark to avoid marked packets congestion on the slowest traffic
direction. But the solution is simple, because it is enough to direction. But the solution is simple, because it is enough to
choose the number of packets that transit on the slowest direction choose the number of packets that transit on the slowest direction
during an RTT. during an RTT.
5.1. Round Trip Packet Loss measurement 6. Round Trip Packet Loss measurement
The Client generates a train of marked packets (Packet Loss Samples) The Client generates a train of marked packets (Packet Loss Samples)
by using the additional bit called Loss bit. The marked packets are by using the additional bit called Loss bit. The marked packets are
generated at the slowest direction rate (only when a packet arrives generated at the slowest direction rate (only when a packet arrives
the Client marks an outgoing packet). The Server reflects these the Client marks an outgoing packet). The Server reflects these
packets accordingly and, as a consequence, it could insert some not- packets accordingly and, as a consequence, it could insert some not-
marked packets. Then the client reflects the marked packets and the marked packets. Then the client reflects the marked packets and the
server reflects the marked packets again. The Client generates a new server reflects the marked packets again. The Client generates a new
train of marked packets and so on. train of marked packets and so on.
skipping to change at page 10, line 9 skipping to change at page 10, line 17
Packet Loss (RTPL). Packet Loss (RTPL).
In addition, this methodology allows Half-RTPL measurement and Intra- In addition, this methodology allows Half-RTPL measurement and Intra-
domain RTPL measurement, in the same way as described in the previous domain RTPL measurement, in the same way as described in the previous
Sections for RTT measurement. Sections for RTT measurement.
The method allows the packet loss calculation for a portion of the The method allows the packet loss calculation for a portion of the
traffic but it is useful to perform RT Packet Loss measurement that traffic but it is useful to perform RT Packet Loss measurement that
gives useful information coupled with RTT. gives useful information coupled with RTT.
6. Protocols 6.1. RTT dependent Packet Loss using one bit
6.1. QUIC Using a single bit in addition to the spin bit and delay bit enables
passive measurability of the end-to-end round-trip loss rate.
The algorithm requires a mechanism to individually identify each
train of packets in order to enable the observer to distinguish
between trains belonging to different rounds. This is achieved by
introducing a temporal pause of 2*RTT duration during which no marked
packets are forwarded. Marked packets are generated by the client
for the duration of an RTT in order to be synchronized with the spin
bit algorithm and to have a sufficient numbers of marked packets.
However, this single bit methodology replies and exposes the RTT of
the connection in any case, when the spin bit and the delay bit are
used and when these are disabled.
6.2. RTT independent Packet Loss using two bits
An RTT independent version of this algorithm requires two bits and
can be used when both spin bit and delay bit are disabled.This
implies that an observer must be able to determine whether the spin
bit is active and correctly spinning or not (choosing, accordingly,
the right version of packet loss measurement to be used).
Without using the spin bit, it is difficult to find the right pause
duration but, with a two bits packet loss field, the temporal pause
necessary to distinguish the different train of packets is no longer
needed. That's because packets generated and reflected by the client
are marked using two different marking values. Furthermore, instead
of generating marked packets for the duration of an RTT, a fixed
duration for the generation phase can be used (e.g. 100ms).
In this way, no information related to the RTT of the connection is
transmitted on the wire.
7. Protocols
7.1. QUIC
The binding of this signal to QUIC is partially described in The binding of this signal to QUIC is partially described in
[I-D.ietf-quic-spin-exp], which adds the spin bit only to QUIC. [I-D.ietf-quic-spin-exp], which adds the spin bit only to QUIC.
From an implementation point of view, the delay bit is placed in the From an implementation point of view, the delay bit is placed in the
partially unencrypted (but authenticated) QUIC header, alongside the partially unencrypted (but authenticated) QUIC header, alongside the
spin bit, occupying one of the two bits left reserved for future spin bit, occupying one of the two bits left reserved for future
experiments. As things stand, according to experiments. As things stand, according to
[I-D.ietf-quic-transport], the proposed scheme of the first header's [I-D.ietf-quic-transport], the proposed scheme of the first header's
byte would be 01SDRKPP. byte would be 01SDRKPP.
6.2. TCP 7.2. TCP
The signal can be added to TCP by defining bit 4 of bytes 13-14 of The signal can be added to TCP by defining bit 4 of bytes 13-14 of
the TCP header to carry the spin bit, and eventually bits 5 and 6 to the TCP header to carry the spin bit, and eventually bits 5 and 6 to
carry additional information, like the delay bit and the loss bit. carry additional information, like the delay bit and the loss bit.
7. Security Considerations 8. Security Considerations
The privacy considerations for the hybrid RTT measurement signal are The privacy considerations for the hybrid RTT measurement signal are
essentially the same as those for passive RTT measurement in general. essentially the same as those for passive RTT measurement in general.
8. Acknowledgements 9. Acknowledgements
tbc tbc
9. IANA Considerations 10. IANA Considerations
tbc tbc
10. References 11. References
10.1. Normative References 11.1. Normative References
[I-D.ietf-quic-spin-exp] [I-D.ietf-quic-spin-exp]
Trammell, B. and M. Kuehlewind, "The QUIC Latency Spin Trammell, B. and M. Kuehlewind, "The QUIC Latency Spin
Bit", draft-ietf-quic-spin-exp-01 (work in progress), Bit", draft-ietf-quic-spin-exp-01 (work in progress),
October 2018. October 2018.
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-18 (work and Secure Transport", draft-ietf-quic-transport-20 (work
in progress), January 2019. in progress), April 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>. May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate-Marking Method for Passive and Hybrid "Alternate-Marking Method for Passive and Hybrid
Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
January 2018, <https://www.rfc-editor.org/info/rfc8321>. January 2018, <https://www.rfc-editor.org/info/rfc8321>.
10.2. Informative References 11.2. Informative References
[I-D.trammell-ippm-spin] [I-D.trammell-ippm-spin]
Trammell, B., "An Explicit Transport-Layer Signal for Trammell, B., "An Explicit Transport-Layer Signal for
Hybrid RTT Measurement", draft-trammell-ippm-spin-00 (work Hybrid RTT Measurement", draft-trammell-ippm-spin-00 (work
in progress), January 2019. in progress), January 2019.
[I-D.trammell-quic-spin] [I-D.trammell-quic-spin]
Trammell, B., Vaere, P., Even, R., Fioccola, G., Fossati, Trammell, B., Vaere, P., Even, R., Fioccola, G., Fossati,
T., Ihlar, M., Morton, A., and S. Emile, "Adding Explicit T., Ihlar, M., Morton, A., and S. Emile, "Adding Explicit
Passive Measurability of Two-Way Latency to the QUIC Passive Measurability of Two-Way Latency to the QUIC
 End of changes. 17 change blocks. 
27 lines changed or deleted 74 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/