Current Meeting Report
Slides


2.7.20 Transport Area Working Group (tsvwg)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 19-Nov-01
Chair(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>
Transport Area Advisor:
Allison Mankin <mankin@isi.edu>
Mailing Lists:
General Discussion:tsvwg@ietf.org
To Subscribe: tsvwg-request@ietf.org
In Body: subscribe email_address
Archive: ftp://ftp.ietf.org/ietf-mail-archive/tsvwg/
Description of Working Group:
The Transport area receives occasional proposals for the development and publication of RFCs dealing with Transport topics, but for which the required work does not rise to the level where a new working group is justified, yet the topic does not fit with an existing working group, and a single BOF would not provide the time to ensure a mature proposal. The tsvwg will serve as the forum for developing these types of proposals.

The tsvwg mailing list will be used to discuss the proposals as they arise. The working group will meet if there are one or more active proposals that require discussion.

The working group milestones will be updated as needed to reflect the proposals currently being worked on and the target dates for their completion. New milestones will be first reviewed by the IESG. The working group will be on-going as long as the ADs believe it serves a useful purpose.

Goals and Milestones:
Done   Updates to RFC 793 to resolve conflict between diffserv and TCP interpretation of IP Precedence submitted for publication as Proposed Standard
Done   Addition to RFC 2018 to use TCP SACK for detecting unnecessary retransmissions submitted for publication as Proposed Standard
Done   Submit I-D on TCP Congestion Window Validation to IESG for consideration as a Proposed Standard
Done   Submit I-D on Computing TCP's Retransmission Timer to IESG for consideration as a Proposed Standard.
Apr 01   submit revised ID for ECN to IESG for consideration as a proposed standard
May 01   submit ID on TCP framing by a shim to IESG for consideration as a proposed standard
May 01   submit ID on UDP-lite to IESG for consideration as a proposed standard
May 01   TCP-Friendly Rate Control (TFRC) unicast congestion control algorithm submitted to IESG for consideration as a proposed standard
Jun 01   submit ID for adding and deleting addresses from an existing associations in SCTP to IESG for consideration as a proposed standard
Jun 01   submit ID on flow control for individual streams in SCTP to IESG for consideration as a proposed standard
Jun 01   submit ID for SCTP unreliable transport mode to IESG for consideration as a proposed standard
Jun 01   submit ID for SCTP API for consideration as an informational RFC
Jul 01   ECN Nonce procedure submitted to IESG for consideration as
Dec 01   TCP-Friendly Variable Rate Control unicast congestion control submitted to IESG for consideration as a proposed standard
Internet-Drafts:
Request For Comments:
RFCStatusTitle
RFC2861E TCP Congestion Window Validation
RFC2883PSAn Extension to the Selective Acknowledgement (SACK) Option for TCP
RFC2988PSComputing TCP's Retransmission Timer
RFC3042PSEnhancing TCP's Loss Recovery Using Limited Transmit
RFC3168PSThe Addition of Explicit Congestion Notification (ECN) to IP

Current Meeting Report

TSVWG meeting minutes IETF 52

The Transport Working Group had a one-hour meeting in SLC.

Agenda:

Transport update 15 mins
Scott and Allison

SCTP checksum outcome 5 mins
Randall Stewart

Eifel update 15 mins
Reiner Ludwig

TLS over SCTP update 10 mins
Michael Tuexen

TLS/SCTP design tradeoff 15 mins
Tuexen, Eric Rescorla

Brief Summary of Discussions -

Transport update
----------------
Allison and Scott presented a compressed update on both the Area and the working group milestones.

For the Transport Area, we mentioned working groups that were new since IETF 51:
nsis
sipping

A working group that achieved its initial goals and was going to be re-chartered:
midcom

Working groups that have concluded, or will be concluded before IETF 53:
diffserv
issll
malloc
nat
pilc

And BOFs that the area was holding in SLC:
dcp - datagram control protocol
ieprep - internet emergency preparedness
roi - remote dma over internet

For the status of tsvwg milestones:
TCP-friendly rate control -
Completed Last Call for PS. IESG discussion asked for some clarifications.

TCP larger initial window -
Completed Last Call for PS. AD needs to ask for minor changes.

ECN nonce -
We chairs strongly request reviews before we are ready to Last Call.

SCTP addip -
Same request.

U-SCTP -
The draft was withdrawn by a consensus of authors, area advisors, and the ADs. A discussion of the requirements that were envisioned to be met by U-SCTP is intended as the basis for a new working group. The DCP BOF is input to developing a charter.

SCTPbis -
The draft was withdrawn by the authors in favor of the closely scoped SCTP "implementors guide" which publishes changes needed due to errors found in implementation testing.

SCTP checksum change -
Discussion next in agenda.

ULP framing for TCP -
Discussions among the IPS chairs/coordinators/WG (as users of the draft), participants in the chartering discussions about remote DMA (as other potential users), and the ADs have led to a conclusion to consider this draft as Experimental.

UDP lite -
We will complete the action of making this a working group document, based on both the WG consensus from some meetings back, and IESG approval of the charter item (it is in the current charter). Also based on WG discussions of the past and a variety of community reviews, the draft will define a separate protocol number, rather than overloading 17. This is because a mismatch of capabilities can be undetectable otherwise. Stephen Hayes wrote the ADs that 3GPP can use udp-lite equally well if there's a separate protocol number.

Eifel -
Discussion today - reviews strongly needed.

SCTP checksum update
--------------------
The purpose of this was to confirm that the CRC-32c choice for SCTP is thought to have no gotchas, and we will do to WG Last Call on this, to complete most crucial missing piece of SCTP, as soon as the draft is back to us from the authors.

Eifel update
------------
Reiner Ludwig's slides will be found on the TSV area web page.

Review of the draft on the algorithm was strongly encouraged, for proceeding toward WG Last Call.

In the days preceding the meeting, Mark Allman coordinated a Transport directorate review of the issues surrounding bit-based use of Eifel. A discussion was to follow on the tsvwg mailing (see archives).

SCTP and TLS
------------
The purpose of this was to strongly encourage the working group to review the draft. Review questions on the draft for this meeting took the form of objection to cryptographic handshake per stream in SCTP, despite the design in which those handshakes are resumptions of a session, and therefore only refresh the keying material. There was also concern about the requirement that the streams provide ordered data, which is fundamental to the design of TLS (it depends on the sequence number processing by the transport). Eric Rescorla led discussion of the performance feasibility of the session-resumption design. For TLS to allow reordering, and thus be able to have one handshake and session for the whole SCTP session, would entail large changes to TLS. The call for TLS over SCTP was for a solution that did not need TLS-change and could accomodate transaction-based use of SCTP, for instance, that required by Diameter for AAA (cf. draft-ietf-aaa-transport-05.txt). Bernard Aboba expressed support for Diameter to be able to use the current design. Jonathan Rosenberg expressed concern that a future layering of SIP over SCTP (with TLS playing a significant role in SIP security) would be prohibited by the design. Working group consensus was not tested; there needs to be a mailing list push for this deliverable and it should lead to broader review of the applicability issues Jonathan raised.

Slides

None received.