Friday 29 July 2022, 12:30-14:30 EDT
Philadelphia North,
https://meetings.conf.meetecho.com/ietf114/?group=ippm
Chairs: Tommy Pauly & Marcus Ihlar
Note Taker: Stuart Cheshire
Martin Duke gave status update
Tommy Pauly proposed participating in the next IETF Hackathon
There was a request for a reference from draft-ietf-ippm-ioam-deployment
to draft-ietf-ippm-ioam-conf-state.
Will proceed with requesting early allocation of code points from IANA.
Al Morton gave a detailed overview of feedback from the Security
Directorate.
Martin Duke asked if document will be finished in the next six months.
Al Morton said yes.
Tommy Pauly suggested that if we don’t want to guard against an attacker
injecting or clearing STOP bits, at least we might want to detect that
it has happened after the fact.
Martin Duke: The square bit (Q) seems to have a lot of overlap with RFC
8321.
Giuseppe Fioccola: The difference is that one is based on time and the
other is based on number of packets.
Martin Duke: This community needs to decide which it wants to do.
Tommy Pauly suggested that as an informational document, it would be
good for this document to describe the pros and cons of each.
Will update document and do a new Last Call.
Christoph Paasch presented overview of changes to the draft, and open
issues tracked in the GitHub repository.
Major item is continued refinement of the measurement algorithm.
Al Morton pointed out a mistake in the arithmetic: the equation uses a
weight of 1/3 instead fo 1/6.
Al Morton: With 20 connections there is a risk of synchronization.
Al Morton: Measurement of throughput and delay is good. There are other
useful things we could measure too, like packet reordering.
Tommy Pauly: Check with Mark Nottingham about use of “.well-known”
J Ignacio Alvarez-Hamelin said that there could be variability in
throughput measurements if there may be other traffic sharing the
bottleneck link.
Did real-world test using a small hosting service to test how well IPv6
extension headers traverse the Internet. In this limited testing
extension headers worked sucessfully.
Bob Briscoe: Be aware that all these tests were between large data
centres, so they do not indicate whether extension headers will work
sucessfully on consumer access networks (residential ISPs, mobile phone
carriers, etc.).
Mohamed Boucadair as joined as a contributor.