Transport Area Report - 44th IETF - Minneapolis, MN Working Groups: Audio/Video Transport (avt) The revision of RTP towards draft standard status is proceeding. For the first time, the main RTP spec and the A/V profile are both essentially complete. A companion draft to the RTP spec defining algorithms for sampled storage of SSRC identifiers is ready for WG Last Call at Experimental status, and another draft defining conformance tests for the RTCP scaling algorithms has been completed. The profile now specifies that media encoding names are to be registered in the MIME namespace as was agreed at the previous meeting. However, to do this the profile references a separate draft which specifies the procedure for registering the names and which registers all the names currently listed in the profile. That draft is in rough form and needs to be completed before the RTP profile can be submitted for Last Call. The draft for PureVoice (QCELP) audio payload format is ready for WG last call for Proposed, as will be the RTP MIB after some minor edits and the payload format parity FEC after a revision to the IPR statement; and the Guidelines for Writers of RTP Payload Formats draft is also ready for WG last call at BCP. New payload formats were presented for MP3 audio with improved error resilience compared to RFC2250, and for DV video format. Both were accepted as new WG work items. There was also an initial proposal to add geographical location information to RTCP; this requires additional work to prepare a draft ready for consideration. The draft payload format for MPEG-4 has been completed. At this meeting, and in an evening phone conference call to the MPEG committee meeting in Korea, we discussed how to define MPEG session parameters and initial object descriptors in SDP and how to multiplex several media streams in one RTP packet. The multiplexing topic also applies to other payload formats over RTP. At this meeting we reached consensus to proceed with the Generic RTP Multiplexing (GeRM) proposal as our multiplexing scheme for RTP and to defer the other four proposals until such time as GeRM proves insufficient. Lastly, the WG members were invited to produce additional profiles defining alternative schemes for scaling RTCP for large groups now that the work on timer reconsideration has been completed. This is motivated by the need to reduce multicast routing state. Differentiated Services (diffserv) The first round of standards work has essentially been completed. The framework document will go for one more round of WG comments prior to WG last call. The conceptual model of diffserv router and MIB were not published before this IETF but are promised for Real Soon Now. One traffic conditioner model ("three colour marker") was presented. Early diffserv work in the ATM Forum was summarized, as was the QBONE work on deploying EF. There was a presentation on Linux implementation experience and a presentation on considerations for diffserv on servers (as opposed to routers). Since this is largely an API issue it may not become a WG item. Several other diffserv-related items outside the charter were given mini-slots. IP Performance Metrics (ippm) The WG began with a status report: Connectivity is now Experimental RFC 2498; there are new I-Ds on packet loss patterns and a Treno-specific BTC metric defined within the Bulk Transfer Capacity; comments were (finally) received from T1A1 on the 1-way packet loss and delay metrics, which have been modified to describe the difference in clock terminology between the ITU and IPPM. WG Last Call has been passed for these modifications; at the end of the meeting, after extensive presentation and discussion on the remaining differences between I.380 and the IPPM documents, strong WG consensus agreed we should submit the drafts for IESG consideration. As a first step towards the WG goal of rigorously validating proposed metrics, results of an analysis of several months of side-by-side testing of independent Surveyor and RIPE implementations of the loss and delay metrics were presented (by Henk Uijterwaal). Short reports were given on the Treno BTC draft (by Matt Mathis), the loss pattern draft (by Rajeev Koodli), and the response of the loss and delay drafts to ANSI/ITU comments (by Matt Zekauskas). A new editor was recruited for the IPDV draft (Phil Chemento), as the original author has had to drop out. Will Leland gave a detailed comparison of the ITU I.380 and IPPM approaches to metrics in general and loss & delay in particular. The few non-cosmetic differences generally reflect the different goals of the ITU and the IETF; while some issues can be usefully folded into a future revision of the IPPM Framework document, only one change to the loss and delay I-Ds arose in WG discussion: not to assume apparent transit times are necessarily non-negative. The WG concluded by recapping future directions: - a renewed push on jitter (IPDV), a need for added statistical expertise for developing a BCP on how to validate metrics implementations, - a plea for someone to step forward on multicast metrics (if the WG wishes to address them -- the topic had pretty much died out, but, for example, the BMWG still thinks IPPM is addressing them), - an Informational write-up (first draft by Leland and Zekauskas) relating ITU and IPPM standards documents, and - the completion of the proposed BTC, roundtrip, loss pattern (if consensus is reached that the draft now captures a useful characterization), and jitter documents. IP Telephony (iptel) The iptel working group met for a packed 2.25 hour session. The subject of most of the discussion was the gateway location protocol, which is making progress. There are two proposals for a foundation, one based on BGP (for which Cisco has claimed IPR), and one based on SCSP. The discussion during the meeting yielded minor pros/cons on each side. There was also much discussion on the attributes which are to be propagated, an issue common to both protocols. There has been a lot of discussion on the lists with many new problems and ideas for solutions tossed around. There was continued discussion during the meeting, with consensus on a few of the issues (like scope), but the hardest ones remain. There was also some discussion on the call processing language, the first draft of which was recently released. There are still issues with the framework, and there was only limited discussion of the language itself. The chair believes it is wise to move this work from standards track to experimental, given that it is treading very new ground, and there is no real operational experience. There was continued consensus to keep the first version very simple. There was also a draft on transporting CPL in SIP. Technical issues aside, there was agreement that transport is important, and not limited to SIP. There was consensus that transport should not be addressed in iptel, but rather in the group where the protocol providing transport was developed (i.e., mmusic for SIP, http for http). Integrated Services (intserv) The intserv working group met for one short session at the 44th IETF. Topics discussed were: - a new draft proposing mechanisms needed to enable accurate resource reservation for compressible flows. This draft will eventually define extensions to the current Intserv sender-tspec object. - Consideration of advancement of Intserv specs to draft standard. The consensus of the room was that this may be appropriate soon but not yet. The chair is looking for (and got some) comments about clarity of the current documents as well as an updated implementation survey. Integrated Services over Specific Link Layers (issll) The issll working group met for one session on Wednesday from 1300 to 1500. The topics included: - a last update of the ISSLOW service mappings draft, - an initial discussion of management parameters (a MIB) for the IS802 SBM, and - a series of presentations/discussions about implementing Intserv using diffserv clouds, a new work item. Finally, an informational presentation about dynamic state for Diffserv networks was made. Media Gateway Control (megaco) The Megaco Working Group met for two hours on Monday, March 15, and for another two-plus hours on Tuesday, March 16. In addition a design team met before and after the main meeting on Monday to find a common view of the Media Gateway control protocol. Following on the success of this effort, an editing team met Tuesday and Wednesday to flesh out the agreed position. The editing team expects to present the results as an Internet Draft within a week of the end of IETF 44. The objective of the Megaco sessions was to clarify the requirements which are being captured in our requirements RFC and to make some progress on protocol issues. In the event, we covered the general protocol requirements in extensive detail. We briefly considered requirements relating to ATM transport which had been submitted by the Multi-service Switching Forum (MSF), and were briefed on the latest view of the ETSI TIPHON architecture. The final item of the meeting was a presentation and discussion of the protocol structure agreed to and proposed by the design team. The Working Group is running a month behind on both the Requirements and Protocol RFCs. The Requirements editors currently plan to recycle the latest draft by the beginning of April, with a view to WG last call later in the month. Multicast-Address Allocation (malloc) At IETF 44, the malloc working group discussed several documents: some old (MADCAP, AAP, MASC, Abstract API, and Architecture) and some new (MALLOC MIB, MADCAP Scope Nesting option, and Glop bits). We also discussed updating the group's charter and milestones. The consensus of the group was that we should update the charter to add the MADCAP Scope Nesting option and Glop bits drafts and update the milestones to reflect our plans to bring all working group documents to IETF Last Call by August. Multiparty Multimedia Session Control (mmusic) The MMUSIC WG met once at the 44th IETF, on Wednesday morning 9.00-11.30. The meeting agenda was set up to allow for high bandwidth discussion of the major issues that surfaced on the mailing list since the last IETF. Mark Handley briefly reported that SIP was now published as RFC 2543 and bakeoff will be held in April 99. Jonathan Rosenberg introduced the concept of caller preferences for SIP-based calls. Caller preferences constitute one component of the earlier SIP call control I-D that has been split up, allowing a caller to indicate preferences of where and how to reach a callee (e.g. location, media types, etc.); they are hints to a callee's proxy that may but need not be followed. Steven Donovan introduced the various SIP issues that came up on the mailing list since the last IETF. SIP session timers are found to be needed to allow removal of per-call state in stateful proxies in special cases of call termination. There was substantial discussion but no final conclusion could be reached and so this issue will be taken to the mailing list. A second issue is the proposal to add a new method to SIP called "INFO" to allow carrying ISUP payloads transparently across an IP network. This provoked controversial discussion with very different viewpoints so that this needs to be continued on the mailing list. A third problem identified is how to allow voice feedback from a (PSTN) gateway to be propagated to a SIP endpoint before the "200 OK" response is received. Various proposals have been made on the list which were discussed at the meeting and will continue to be discussed on the list. Finally, a specific multipart encapsulation message format for SIP message bodies was proposed to include an SDP description, an ISUP message part, and e-commerce information -- all of which are optional. It was commonly found that no specific multipart format should be prescribed and rather the generic multipart message format should be used in order not to restrict future extensibility. This rather new item will also require further discussion on the mailing list. Jonathan Lennox gave a brief presentation on the usage of SIP as transport for scripts of the Call Processing Language (CPL). In the meeting of the IPTEL WG a day earlier, it was found that it is not up to IPTEL to define how to carry CPL scripts in any possible transport but rather that the precise mechanism should be left up to the group responsible for designing the transport itself. This was primarily a heads-up presentation for a possible new work item. Finally, the working groups chairs proposed their view on how to deal with SIP-related issues in the context of the MMUSIC WG: generic SIP mechanisms as well as revision/extensions/corrections of the base SIP spec are supposed to be included in MMUSIC, while applications of SIP (such as the PINT profile) are out of scope. A borderline case constitutes IP telephony and related specifications. In any case, the MMUSIC WG, in consultation with the ADs, will decide on a per-case basis whether or not to take up certain tasks, but the aforementioned principles will serve as guidelines. Network Address Translators (nat) WG chairs and ADs had an off-line meeting with Tony Hain and Brian Carpenter to resolve pending issues with the IAB draft on NAT. The revised IAB draft will be a combined IAB/NAT WG draft and will be objective in its tone. Discussion of the revised draft will take place on the mailing list. The NAT terminology draft with the IESG is currently undergoing text and concept clarification and should clear the way for the remaining drafts with the IESG shortly there after. The "NAT complications" draft still needs input and will be redone shortly to be more structured and readable. "NAT friendly design guidelines" draft did not have issues and may be ready to be advanced. As for SNMP-ALG draft, people felt that a strong applicability statement will be required to show situations where the suggested solution will work. Discussion to be moved to mailing list. As for RSIP framework and protocol drafts, some folks felt that it was too generic and needed clarity on its scope - in particular, what needs changing - applications or OS kernel. Lastly, "Relocation through Twice-NAT" was discussed as a mechanism for boot-strapping mobile-IP and questions were raised as to whether such a technique was required in the industry. Network File System Version 4 (nfsv4) The NFSv4 working group met in two sessions at the Connectathon site in San Jose. These sessions were held in lieu of sessions at the IETF meeting in Minneapolis due to the large turnout of NFS engineers at the Connectathon event just one week before the IETF meeting. Brian Pawlowski hosted the first 90 min session which attracted 57 participants (according to the blue sheet). Since many of the participants were not familiar with IETF procedures (indeed, many were not on the mailing list), Brian presented a quick summary of the WG charter and timeline. Spencer Shepler followed with an update on the status of the Requirements document (to be called a Design Considerations Document) and changes to the draft protocol spec. Srini Bharadwaj presented some features that he would like to see in the protocol: bulk handling for multiple files, an attribute that refers to a viewer application, and a file search operation. The consensus of the discussion was that bulk handling could be achieved with compound operations, mime_type attribute could be used to identify a viewer, and a search facility is not usable from any known API. After a break, Brent Callaghan hosted the the second 60 min session, beginning with a summary of caching issues that must be resolved in NFSv4. Rob Thurlow presented an update on the framework for NFSv4 file attributes, and Mike Eisler gave an update on security issues; most notably: the charter requirement for strong security mechanisms to be implemented (some participants expressed concern as to the difficulty in implementing and exporting Kerberos based security). Brian Pawlowski finished with some ideas for support of Replication and Failover within the protocol, in particular, that servers keep a list of alternative locations for replicas. Meeting agenda and slides can be found at http://www.connectathon.org/talks99 ONC Remote Procedure Call (oncrpc) ONCRPC did not meet in Minneapolis. PSTN and Internet Internetworking (pint) PINT did not meet in Minneapolis. RSVP Admission Policy (rap) The framework, base COPS protocol and RSVP extensions for use with it documents have completed RAP and RSVP WG last calls. Framework draft still needs some editorial work based on comments received. RSVP Extensions draft needs some editorial clarifications based on comments received during RSVP WG last call (to be discussed in RSVP WG meeting). Will forward for IETF last call shortly. The working group will be starting work on COPS client MIB. The working group desires to work on simple extensions to COPS base protocol to enable QoS provisioning, particularly of DiffServ routers - this to be driven by requirements from DiffServ and ISSLL WGs and to be closely tied to DiffServ MIB work there. A possible WG charter revision will be worked out shortly. Realtime Traffic Flow Measurement (rtfm) RTFM did not meet in Minneapolis. Resource Reservation Setup Protocol (rsvp) The RSVP WG met once at the Minneapolis IETF. It generally proceeded according to agreements worked out in earlier small-group meetings (quite a few of them, actually). The RAP last call was extended one week. WG last calls were initiated on the integrity, diagnostic, and tunnel drafts. The WG agreed to either termination or (again) going dormant. There will be an interim meeting on either Apr 12 or 26 at Cisco west, to work through the only important open item, the refresh reduction proposals from Berger and Zhang. There may be a final RSVP WG meeting in Oslo to finally dispose of this item. Signaling Transport (sigtran) The SIGTRAN Working Group met on March 16th, with ~180 persons attending. The group reviewed the current draft of the architecture and functional requirements spec, and agreed that current text is stable. A small subgroup was formed to do additional editing later in the week. There was a review of performance requirements for TCAP. Performance requirements are to be documented and more information on hard timeouts added. The group reviewed proposals for a modular protocol framework as a way of supporting the variety of different SCN protocols, and there was general support, with details TBD. Finally, the group reviewed several proposals for a core reliable transport over UDP. In order to proceed, a Design Team was formed to compare and if possible reconcile the different proposals, and to identify any advantages compared against use of TCP. Members are also directed to the work of the SLUMS group, which may address many of the functions that are being considered TCP Implementation (tcpimpl) Tcpimpl did not meet in Minneapolis. TCP Over Satellite (tcpsat) Tcpsat did not meet in Minneapolis. BOFs: Performance Implications of Link Characteristics (pilc) The pilc BOF was held on Thursday March 18 at 9am. Approximately 140 people attended the BOF. Aaron presented some background material on the history of the group and its purpose. Mark Allman quickly reviewed the comments sent to the mailing list since the last IETF, as well the proposed WG charter. Phil Karn gave a quick outline of a document that he is working on regarding the design of link layer protocols that are meant to support Internet traffic. The chairs led a discussion on the scope of the group and the appropriateness of the approach. The consensus of the group seemed to be that the proposed charter was generally sound. Hari Balakrishnan volunteered to work on documents pertaining to asymmetric networks. This will be added to the charter before sending it to the IESG. PSTN/Internet Notification (pin) The pin BOF reached rough consensus that three (3) actions are needed in order to move forward with definition of PIN services and, possibly, a PIN protocol: 1. An Informational RFC, describing proposed PIN services in greater detail, to be completed in two (2) month. 2. Immediately start discussion on the PIN mailing list (ietf-pin@lists.research.bell-labs.com) to define a set of requirements for PIN services. Deadline for the defined set of the requirements is June, 1999. 3. After defining set on requirements PIN community will check whether existing IETF WGs and protocols can be reused (possibly, with slight modification) to satisfy PIN requirements. Findings to be posted on the PIN list by the end of June, 1999. Reliable Multicast Transport (rmt) The BOF explored two fundamental strategies for standardizing reliable multicast: the building-block approach, in which what's standardized are modules or building blocks, and the whole-protocol approach, standardizing whole protocols. Mark Handley first discussed why more than one RM protocol is needed, and ways of partitioning the functionality of different protocols. He then advocated for the building block approach. Issues discussed were whether the IETF has taken such an approach before (yes, for MMUSIC and IP telephony); what are the performance costs; whether first congestion control must be standardized (the ADs believe such standardization can proceed in parallel, instead); and whether in fact the coupling between different functional elements is too strong for building blocks to really work. The advocates for the whole protocol approach (Brian Whetten, Tony Speakman, and an absent Ken Miller, whose slides were presented by Brian) argued that the realities of implementing a full RM protocol are such that it's not at all clear that major pieces of the protocols can in fact be fruitfully decomposed into modules, and market realities are such that a building block approach that fails to take them into account is likely to spend a lot of time on modules that in fact aren't useful. In the ensuing discussion, the sense of the room appeared to be that a hybrid approach, in which some easily separable building blocks such as FEC modules are pursued independently, but the notion of a non-trivial protocol "core" remains, might yield the best balance. Support for Lots of Unicast Multiplexed Sessions (slums) The goal of the BOF was to explore possible transport solutions for addressing a subset of the requirements that came out of the Orlando RUTS BOF. The emphasis was on architectural issues, not specific mechanisms, with the premise that a basic building block is to first address the muxing requirement, ensuring that multiple communications threads between two hosts obey congestion control principles, but doing this in a way that leaves flexibility for later addressing other requirements. Three approaches were presented. First, Srini Seshan and Hari Balakrishnan advocated for the Congestion Manager (CM) described earlier on the mailing list. Two main issues that arose was the overhead of the probe system, and the need to deploy CM at both ends. It was pointed out that the overhead is avoidable if the connections use a feedback-based transport such as TCP, and likewise in that case the CM only needs to be deployed at the sender. Another issue is that the congestion control sharing and probing needs to reflect the diffserv treatment of the connections, which can be difficult to determine. Mike Spreitzer discussed MEMUX, which is a lightweight muxing protocol layered on top of TCP. Because of this layering, MEMUX cannot prevent head-of-line blocking between different communication streams; the main interest in it for SLUMS is as a possible foundation for a muxing API. Venkat Padmanabhan argued for addressing many of the SLUMS goals by sharing congestion control across T/TCP connections, as he previously discussed on the mailing list. The contentious part of his proposal concerned Integrated Loss Recovery, in which packet delivery across different connections is pooled together for purposes of counting duplicate acks to trigger fast retransmission. It was argued that packet reordering can make this much more difficult to get right than one might at first believe. It was also pointed out that this approach cannot support one of the important RUTS requirements, support for failover.