No changes to the agenda.
Note from the chairs: IPPM as a WG will move from transport to OPS.
Hopefully that will help with scheduling moving forward.
Note-takers: Frank Brockners (& Ruediger Geib)
Greg recaps main qualities of the hybrid two step protocol - probe
packets follow the same path but would typically map to a different
class of service, so that the probe packets would not compete for
resources with the user data. No comments.
Next version will include all comments received on the list.
Status: Early review of SECDIR completed - draft updated per reviewer
suggestions.
Next step will be to have another SECDIR review to get feedback from
SECDIR on the updates ("private" review in the works, i.e. Nalini is in
a conversation with the reviewer - will be followed by a formal SECDIR
review.
Chairs suggest that the WG reviews the updates as well.
Team is working on an implementation (done in eBPF).
Assuming successful SECDIR review, we can kick-off WGLC.
Publication of accompanying information, wiki entries and implemenation
status, is welcome.
No floor comments
Editorial updates, added another code point for DEX;
Still waiting for SECDIR review.
Suggestion by Justin is to kick-off WGLC to drive folks to review the
doc.
Suggestion from the chair: Ask the SECDIR secretary to assign a new
reviewer; WGLC to be kicked off before IETF119.
No floor comments.
Stuart presents the slides. 3 different implementations exists. Ships by
default with macOS.
Authors ask for last call
Lucas Pardue: still has open issues, could be dealt with during LC.
Stuart would welcome comments asap.
Kireeti Kompella: Consideration, given that the tool would be used in a
formal environment. Has anyone done the analysis of gaming the system?
Stuart: Important point, read doc and provide feedback. Tests do
"application layer RTT" instead of ICMP echo. Prioritizing ICMP won't
"help you". The only way to game the tool would be to provide really
good internet service.
Tommy: Well-known URI to be supplied. Have we talked to the expert?
Stuart: He's not sure what those experts are. He can expect the tool to
support additional features, like PMTU discovery etc. Idea is when you
fetch the tests from the well known URI, you get a json that describes
what is available.
Tommy: Talk to Mark Nottingham.
Greg: Rakesh Gandhi joined as an author (and Greg would welcome further
co-authors). Draft had timed out, now revived. Several STAMP extensions
now contained (from RFC 8972). Greg asks for comments on the list. Aims
on a stable version before IETF 119.
No comments from the floor.
Individual drafts that have recent on-list discussion.
Rakesh presents. STAMP for IOAM - to implement a method for active
measurements with IOAM (see IOAM active flag).
Additional ideas (not yet in the draft, discussion on the list is
welcome): Asymetric operation (measure one way only), sampled operation.
Xiao Min: Mulitiple STAMP TLVs may not be best choice for this scenario.
Relation between flow label and forwarding path should be monitored.
Rakesh welcomes the idea and proposes joint discussion with (Tianran?)
4 people in the room have read the draft. Interest in adoption: 5 in
favour, 2 against.
Footer Foote: Too early to adopt.
Rakesh: will work on received comments and update the draft.
Giuseppe presents on behalf of the authors. Draft adds 4 additional TLVs
to enable hop by hop measurements.
Info collected at each intermediate node - and then send back by the
reflector. TLVs can be enabled selectively depending on the
requirements.
Frank Brockners: How is STAMP hop-by-hop organised? How should a transit
node reckon a STAMP Ack?How is TLV integrity protection done?
Giuseppe: Security has to be improved.
Greg: Could also be STAMP unauthenticated & HMAC auth.
Greg Mirsky: How will a transit know that it needs to look at the TLV?
Well know ports? Configuration?
Giuseppe: Configuration based.
Greg: We need better description how things would work if there is no
IOAM present.
Wolfgang Beck: Related question, who set's the egress timestamp in
hop-by hop? It's complex to have this in data-plane and not accurate in
control plane?
Giuseppe: Implementation dependent. We'll need to think more about this.
Chairs: Consider security aspects in the next update.
Björn: 2 drafts: Requirements draft and associated measurement draft.
Draft based on BBF TR-452. Can be measured section by section or e2e.
Metric is composable and based on probabilities. Proposed metric is a
measure between QoE and QoS. Result should be a "simple score". An
example is given and community feedback is required. The slides shows a
"good" delay feature (100) and how "bad" (0) would be by a line in a
measured graph. Could be compared to actual measures in a network.
There is an initial implementation available; App for single persons in
Teams, single results can be viewed for joint evaluation. Chrome
extension (search for NetworkXray)
Luis Contreras: Can this also be used to measure the impact of the
endpoint/terminal and intermediate points?
Björn: Yes, as long as you can instrument the endpoint accordingly.
Marcus: What happens if you cross multiple 0-100 lines?
Björn: Right now we just show the worst one. Not the final version
though. Needs more thought.
Madhan Kanagarathinam: no Audio - comment on the list, please.
Tommy: What's the difference or value add as compared to available
responsiveness metrics?
Tommy: The QoO metric is running in background and won't introduce
congestion. Score is also app specific - not like a general network
test.
Stuart: We need to distingish between tools that saturate the network -
and tools that do measurements with very low bitrates. A lot of the
tools that measure by loading the network is basically a representation
of "my network is great if I'm not using it". Bottom line: Understand
what you measure.
Timescales for presentations matter - worst 10s versus a 24h
presentation of results in just a single graph - will present very
different scores.
Chairs: We did an adoption call - and received some feedback. Chairs
consider reopening the adoption call. Please review and provide
feedback.
Giuseppe presents the update. Draft is to provide guidance for a real
world deployment.
Main focus is on manageablity and configuration aspects.
Frank: RFC 8799 is an Individual RFC, no IETF RFC. Frank suggests
writing such a document related to Alternate Marking, rather than
referencing RFC 8799.
Greg: please also specify what "limited domain" means for Alternate
Marking, as there's no general definition of that term.
Giuseppe agrees to both suggestions.
Martin Duke: Is there a data-plane for this?
Giuseppe: Yes. Already existing in IPv6. RFC 9343 (copied from
audio->txt, might be wrong).
4 people in the room have read the draft, chairs will go for WG adoption
call.
Greg presents. Work initially introduced in IETF in San Francisco. One
use case: Set the # of returned packets to 0 - you have one-way
measurement. Authors ask for WG adoption.
Rakesh: Doc is well written and is ready. RFC9503 - explain the
interactions.
Communication with controller, security issue - sender address is
controlled by an ACL, which seems to contradict other text in the draft.
Greg replies, that several methods are possible to ensure that, the text
may reflect different examples.
Wolfgang Beck: Why do we need to add config/control of STAMP to the
protocol, instead of relying on standard management plane procedures
(NC/YANG).
Greg: That's a valid question and a valid alternative "People prefer to
have options"
Wolfgang: There's a security aspect to that too.
Rakesh: This work is mostly suited for stateless reflectors (vs.
stateful reflectors)
Greg: Using the proposed options is similar to SR network programming,
as an analogy.
Xiao Min presents. STAMP over IP/UDP over Geneve (and other options).
Asks for comments. No comments from floor.
Giuseppe presents. YANG data model for alternate marking. Complements
the earlier discussed deployment draft.
Ack that there was an earlier YANG model proposed by a different set of
authors.
Draft follows the same strucutre as the IOAM YANG data model - it is
expected that it would help the implementation. Asks for reviews and for
support of earlier Alternate Marking Co-authors.
Xiao Min: We submitted an earlier draft on the topic.
Chairs propose to merge the efforts. Please make sure that the
author-count is considered when merging.
Chairs ask for a unified approach before considering adoption.
Alexander presents. Proposes to enable aggregation of IOAM data on
forwarding path. Should be done for a limited set of data to enable
forwarding path processing. Introduces suggested TLV.
Chunchi Liu: interesting work. Could support many use-cases.
Frank: this is useful - and has been proposed before. Current approaches
leverage the opaque state snapshot in IOAM. Seemingly there is interest
for a standards approach. Supports the approach.
Alex presents. Extend IPFIX to export flow precision availability
metrics.
Frank: Is there an implementation? Measurement precision is usually
reducing if available resources have to be prioritised.
Greg: Users or externals may define threshoilds and reports may just
cover "values", but judgement can be left to external evaluation.
Thomas Graf: has implemented IPFIX and didn't experience problems when
running into adverse operational conditions.
Ahmed presents. Path tracing in SRv6. Fixed space overhead of 40Byte
(but passed nodes write only parts of that space), processing on
forwarding path, no MTU changes. Several implementations in ASICs.
Greg: SRv6 is scoped?
Ahmed: received a request to extend to IPv6 in general.
Greg: should be generic fo IPv6
Ruediger Geib: There are several proposals in the space for how
intermediate nodes can give feedback. We should harmonize the different
proposals, at least on coding space of identical parameters.
Ruediger would favour IETF WG adoption in Spring (Tommy asked, within
which WG).
Richard Foote: Isn't it that it is already generic. Ahmed responds that
there are some dependencies that are SR specific.