This session was chaired by Henk Uijterwaal and Matt Zekauskas, and Dave McDysan was the scribe.
AGENDA:
(see slides)
See slide in Agenda.
Look at www.measurementlab.net.
MeasurementLab is soliciting tools from researchers to better understand what is going on in the network between content providers and customers. Researchers should click the link to find out more.
MeasurementLab is a consortium consisting of Google, The New America Foundation, PlanetLab, and 6 researchers that are already involved. It is deploying clusters of servers across world; today four sites are up, and more are on the way.
draft-ietf-ippm-twamp-reflect-octets-01.txt
Al described the new feature, which reflects both in the control and test protocol. It currently relies on the ability to truncate the reflected packet to keep the packet sizes the same in both directions.
Slide 12 has a question for the group, which has been discussed a bit on the list. Should we perform the straightforward translation, that will require trucation, or should we use a new packet format that would place dummy data in the intial packet, to be overwritten in the reflected packet, keeping offsets the same and not requiring truncation. Please read the draft and comment on the list. If there is no consensus for change, the document will go ahead with the straightforward extension.
Matt Z asked if there was feedback from Kaynam Hedayat, or any of the implementors. Al said not yet, but that asking was a good idea.
Al asked who was familiar with the document, about 8 responded. Please read and comment.
draft-ietf-ippm-more-twamp-00.txt
In LC until 31-Mar. The mode registry contained inside is a pre-requisite for extensible features in other drafts.
draft-ietf-ippm-twamp-session-cntrl-01.txt
Murtaza Chiba, co-author and implementer, had planned to present this draft to the group and introduce himself in the process, but he was unable to attend in person. The draft was a result of the TWAMP last call period; it was suggested during last call, but decided that this change should not delay the document publication, and be done as a separate document.
This document allows multiple test sessions to be controlled by a single control connection. It introduces a few new commands. This allows for fast switching between multiple tests.
The authors propose to disallow previous Start/Stop (2,3) commands when this feature is available and selected. What does IPPM want to do? Please respond on the mailing list.
draft-ietf-ippm-framework-compagg-07.txt
Yaakov Stein sent comments to the list on 4-Dec-2008. He was waiting for a reply before sending another round. Al apologized for not getting to this sooner, but will shortly.
No comments from Roman Krzanowski received.
The intent is to resolve comments and queestions and move to last call,.
draft-ietf-ippm-spatial-composition-08.txt
Al described the updates since -07. He also discussed some of the comments, including adding reordering and capacity. Capacity may be straightforward, but hadn't been discussed by the authors. Reordering had been discussed, and it was not clear how composition might work, so it was intentionally not in the draft.
Loki Jorgenson asked what might be done with capacity. At the moment Al prefers to not add anything to the document, and finish what we have. However, they will revisit, and if it looks very straighforward maybe it can go in the document. Loki will review as well.
The next step is to apply Yaakov's comments, and review. He feels the document can be last called shortly after that. The goal is to last call both of these drafts before Stockholm.
draft-ietf-ippm-reporting-03.txt
Matt presented the changes to the document, which were principally made to add references to canonical IPPM metrics. People in the audience were satisfied with how the references were specified, and having them be normative.
The definition of duplicate is slightly different than the working group definition (now in IESG review) and the ITU definition. (It was this reporting draft that inspired the duplicate document in the first place.) It was agreed to fix the definition to match our documents; the version here was an interim version.
Yaakov Stein noted that this definition doesn't differentiate between one packet duplicated 1000 times, or 500 packets duplicated once. This is true, but there are additional metrics in the duplication metric document that does this. There was no consensus in the room to change this (reporting) document.
In the reordering section, the definition here is different either of the definitions in RFC 4737. We should either make it the degree of 1 reordering, or Type-P-Reordering-Ratio-Stream (see Section 4.1 of RFC 4737). Al, Stas, and Yaakov discussed, reaching an agreement to remove duplicate packets from the divisor; we should match an RFC definition. We will take this issue to the mailing list to confirm consensus.
In addition, in the process of adding the references, Matt worked the example by hand. He found a bug in the 1-reordering code used, and that bug is also in RFC 4737. (They were both in non-normative sections.) There were also other C coding errors that cause some anomalous results and some assumptions about removing duplicates. The percentile code might also need to be tweaked. The code here will be fixed. Lars noted that Matt should request errata for the 4737 bug.
draft-morton-ippm-reporting-metrics-06.txt
Al reminded the group that he has a separate document on reporting. He talked about changes (see slides). The idea is to finish the working group draft, and then consider how this one fits.
There was a lot of discussion on how this draft treats lost packets; in particular, it advocates additional delay reporting that treats lost packets separately, allowing the use of maximum delay of packets received, or average delay of packets received.
Stanislav Shalunov advocated consistency with IETF delay defnition, where packets that do not arrive have infinite delay. He thought that if this draft went forward it would effectively depricate the existing delay definition. There was a lot of care in the existing definition, to use infinite delay and not use means. Regardless of sample size, the mean is less robust than median.
Al noted that in practice, many people use conditional distribution; they not when packets are lost, but do define distributions on packets that arrive within the loss timeout. He felt that this makes delay orthogonal to loss. Stas said the use of infinite delays was an important point, not just nit picking, or statistical geekery. There is a long tail there, and the average is substantially less robust than the median. Al then clarified that the assignment of lost packets as infinite delay is an informal practice according to the RFC. They are undefined delay according to the specification, but some have taken the informal practice as the formal specification (which Al contends is not the case).
Yaakov said that from what he read, and from his experience as part of a Europena user group, that he favored counting packets delayed longer than a threshold as lost. But that threshold varied by application. (This is in fact what all the IPPM metrics do.)
draft-duffield-ippm-burst-loss-metrics-00.txt
Al described this as the first of a series of metrics to better specify SLAs. It is very rough, and will be updated soon. (See slides.)
Lars noted that there was IPR on this draft, but he hasn't seen the disclosure. Al noted there are pointers in the draft. However, Lars said there needed to be an additional filing with the secretariat to link them to the draft. Al will follow up.
The WG should read and comment.
(Chairs to introduce, then floor discussion).
[NOTE: Last draft on this subject, now (long) expired:
http://www.watersprings.org/pub/id/draft-bradner-metricstest-03.txt
]
(see slides)
Al Morton said he wanted to volunteer to work on the draft, and he thought the implementation draft was valuable on its own, and reasonable to publish as an independent document. He thought that the information for moving metrics forward was there -- who implemented what, and what was not implemented. The metrics advancement document is important, but the implementation report is useful too.
--Al Morton
See open ITU-T FTP web site listed in slides for details
http://wftp3.itu.int/packet/Mar2009_SG12/
There are a bunch of updates to Y1731 in process. In particular with respect to predicting performance of FECs, performance objectives for Ethernet frameworks, and IP layer capacity framework. Look at the Liaisons, and appendices on the web site.
We are asked to read, and Al welcomes any comments. If you happen to be a member of the ITU, you can also send them directly to the Question 17 list.
There is a bunch of outstanding errata that the ADs have asked us to clear. In particular, there's some for 5357, and some for the original RFCs.
Al said he did look at the 5357 errata, and the majority was valid. He wasn't sure what was supposed to happen next.
Lars said that the RFC Editor has a new web system to file and verify eerrata. As AD, for IESG documents, he can change what was submitted, and validate or reject the errata. Validated errata shows up on the RFC Editor's site, and also in the tools html RFC display. Rejected errata is archived. There is also "hold for document update" -- something that doesn't immediately need to be noted, but should be fixed if the document is updated. Typos go into that catagory, for example.
For documents with TSV WGs, it is up to the chairs to figure out what to do with the help of the document authors. For some, the answer will be obvious, and the WG need not be involved in the decision. For deeper questions, the WG should be involved. Errata that attempts to retroactively change WG consensus should be rejected. The WG chairs inform the ADs, and the ADs edit the errata (if necessary) and mark it approved, rejected, or held for document update.