IPPM Agenda IETF 110

Chairs: Tommy Pauly & Ian Swett

Session 1

Monday 8 March 2021, 14:30-15:30 UTC

Welcome, Note Well, Agenda, Status




IOAM Data Integrity

Loopback and Direct Export

Tal to present https://datatracker.ietf.org/meeting/110/materials/slides-110-ippm-sessb-ioam-flags-and-direct-exporting-00 (moved to later)

Martin presenting the challenges with loopback and DEX - https://datatracker.ietf.org/meeting/110/materials/slides-110-ippm-sessb-ioam-loopback-direct-export-concerns-00 - Greg : (didnt quite get the gist of this) - Tal : IPFIX and other export methods also have these challenges. If we need to find a solution of this it should. be generic for IOAM and IPFIX and other methods. - Tommy : Will batch processing help? will make it more deterministic. Will this be acceptable?

Session 2

Friday 12 March 2021, 16:00-18:00 UTC

Welcome, Note Well, Agenda, Status

Agenda bash-adding in Loopback/DEX to finish from last time.

Loopback and Direct Export (Continued from session 1)

Tal presenting

Amplification threat, discussed earlier. Both drafts call out perf and security considerations. The threats are worse in wide area networks Loopback & DEX mitigate via rate limiting Loopback mitigates with applying to a subset, being truncated, and being a single data field

Suggestions are to add: - Probability bound for loopback and DEX - Stronger restriction to a domain

Tommy: How do we restrict to a domain? Tal: This would be text to say that you need to understand your deployment topology. Tommy: Shouldn't we be considering changing the export strategy to delay/batch the export? Tal: We want to reference ipfix and other docs about sampling strategy. Tommy: But we should have this be about export time, not sampling rate. Tal: We want deterministic logic around when DEX nodes export. Martin: I'm concerned about this deterministic approach here. I'm also concerned about just saying we need to be careful about the domain. We could say that you must not do this in an overlay, etc. Could be effective even if it makes it less useful. Mirja: You've been talking about sampling of requesting data. But we need to also restrict on the nodes doing the exporting, in the node, not from the requester. We need to give advice for how the nodes apply protection mechanisms individually. You can also only allow exporting to nodes that are known nodes. I'm still not convinced this will be a safe/good design, since there are so many sharp edges. We would do well to find a different design.

Tal: Also have open issues around hop count field and DEX option length.


Al: Following up on IESG feedback, lots of iteration on the list. Added an applicability sub-section. Restricted to access measurement, and added requirements for limiting to diagnostic measurement. Added more detail on method and algorithm. Changed SHOULDs to MUSTs Updated running code section Updates to expected safe range for key parameters Timeouts for senders and receivers guarantee that tests stop

Magnus: What's determining the retransmission value? Al: It's a static timeout value as defined here. It doesn't care about round trip delay, it's about inter-packet arrival time. Magnus: The control loop is feedback timer + RTT. The traffic load is based on feedback, but this doesn't have the same congestion control as TCP or QUIC. Al: In the context of static timeouts, can you provide the values you're comfortable with? If you don't receive packets, you tell the other side, and it lets the other side know. There's not traditional loss detection, but it does provide the info. This is how we define methods and metrics in IPPM. Magnus: We shouldn't go way overboard when measuring capacity. Al: Many protocols could overwhelm the network if they don't follow the bounds.

J Ignacio: There are many services like speedtest, etc, that measure your bandwidth. This is no so strange to measure capacity. If you don't receive all the packets, you stop sending. We just need to set up the limits.

Tommy: I disagree with the blockage here, I think this is appropriate for a metric/method.

Martin: We'll want a new WGLC, and then re-ballot it.

Zahed: I think it looks like this will be ready to progress once the WG approves again.

Greg White: It may be good to clarify if this is trying to be friendly to other flows or not. That would help explain how this algorithm works. Is it fair capacity, remaining capacity, or full capacity?

Al: Full capacity. We'll push other traffic down for a few moments during the measurement. It's not friendly. It's trying to measure the maximum.


Ruediger: Measures on segment routed paths. Still doing updates editorially to the metrics. (Terminology will continue to be updated, etc.) Metrics will need to be completed more later.

J. Ignacio: Why use the mean of the time, not the median?


Mauro: Explicit Flow Measurement (EFM) adds a few marking bits to measure delay and round-trip/one-way packet loss.

Hackathon implementations from telecom italia, ericsson, orange, huawei.

Single spin bit has limitations with holees in traffic. Delay bit fixes that.

New delay bit is a single bit measurement, and independent of spin bit. Different from previous 2-bit measurement.

Greg: What about compact marking that uses one bit? Mauro: This is more about protocols like QUIC where the transport doesn't allow the bits to be changed by the path.

Martin: I'm concerned about if QUIC is engaged enough Where would the privacy review live?

Tommy: I'd like to call for adoption, and cross list to QUIC

Ian: Are some of the authors who have major servers interested in deploying this?

Gorry: Is this a protocol or method in IPPM?

Tommy: My impression is that this is just a method.

Gorry: This could be in GRE too. Let's write a good method, and then leave not limit the protocol work.


Greg: HTS is now a new IOAM trace option type, for the IANA registry. Authentication for HTS, and clarified intermediate node behavior.

HTS can be used as a method to collect IOAM data. IOAM is a trigger packet, and HTS is used for transmitting the data.

Can extend more in the future, but current auth uses 16 octet digest HMAC.

Asked for adoption; no comments at mic, some support on Jabber.


(Low on time, doing a lightning talk)


(Low on time, doing a lightning talk)


Did a show of hands to get input on working on this.

9 in favor. 5 against. 28 did not respond.

Lightning Talks