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
([email protected]) 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.

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.