=============================================== IP Performance Measurements (IPPM) IETF 100 Singapore Raffles City Convention Center Bras Basah Room Monday Morning session I 9:30-12:00 (noon) Singapore Local Time (UTC +8) =============================================== IPPM WG Chairs: Brian Trammell, Bill Cerveny (not present) Note taker: Tal Mizrahi CHAIR SLIDES ------------ Presenter: Brian https://datatracker.ietf.org/meeting/100/materials/slides-100-ippm-00-chair-slides/ Summary: - Note well was presented. - State of the current drats was presented. - IPPM meeting agenda presented. IPv6, IPv4 and Coexistence Updates for IPPM's Active Metric Framework ------------------------------------------------------------------------------------------------- Presenter: Vinayak Hegde https://datatracker.ietf.org/meeting/100/materials/slides-100-ippm-01-ipv6-ipv4-and-coexistence-updates-for-ippms-active-metric-framework-draft-ietf-ippm-2330-ipv6/ Summary: - Status of the draft was presented. - How many have read the draft? A few hands raised. - Nalini Elkins: we need another draft about the 6Lo functionality. - Brian: are there demands to use this with 6Lo? If yes, we need the draft, otherwise we do not. - Vinayak: right. - Al Morton: the work that is required here is to define the standard form packet for reduced header. - Brian: if there is interest to do this work, and there is interest in this work, it should be done. - Brian: WG LC is done. Is anyone interested in shepherding this document? - Brian will be the shepherd. Initial Performance Metric Registry Entries -------------------------------------------------------- Presenter: Al Morton https://datatracker.ietf.org/meeting/100/materials/slides-100-ippm-02-initial-performance-metric-registry-entries-draft-ietf-ippm-initial-registry-and-draft-morton-ippm-mbm-registry/ Summary: - Al: should we still define the delay as first-bit on one place to last-bit on another place? - Brian: let's not cheat. For TCP we are usually looking at packet-level timestamps, not bit level timestamps. - Al: right, let's leave the timestamp at the packet level. - Brian: SYN / SYN-ACK should be a separate metric. In a lot of cases the handshake is treated differentely than the rest of the flow. Another reason is that the metric definition for TCP is the basis for other protocols, e.g., QUIC - there is an open issue in QUIC about whether it is possible to measure the RTT online. - Al: let's add QUIC to the naming element. - Brian: I will read the draft. - Al: please do. - Nalini Elkins: a lot of times the first N packets are different than the rest of the flow. For example, in TLS the first N packets are different. - Rachel Huang: interesting, because passive metrics for TCP are useful. I am happy to see this. The delay for SYN/ACK should be a separate metric. RTT forward and RTT receive should be separate. - Al: what statistics would you be interested in? - Rachel: the average is the most important. - Al: it makes it simpler if we use only one. - Al: please review the draft. - Brian: question about DNS response time - is it for a specific RR? - Al: yes. - Brian: there is an interesting method for DNS measurement by encoding information in the query itself. It is a question of what exactly we are trying to measure: specific RR, or the infrastructure itself. - Al: from a registry perspective there has not been a nailed down method to do this. We will need to nail down a method for this. - Rachel: what is the TCP XR? - Al: I prepared that a long time ago. What do we want to measure in the TCP XR? - Rachel: I can provide some inputs. In-situ OAM ---------------- Presenter: Frank Brockners https://datatracker.ietf.org/meeting/100/materials/slides-100-ippm-03-in-situ-oam-ioam-draft-ietf-ippm-ioam-data/ Summary: - John Lemon: we are suggesting to support both PTP and NTP timestamp formats. - Greg Mirsky: you could use just a single bit to indicate whether you use PTP or NTP, no need for two separate bits in the IOAM bitmap for that. - John: we thought about it, but the current IOAM structure is based on a data bitmap. There are separate data fields for seconds and nanoseconds. - Greg: there are a lot of other protocols that use both NTP and PTP timestamp formats, and only require a single bit to pick between them. - Brian: there is also the option of not having a timestamp at all, so all the possible options need to be addressed. - Greg: it is an over-complication. - John: you are suggesting a fundamental change in how the data is encoded. - Greg: yes. - Shwetha Bhandari: it may make sense to have a global decision in the control plane, and not necessarily on a per-hop basis. - John: a node may run both NTP and PTP, and it needs to be able to accept a timestamp in both formats depending on who it communicates with. - Shwetha: this could be conveyed on a per-IOAM domain during session setup, not necessarily needed on a per-hop basis. - Brian: the requirement here for PTP/NTP makes sense. We have seen this in other work in the WG. Applications often do not handle timestamps correctly or consistently. I am not sure we need all the possible combinations of PTP/NTP seconds/nanoseconds/fractions. Need to rethink what subset is needed. - Frank: I second what Brian said. When we started IOAM we wanted a dedicated namespace for the field formats in order to avoid to many data field types. However, there are use cases in which different nodes fill in information in different formats. The node ID indicates what the node is capable of, including potentially the timestamp format. If that is not the case, we may not need the indication, and can go with two fields, We may be over-specifying with separating the flags to seconds/nanoseconds. We need some more thought about how exactly we do this in order to avoid the slippery slope of too many formats. - Greg: the suggestion to look at this information as part of the configuration is a good direction. We should look at a data model. This discussion is not limited to the timestamp format, but for other information as well. Node ID will be present, so we do not necessarily need the timestamp format. - John: the node ID is not necessarily present. It may be difficult for the data plane to add all this information including the node ID. - Greg: I would like to hear more about scenarios where the metadata is not accompanied by the node ID. - Mickey: edge-to-edge timestamps - do you mean ingress on both sides? - John: egress on the transmitting node, and ingress on the receiving node. It is not specified in the current draft. - Frank: please come up with proposed text, and send it to the list. It is probably relatively easy to add another edge-to-edge option. Please take it to the list. - Sarah Banks: I do not read Github. You keep raising problems in chips. What chip are your referring to? - John: the problems I raise are not specific to a certain chip, but are related to hardware implementations in general. - Mickey: we have undefined bits in the IOAM bitmap, and we do not specify what the transmitter/receiver needs to do with these bits. We need to think about how to define the functionality with future compatibility in mind. We need to either ignore undefined bits, or to have the bitmap well-defined without future changes. - Barak Gafni: why can't you define the bits as 'undefined'? - Mickey: if you just ignore the bit, it messes with the option length. - Greg: if something is undefined it must be zero on transmission and ignored on reception, right? - Mickey: but that does not work. If we use a bit that is defined in a new version of the protocol, then the length will not be consistent across the network. - Greg: that is an issue of compatibility between versions. One way to do it is to have a version field in each hop. Another approach is not to support compatibility between versions. - Barak: if the unused bits are set as reserved, then if they are used they are just ignored by nodes that do not support these bits. - Brian: we have had this discussion in different protocols, and there are various approaches. I suggest to have well-defined functionality. It looks like the main issue here is the length, right? - Mickey: not exactly. The nodes that add the info are not the problem. The problem will occur in the last node which parse the information. - Brian: you can define the length of each code point right now, even for the undefined ones. - Haoyu Song: we wrote a draft about this. The idea is to use an extension bit, that allows future extensibility. - Kyle Larose: the first suggested option does not address the problem. - Mickey: right. - Brian: with the chair hat on - there is an emerging method for using Github within a working group. We need to fix the IOAM repository to comply to that method. - Frank: let's do that right now. Two-Way Active Measurement Protocol (TWAMP) Data Model ----------------------------------------------------------------------------------- Presenter: Al Morton https://datatracker.ietf.org/meeting/100/materials/slides-100-ippm-two-way-active-measurement-protocol-twamp-data-model-and-well-known-port-assignments-draft-ietf-ippm-twamp-yang-and-draft-morton-ippm-port-twamp-test0/ Summary: - Al: WG last call is over, but no clear statement about the consensus. - Brian: I believe there is consensus about the draft, but I will clarify that. - The authors suggest call for adoption of the well-known port assignment draft. - Brian: that makes sense. How many people have read the draft? - A few hands raised. - Brian: any objections to WG adoption call? - No objections. - Brian: I will go ahead and start the adoption call on the list. - Greg: my understanding is that the range is enahanced, using the ranges make port 862 optional. - Al: will look into it. Advanced Unidirectional Route Assessment (AURA) ---------------------------------------------------------------------- Presenter: Al Morton https://datatracker.ietf.org/meeting/100/materials/slides-100-ippm-04-advanced-unidirectional-route-assessment-draft-amf-ippm-route/ Summary: - Al: Should we extend our scope beyond IP, e.g., MPLS? - Greg: great idea, but we can generalize even beyond MPLS, including for example NSH, BIER, segment routing. - Al: there is more than one way to approach this. I propose that we start with MPLS, and then we define standard form packets. Once we do this for MPLS, it will be easier for other protocols. - Greg: for MPLS we need to consider RFC 6374 for loss, delay measurement. There is a question of how many timestamps to include. - Al: we may need a re-chartering discussion. - Brian: right. - Nalini: everything in the draft was assuming TCP/UDP, without talking about other transport protocols. - Al: right, that is what Carlos has raised. We considered this, but haven't gone there yet. It is pretty generalized at this point, so the extension should be straightforward. - Nalini: maybe consider QUIC. - Al: let's discuss. - Brian: the new charter talks about performance measurement over IP. The way networks work today is that you need to be able to measure networks without the restriction of a specific layer. Generalizing the route metric may be feasible, but defining stuff over MPLS may require re-chartering. - Spencer: there is more than one way to go. We may be able to update the charter as-we-go, and do some of this work which is borderline related. We can first decide whether the work needs to be done, and only then decide whether the current WG is the right place. - Brian: we are looking at work that is potentially generalizable, but at this point let's do the route work first, and leave the non-IP stuff to the future. - Carlos Pignataro: I agree that the work is generalizable. I like the suggestion. I suggest that the MPLS related work can also proceed, perhaps as an appendix. - Biran: we can always discuss these extensions in the context of unchartered suggestions. - Nalini: you talked about IP and higher, but you should also consider IP and lower. In some cases you need to look at lower layers. - Al: how many people have read the draft? - A few hands raised. - Brian: humming vote for adopting this document. - A fair hum. No humming against. - Brian: we will call for adoption. Simple Two-way Active Measurement Protocol (STAMP): ---------------------------------------------------------------------------- Presenter: Greg Mirsky https://datatracker.ietf.org/meeting/100/materials/slides-100-ippm-05-simple-two-way-active-measurement-protocol-stamp-draft-mirsky-ippm-stamp-and-draft-mirsky-ippm-stamp-yang/ Summary: - The draft was presented. - Greg: Would like feedback about security. Perhaps the right way is to define the IPv4 variant without security, and to consider a security mechanism over IPv6. - Brian: this will not necessarily be acceptable by the security directorate. There needs to be an analysis of this in the Security Considerations section. - Brian: who has read the draft or is familiar with TWAMP Lite? - A few hands raised. - Humming vote for considering WG adoption of STAMP. - Gentle hum. No hums against. - Brian: will do a call for adoption on the list. IOAM Improvements ---------------------------- Presenter: Haoyu Song https://datatracker.ietf.org/meeting/100/materials/slides-100-ippm-07-08-09-ioam-improvements-haoyu-song/ Summary: - Three drafts were presented: draft-song-ippm-ioam-data-extension draft-song-ippm-segment-ioam draft-song-ippm-ioam-data-validation-option - Questions and comments should be posted on the list. Extended OAM to Convey In-situ OAM Configuration State ------------------------------------------------------------------------------ Presenter: Xiao Min https://datatracker.ietf.org/meeting/100/materials/slides-100-ippm-10-extended-oam-to-convey-in-situ-oam-configuration-state-draft-xiao-ippm-ioam-conf-state/ Summary: - The draft was briefly presented. - Comments will be posted on the list. TWAMP Extension for Direct Loss Measurement ----------------------------------------------------------------- Presenter: Xiao Min https://datatracker.ietf.org/meeting/100/materials/slides-100-ippm-11-twamp-extension-for-direct-loss-measurement-draft-xiao-ippm-twamp-ext-direct-loss/ Summary: - The draft was briefly presented. - Comments will be posted on the list. Multipoint Alternate Marking method for passive and hybrid performance monitoring --------------------------------------------------------------------------------------------------------------- Presenter: Giuseppe Fioccola https://datatracker.ietf.org/meeting/100/materials/slides-100-ippm-12-multipoint-alternate-marking-method-for-passive-and-hybrid-performance-monitoring-draft-fioccola-ippm-multipoint-alt-mark-01/ Summary: - The draft was briefly presented. - Comments will be posted on the list. Compact Alternate Marking ------------------------------------- Presenter: Tal Mizrahi https://datatracker.ietf.org/meeting/100/materials/slides-100-ippm-13-compact-alternate-marking-draft-mizrahi-ippm-compact-alternate-marking/ Summary: - The draft was briefly presented. - Comments will be posted on the list. Adjourned at 11:58.