RFC6374 Synonymous Flow Labels draft-bryant-mpls-rfc6374-sfl-03 S. Bryant, M. Chen & Z. Li: Huawei G. Swallow & S. Sivabalan: Cisco Systems G. Mirsky: G. Fioccola: Telecom Italia

This Revision The text on RFC6374 Packet Loss Measurement is unchanged and stable. We have added text to cover a number of packet delay & jitter measurements. The draft describes a number of measurement types. We seek input from the WG on which ones would likely be deployed.

RFC6374 Single Packet Delay Measurement Works exactly as you would expect an RFC6374 packet is sent over the SFL that is being instrumented. It only adds useful information compared to running RFC6374 over the LSP if there is SFL specific handling along the LSP that treats the packet differently from any other packet with the same TC [RFC3270].

Delay Measurement Marking (1) AAAAAAAAAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB Packet loss measurement (2) AADDDDAAAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB Marking subset for delay (4) AACDCDCDAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB Multiple delay measurements within a packet loss measurement

Some Simplifying Rules Too many combinations of measurements. Recommended simplifications: System measuring delay MUST be able to measure loss and must be configured to do so. A delay measurement MAY start at any point during a loss measurement batch, subject to rule 3. A delay measurement interval MUST be short enough that it will complete before the enclosing loss batch completes. The duration of a second delay batch must be such that all packets from the packets belonging to a first delay batch will have been received before the second delay batch completes. Given that the sender controls both the start and duration of a loss and a delay packet batch, these rules are readily implemented in the control plane.

Method 1: Time Buckets Classifies the inter-packet gap into a series of “time buckets” i.e. 1us, 2us, 4us etc A relatively simple operation, but in practise limited config abilities likely to be provided by h/w Shows more structure in jitter than max, min, mean, std var’n +---------------------+ ~ RFC 6374 header ~ +--------+------------+ |Num Bkts| Reserved | | Interval x 10ns | | Num Pkt in Interval | ~ ~ ~ TLVs ~

Method 2: Classic Standard Deviation over a Batch µ = (Sum of Delay)/n Var = (∑ Delay^2 - n(µ)^2)/(n-1) Naïve algorithm – will investigate assumed mean +---------------------+ ~ RFC 6374 header ~ | Num Packets | | Sum delays for batch| | Min Delay | | Max Delay | | Sum Delay^2 | ~ TLVs ~

Method 3: Average Delay A one way delay method. Draft-ietf-ippm-alt-mark By reporting the average timestamp of packets, the average packet delay can be measured at multiple points along its path. +---------------------+ ~ RFC 6374 header ~ | Num Packets | | Time of First Pkt | | Time of Last Pkt | | Sum of Timestamps | | Sum Delay^2 | ~ TLVs ~

Sampled Measurement AASAASAASABBSBSBBBBBBAAASAASAAABBSBBBSBBB Instead of measuring all packets in a block, sample. Sample is singleton or first packet in a block Measurement interval not defined by colour but by interval between RFC6374 packets This approach may be less impacted by ECMP effects

Next Steps We need comments, particularly on measurement preferences. We suggest focusing on getting this right and then circle back to the architecture and control plane. Is it time for the WG to adopt this draft?