NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>
Allison Mankin <mankin@isi.edu>
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/
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.
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 |
· TCP Processing of the IPv4 Precedence Field
· TCP with ECN: The Treatment of Retransmitted Data Packets
· ECN Interactions with IP Tunnels
· The Addition of Explicit Congestion Notification (ECN) to IP
· TCP Friendly Rate Control (TFRC):Protocol Specification
· Robust ECN Signaling with Nonces
· An Open ECN Service in the IP layer
· SCTP Unreliable Data Mode Extension
· Stream Control Transmission Protocol
RFC |
Status |
Title |
RFC2861 |
E |
TCP Congestion Window Validation |
RFC2883 |
PS |
An Extension to the Selective Acknowledgement (SACK) Option for TCP |
RFC2988 |
PS |
Computing TCP's Retransmission Timer |
RFC3042 |
PS |
Enhancing TCP's Loss Recovery Using Limited Transmit |
Transport Area Working Group (tsvwg) Minutes
Wed, Aug 3, 2001 1300-1500pm
Chairs: Scott Bradner and Allison Mankin
Notes were taken by Aaron Falk (many thanks to Aaron).
AGENDA:
Area report and WG status - Chairs
TLS over SCTP - Michael Tuexen
SCTP Checksum - Chairs
ECN nonce - Neil Spring
Datagram Control Protocol - Mark Handley
********************
Area Report: Chairs
No comments or questions. Viewgraphs submitted. Watch for an announcement of the Transport Area web page, which will include HTML versions of our semi-regular area reports :)
********************
Status of TSVWG work: Allison
This discussion referred to the oneline charter, no viewgraphs.
Discussion of current milestones - note that they need to have revised dates. No comments or questions. The chairs drew attention to operative rules:
- working group drafts item should not (in TSV area, must not) be accepted without being in the charter
- charter additions require AD approval
- charter addtions to tsvwg require IESG approval (that is, tsvwg has twelve ADs :)
Chairs appreciate WG feedback on all charter determinations and will try to keep the WG strongly in the loop.
********************
TLS over SCTP Discussion, Michael Tuexen
Viewgraphs submitted.
This draft was added to the WG because of a pressing need for TLS support for SCTP for the AAA WG's Diameter security specification.
It is part of the chartered SCTP effort. (The TLS WG asked for the work not to be done there, as transport mappings were not in their current charter).
Randall Stewart: only a subset of streams use TLS?
A: yes, issue is how do you handle violations
Comment: an additional feature that should be pointed out from SCTP is TTL, should these be only used on non-TLS?
A: yes
********************
SCTP Checksum Discussion, Chairs
No viewgraphs.
Allison: consensus support Sharp draft; seeking remaining dissent and a hum. This will replace specified Adler checksum which has poor properties for small packets. Jonathan Stone, a Stanford doctoral student studying transport checksum issues, has pointed out both on the list and in private, as has Craig Partridge, his advisor, that it's impossible to get perfect protection over an unknown error model, and by nature, transport protocols encounter unpredictable and varied error patterns, in contrast to a layer two protocol over many kinds of single, physical links.
Randall Stewart: are we talking about CRC-32 or ITU CRC-32c? Should get clarification before making a recommendation. Doug: difference is a better protection for jumbo frames. CRC-32c has better protection. IETF recommendation (CRC-32) degrades on jumbo frames.
John Wroclawski: Monday night discussion (and advisory discussion by the TSV Directate) suggested that problem was not explored on list adequately. Recommend further list discussion of some of the new points suggested. E.g., last comment pointing out that error model makes a difference regarding performance of algorithm. There exist lighter weight and better error detection implementations that should be put into the protocol. It's not true that substituting a CRC for a checksum is equivalent.
Scott: there is time pressure to get SCTP out.
Doug Otis: Fletcher 32 has 2% error rate on bus, undermining credibility of checksums as algorithm.
Comment: specify CRC vs. checksum today and close on polynomial later as a way to make progress.
Stewart: Jonathan Stone working with Partridge found 50% of checksum failures due to packet splicing. Moving checksum to end would increase value of checksum. Also recommended changing Adler32. Also, noting that error model in use does not reflect error model in Internet.
Comment: several groups want to know when this issue will solved and whether SCTP is stable and real, etc. Need to get this resolved soon.
Allison: note that SCTP is otherwise stable. The other work is a clarification (the implementors' guide) that makes no changes.
David Black: error model will drive selection of selection of best polynomial. Recommend different polynomial for link use.
Comment: want to see this solved ASAP. If error model is application specific, then solution should not be in Transport but in Application.
Wroclawski: If you do CRC at pkt head, should be sure solution works for big packets.
Black: application specific checksum will drive application specific retransmit which is a bad idea.
Scott: CRC vs. checksum? most hands raised for CRC.
Scott: 32? 32c? talk another week? 32: few hands; 32c and talk: similar numbers. Action: talk on list more to more clear consensus.
Comment: need to be sure solution for jumbo msgs doesn't eliminate use for small msgs.
Stewart: CRC32 or CRC32c protect against internal copy errors in routers. checksums protect against link errors.
Consensus reported: use a CRC, the polynomial to be discussed, including chairs asking for specific mathematical help on
1. is it good/bad/indifferent for the CRC to be the same one as used in Ethernet?
2. is CRC32-whatever fine with both v. large and v. small packets?
********************
ECN Nonce Discussion, Neil Spring
Viewgraphs posted.
Wroclawski: how to say when to set nonce bit?
Christian Huitema: have you thought of load balancing effect with routers that see only half the flow? Would like to see a simulation. A: yes
Matt Mathis: there are several different places where there are bad interactions between DF and other protocols e.g., PAWS. Should document.
A: not clear what should be done?
Allison: should record to document protocol interactions.
Discussion of setting the DF bit per the draft -
Handley: is it reasonable to turn off ECN if you can't do DF? Sally Floyd: this is a good policy question. If you can't set DF then you don't have protection about whether the receiver was lying. Different busy web servers may call it differently. Mark: Does the IETF want to make a recommendation one way or the other? Sally: not necessary at this point to recommend that you don't use ECN unless you can use DF.
KC: Is Nonce a must for ECN? Sally: no, ECN was standardized without it. So, nonce was not a must. (KC = Kacheong Poon?)
Wroclawski: it's not a requirement but it *is* a really good idea and should be encouraged. Does it make sense to use nonce only on low order fragments? Sally: Nonce doesn't give very good protection if you can't set DF. David: text says that reassembly of fragments may not behave well when nonce bit is set differently on fragments.
Scott: ready for last call for standards track or need more opinions? Sally: ready for last call.
Clear show of hands to last call.
Consensus: we will WG last call this for standards track after IETF.
********************
Datagram Control Protocol (DCP) discussion: Mark Handley
Viewgraphs posted.
Wroclawski: does DCP allow for third party cc algorithms? A: yes, a user-specified option exists but in kernel space. Wroclawski: kernel/user space is arbitrary distinction.
Floyd: choice is either to design protocol like this or to encourage implementers to enable UDP users to use ECN. Don't want the latter. Wroclawski: don't want to prevent kernel implementation but don't want to count on it.
Henning Schulzrinne: compared DCP to SCTP and UDP as alternatives, couldn't this also be used to negotiate TCP congestion control algorithms as well? Mark: you can probably do it but may not want to.
Stewart: don't know how to set ECN bit unless you're superuser. USCTP is not right choice for real time apps but it does have limited retransmit.
Comment: DCP give good solution for real time protocol without architectural hacks at RTP or architectural level.
Huitema: most folks no longer look at socket interface when programming networks. DCP appears to be designed with one single rationale: to do a UDP stream with congestion control. Perhaps we should do a requirements analysis before we design a new transport protocol. For example, its necessary to work with firewall and NAT vendors for support. E.g., RTP does much of this but adds time synchronization. Should we add this to DCP? Also, perhaps we should have support for true Transport layer security?
Comment: Merging with RTP is a bad idea because you might want to degrade audio and video seperately in a stream were all the streams are integrated in a single RTP stream.
Jim Renkel, 3COM: I implement multimedia gateways in a dedicated carrier network. RTP is sub-optimal for my applications. Besides, VOIP, Fax-over-IP and Modem-over-IP would be able to use DCP better than RTP. However, RTP has good statistics and time synchronization. These features should be added to DCP. Need to be sure negotiated features and be extended to support this stuff. Also, want to add some ability to support forward error correction. A (Mark): can use RTP over DCP to get extra features. Jim: layering multiple protocols is inefficient and wasteful.
Comment: we're not taking advantage of IP multi-homing. Should be sure to support multi-homing in the features here? Mark: we've been trying to be minimalist and didn't consider it. Might be considerable.
Phil Conrad: tech concern: typically setting up multiple media streams in parallel (video, audio, chat, etc). Do you coordinate ways of having multiple streams sharing congestion state? SCTP can do this. May be duplicating effort with SCTP. Allison: Endpoint congestion manager may address this desire. Note ECM has become a Proposed Standard (RFC 3124).
Wroclawski: it's difficult to deploy new protocols because of a) implementation complexity and b) firewall complexity and other reasons. Because of all the overlaps between different transport protocols, perhaps we should consider moving to an approach of using multiple building blocks that can be combined usefully.
Comment: SCTP may be modified to have negotiable congestion control.
A consensus call was not made but the chairs stated that they did not expect to ask for chartering of DCP work within this working group, but did wish for comments on the general approach for protocols for varied congestion control and variable reliability.
------- End of Forwarded Message
Agenda
TLS over SCTP
Robust ECN Signaling with Nonces: Moving Forward