Justin (slide 3): Trade-off solution proposal for fields and
interoparability. Versioning versus define header fields in IANA
registry. Requesting feedback from the working group.
Greg: The proposal is to give integrity protection to pre-allocated and
incremental option-type header fields. Correct?
Justin: Correct. As for edge-to-edge and proof of transit option-type as
well.
Greg: It would not affect direct export option-type correct?
Justin: Direct export option-type has been excluded in the document.
Greg: Edge-to-edge and pre allocated I can estimate how it looks.
Unclear to me is how it affects incremental where each node adds data.
Justin: It is actually the same process as in proof of transit. The
encapsulation node apply it to part of the header where the transit
nodes add their data, add the integrity protection to the chain.
Greg: No special preference since I care on direct option-type.
Justin: We care about protecting the data not the processing of the
data.
Marcus as a chair: We take the request for WG LC into consideration. As
always, more feedback from the working group would be appreciated.
Sometimes, going to WG LC this can be facilitated.
Greg: I am in favor to keep MPLS in the document. I am confident that
the MPLS working group progress in time. I suggest to split the work in
case IPv6 should progress more quickly.
Rakesh: Exactly. That were also our thoughts.
Tommy: When do we know how many samples are enough? In your example,
1000 seems to be much better then 10 or 100. Probably 1000 is enough.
How do we know that it is not 10'000?
Bjørn: Thats a very good question. It depends on how accurate the
results should be and what types of issues we need to cover. To cover
Wi-Fi is easier than random service outages as they happen rearly with
high spikes.
Tommy: How about show how the results look when enough sample results
are available?
Bjørn: I am not sure wherever this is feasible or not. Less discuss
further.
Tal: Apart from the shared slides, could you make more informations
available later?
Bjørn: Sure. In the shared github link you will find a PDF with more
informations.
Tal: I suggest to add the security considerations section before going
WG LC. Question to chairs: should the document be experimental or
informational?
Marcus as a chair: Given the type of content, informational makes sense
to me.
Tommy as a chair: In general, if experimental, then experiments should
be described, which is here not the case.
Bjørn: I am open for either way. Regarding the security consideration, I
need some help guidance since it is my first document.
David: Does it make sense to pick a single use case application and see
wherever constraint to certain enviroments and topologies wherever the
variables are reduced or not appart from the WI-FI case.
Bjørn: We have more then just the WI-FI case. I will be showing more
scenarios in the MAPRG session tomorrow. Show differences in latency
behaviours.
Varokas: To Tommy's point about how many data points are enough. I
believe there are existing methods such as statistical tests such as
F-Test.
Bjørn: Thats a good point. Devil is in the detail. Latency distributions
are not static. They change over time.
Marcus as a chair: There might be considerations worth mentioning in the
document. We got good feedback. Working group please engage in the
dicussion. We consider to add it to the list of WG LC backlog. An
outreach to the application communities would be appreciated.
Marcus as a chair: Agree. Sounds like a good plan. Looks like you have
the same problem as the previous presentation. There is a group of
people we like to get feedback form and they are not in this room. As
mentioned before, an outreach to the application communities would be
appreciated. Lets discuss offline how this could be approached best.
Bjørn: I think these are good default values. I support the source
buffer management work. I hope that IETF community can take upon.
Stuart: The question in my mind is: We need a venue where people can get
together and discuss on device buffering. It affects transport protocols
and operating systems. The IETF is a good venue to discuss this.
Giuseppe: In the BMWG we are discussing the same problem space. Maybe
Bjørn and Stuart may consider to present at BMWG as well?
Stuart: I am happy to.
Justin: I think it is in scope for IETF. Have you considered the NETDEV
conference as a venue?
Stuart: Good point.
Jason (chat): I also just made an intro for Stuart to the WhatsApp SME
working on low latency - maybe he can look at RPM correlation.
Jason (chat): Also @stuart - maybe present to the STVA's QoE WG - these
are major video streamers. See
https://www.svta.org/working-group/measurement-qoe/ and ping Glenn Deen
if you need help (glenn_deen@comcast.com) - the SVTA Chair
Boris: Support the work.
Greg White: Is this interesting for the IPPM working group?
Greg Mirsky: This kind of work has been brought to the IPPM working
group 7 years ago as part of a TWAMP extension. We need to ensure that
it doesn't brake RFC 3168 and please involve the transport area. ECN set
to non 0 should not be set by the router.
Greg White: Agree that TSVWG should be made aware of. The STAMP session
reflector is not a router.
Marcus/Tommy as a chair: If we do an IPPM adoption call, we can ensure
that it is also sent to TSVWG to obtain that feedback. Greg, if the
TSVWG gives the ok, would it make sense?
Greg Mirsky: Yes, if the TSVWG gives the ok on ECN set to non 0 on STAMP
session reflector, we can explain he relational, then I think we can go
ahead.
Tal: Is it possible that a session refector only reflects the ECN and
DSCP it received, but does not use the DSCP and ECN from the TLV in the
reply it sends?
Greg White: Currently not supported.
Rakesh: We just presented a document where the entire IP header is being
reflected. Have you looked at that?
Greg White: No I haven't. And it appears to resolve previous comment. I
will have a look.
Rakesh: RFC 9503 has return path properties TLV defined. Encoding can
use Sub-TLV for it for return packet DSCP.
Greg White: I have a look at it.
Richard: Take a look at https://datatracker.ietf.org/doc/html/rfc9503
for handling incosistent TLVs.
Greg Mirsky: In order to achieve what Tal asked, a hack could be
facilitated so that the DSCP1 to value not supported by the reflector.
Bjørn: I support the work.
Alex: On the method type, I suggest to add an integrity feature
statement and a if condition for each leaf you are adding.
Justin: It is not shown in this picture, but it is already defined on an
encapsulation node that way.
Alex: Lets clarify offlist.
Rakesh: In the reflecting STAMP packet header draft, we discussed to
split IPv6 and MPLS data plane into separate drafts.
Giuseppe: Correct. This also applies to this document.
Tal: Nice work. Since the draft mentiones ICMP with IPv6 options, there
is an IPv6 document in 6MAN which describes ICMPv6 reflection.
Giuseppe: We will consider.
Marcus as a chair: We take this into consideration for work working
group adoption.
Greg Mirsky: What is the relationship to RFC 9617?
Giuseppe: RFC 9617 only covers the configuration aspect. This module is
related to operational metrics.
Greg Mirsky: The data is orthogonal on how the data is being collected.
I suggest to look at data abstracts and not how it is being collected.
Giuseppe: There are two options. Either create a new YANG module vs.
augmenting an existing.
Greg Mirsky: The STAMP YANG model might be a good example to look at.
Giuseppe: Lets further discuss what is the best approach.
Thomas: There is even a third option. A new YANG module with groupings
which augment existing YANG models.
Giuseppe: Correct.
Bjørn: This is interesting. Are you aware of the quality attenuation
work at the broadband forum? There are data models for path latency
measurements. Might be a different use case.
Giuseppe: I am not sure wherever there is an overlap. I will review.
Maxime: You are exporting the same from direct export, pre allocated and
incremential option-type. Is that correct?
Giuseppe: Correct.
Maxime: I am working on a Linux kernel implementation on direct export
option-type. There might be a need to export also the extension flags.
Such as flow ID and sequence number. There might be a need to do a
distinction between direct export, pre allocated and incremential
option-type.
Giuseppe: Good suggestion. I am already discussing this with Justin on
IPFIX and apply the same here as well.
Marcus as a chair: Will take this also on the list to consider for
working group adoption. However there might be further points to clarify
first.
Giuseppe: Agree. Further discussions are needed before engaging working
group adoption call.
Tal: Most of the data in the trace option type are most likely not
aggregateable. Like node id or hope limit. Correct? You might want to
look at draft-mzbc-ippm-transit-measurement-option.
Alex: Correct. Thanks for the pointer. I will have a look.
Justin: How do I make use of this?
Alex: You are referring to the data field on the bottom I suspect. The
use depends on the aggregate. If you have a comparison aggergator, such
as min or max you can include node id as an aggregator.
Xiao: It is time to extend the IOAM trace option type. There is an
alternative option to extend an existing IOAM option type. Lets discuss
on the mailing list.
Rakesh: In the second option on slide 3, it is expected that the history
of all paths are stored by the PCE to be able to compare the new path.
Correct?
Louis: The PCE doesn't have to be in charge of that. It could be the
monitoring system instead.
Rakesh: It has to consult another entity and judge wherever it is within
the SLO or not.
Bjørn: Thank for bringing this to IPPM. It matches perfectly with the
work we are doing at quiality of outcome. Looking forward to discuss
further.
Thomas as a chair: I was participating OPSAWG yesterday where the chairs
presented this status slide. The document is currently stuck as it
received some push backs. Greg as the shepherd reached out to the IPPM
working group to receive more feedback. I encourage the working group to
give feedback. I wanted to reach out to IPPM to understand wherever
there is interest in this document or not. Personally, I believe it is
valuable to have a document describing aligned terminologies. And I see
that this document is updating RFC 6291 and it extends RFC 7799. I would
like to get some feedback from IPPM: should it further progress or not?
Greg Mirsky: I appricate that Thomas brings this to the IPPM attention.
If this document progresses further, IPPM will be most affected by. I
have a different view how this document relates to RFC 7799. In my
understanding, this document changes terminology of the characteristics
of performance monitoring to something which appears to be rather
artificial and controversial. At the current state, the document is in
limbo. Rather fixing this document, IPPM could colaborate with the OPS
and RTG area and collect existing terms and definitions instead.
Benoit Claise as OPSAWG chair: This is the document OPSAWG adopted. I
was also involved in the sherpeding of the document. I like what Greg
said. The draft is kind of limbo state where the authors lost energy. I
am not speaking on behalf of the authors. Thats what I observed. Do we
have people at IPPM who volunteer and help actively on this document?
This question is aimed to the working group and the IPPM chairs as well.
Greg Mirsky: Who is interested to volunteer, please reach out to the
IPPM mailing list. I am joining the effort iff there is a critical mass
of people interested.
Marcus as a chair: I think thats a good first step. To take it onto the
mailing list and see wherever there is interest or not and take it from
there.