Reported by: Paul Love and Guy Almes
I. Overview and Agenda Bashing
Guy Almes led off with a few opening remarks, along with the usual agenda bash. The agenda was rearranged to accommodate the needs of presenters.
II. Announcement from the Area Director
Guy then introduced Scott Bradner, the 1996-97 Operational Requirements Area Co-Director and 1997-98 Transport Area Co-Director.
Scott announced that IPPM will be split off from BMWG into its own working group and moved from Operational Requirements into the Transport Area. This will require a complete working group charter to be written and approved. Scott will be the Transport Area Co-AD responsible for the new working group. In response to a question, Scott indicated that RTFM will also be moving to the Transport Area.
III. Presentation on NLANR Traffic Measurement Tools
Kim Claffy gave presentations on web traffic and measurement tools.
A. Results on the Nature of Web Traffic
Based on passive observations of user traffic, it appears that:
· Using a time-out value of 60 sec, 65% of flows are web traffic. · Further, 65% of bytes are web traffic. · But only 35% of the packets was web traffic.
Packets per flow were in the range of 14-17. Also, bytes per flow were in the range of about 10K.
Looking at only the web traffic flows, 75% of the documents were GIFs. The Memphis IETF Terminal Room web cache had about a 75% hit rate as of Monday. (This may be a skewed test, since both IETF and FedEx were included and users could avoid cache storage if they wished.)
B. Taxonomy of Measurement Tools
Kim Claffy and Tracie Monk have worked on finding out what measurement tools are available. The current taxonomy of tools is located at: http://www.nlanr.net/Caidants/meastools.html. KC and Tracie would appreciate information both about new tools and about updates on what is already in the list. They would also be interested in thoughts on how best to publish the results from these tools.
Guy Almes led a discussion of ideas leading to a charter for a new IPPM Working Group. We need to submit one now that IPPM will become a separate Working Group.
There are several sets of materials we can use as a starting point. One is part of the current BMWG charter that apply to IPPM. In addition, work was done on an IPPM charter in Spring 1995 before the initial decision was made to fold the IPPM effort into the BMWG. Matt Mathis maintains this and other materials from the Danvers IPPM BOF at http://www.psc.edu/~mathis/IPPM.
Among the deliverable documents, Scott Bradner noted that the Framework document (now in it's second version as an Internet Draft) should be completed and issued as an RFC soon. Guy noted that one more modest turn was required on the Framework, but agreed that it could then be issued as an RFC.
Scott also called for some of the other Internet Drafts (e.g., the Specific Metrics on Connectivity, One-way Delay, and Bulk Transfer Capacity) should also be issued soon as RFCs. Guy noted that, just as protocols are not normally considered done until there are working implementations, so in this case the issuing of RFCs on the specific metrics should await their implementation. He agreed, however, that they should then be issued as RFCs. This is hopeful, for example, since at least two implementations of the One-way Delay metric are in progress. In the case of Bulk Transfer Capacity, an empirical metric based on TReno, the implementation is done (the treno program), but the theoretical work that clarifies the significance of the TReno metric is ongoing.
The Framework and the specific metrics would be issued as Informational RFCs, although there was someone who noted that a BCP document might be appropriate. It was also noted that lessons learned in the course of implementing specific metrics and lessons learned in the course of using the metrics to solve problems would make good additional documents.
Scott noted that the ANSI T1/A1 group is also initiating some work in the Internet performance area. We need to work/coordinate with them. Their plan as specified in the T1/A1 Letter Ballot 596 is: "This project will develop American National Standards relevant to performance specification and allocation to network entities for Internet services offered by public telecommunication service providers in accordance with applicable national and international standards. The project will also develop proposed U.S. contributions on Internet performance to relevant international standards committees. "It is planned that 596 will result in: "Completion of this proposed work program will result in a new American National Standard, provisionally titled 'Telecommunications - Performance Parameters, Objectives, and Measurement Methods for Public Internet Services'." T1/A1 has a web site at http://www.t1.org
Scott commented, "I get calls monthly asking, to paraphrase, 'How bad is the Internet?'". Guy asked whether we should also be writing documents on "How I used the IPPM drafts/RFCs to make a business decision?" Scott noted some good reasons why such a document should not be an official working group product, but several noted that people, particularly from the user community, need to be able to share information on such application. There are heavy constraints, though, on discussing similar issues within the provider community.
Members should expect to see more information on the Charter on the mailing list.
V. Packet Loss Metric Internet Draft
Guy Almes lead a short presentation/discussion on the Packet Loss Metric Draft. The structure and the content of draft parallel that of the One-Way Delay Metric draft discussed in San Jose. Among the issues raised in discussion were the following:
· How will duplicates be handled? The desired outcome would be to measure the time taken for the first instance of the packet to arrive at the destination. Fortunately, this would also be the result of the obvious implementations. · How would out-of-order packets be handled? They would naturally be handled as two different singleton measurements and there is therefore no issue really to be addressed. · How would corrupt packets be handled? (Guy and Vern Paxson had exchanged email on this previously.) Corrupt packets would be treated as lost. Note first that if the IP header is corrupted, then the packet must be discarded. Second, for many implementations, if some fields outside the IP header are corrupted, it may be very clumsy for the implementation to do anything other than discard it. Third, it would be complex and arbitrary to specify in the metric that some corruptions were OK and others not. · Would it make sense to have several different Stream definitions based on the same notion of singleton Packet Loss, but differing on the distribution of time between successive singletons? Guy and Vern together noted that other Streams could be defined, but that many of the obvious alternatives are subject to biases. · At least one implementation of the Packet Loss metric is underway.VI. Update on Vern Paxson's Thesis Research
Vern Paxson gave a report on his Network Probe Daemon (NPD) measurement study. This was mostly an abbreviated version of a talk he gave earlier this year at NANOG, available from: ftp://ftp.ee.lbl.gov/talks/vp-pkt-dyn-nanog97.ps.Z. For IPPM purposes, particularly noteworthy aspects were:
1. Packet filters can suffer from a wide variety of errors, such as drops, additions, and reorderings. 2. Similarly, packet timestamps can exhibit surprising errors in terms of clock adjustments and skew, even if the clocks are synchronized using a protocol such as NTP; 3. Packet reordering, replication, and corruption all occur in the Internet with non-negligible probability, so it pays to consider these possibilities when defining metrics; 4. The loss rates observed by a TCP sender differ considerably from the unconditional loss rates of a network path, because TCP adapts its transmission rate in the face of loss; 5. Using packet-pair for measuring a path's bottleneck (i.e., maximum upper bound) bandwidth can fail in a number of ways, including with arbitrarily large errors in the face of a multi-channel or multi-link path; 6. It may be possible to define a metric for gauging available bandwidth (similar to BTC) based on careful packet timing analysis, rather than by stressing a path to see how much throughput it delivers.VII. Work to be done leading up to the Munich Meeting
Guy led a discussion of working group agenda in the run-up to our Munich meeting.
· We should get the Framework draft out as an Information RFC. · We should get reports from the working group on implementations of any of the currently drafted metrics, including: - Connectivity - One-way Delay - Packet Loss - Bulk Transfer Capacity
We will also be open to "Experience With" Internet Drafts or presentations on lessons learned either implementing or applying any of the metrics.