2.8.23 Transport Area Working Group (tsvwg)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-03-04

Chair(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@psg.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@psg.com>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
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:
NOTE: special mailing list for questions related to implementing and using SCTP.

E-mail Address: sctp-impl@external.cisco.com To subscribe: mailer@cisco.com In Body: "subscribe sctp-impl "

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.
Done  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
Done  submit ID on UDP-lite to IESG for consideration as a proposed standard
Done  TCP-Friendly Rate Control (TFRC) unicast congestion control algorithm submitted to IESG for consideration as a proposed standard
Done  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:
  • - draft-xiao-tcp-prec-03.txt
  • - draft-allman-tcp-sack-13.txt
  • - draft-ietf-tsvwg-tcp-nonce-04.txt
  • - draft-ietf-tsvwg-tcp-eifel-alg-07.txt
  • - draft-ietf-tsvwg-addip-sctp-07.txt
  • - draft-ietf-tsvwg-sctpsocket-06.txt
  • - draft-ietf-tsvwg-sctpimpguide-08.txt
  • - draft-ietf-tsvwg-udp-lite-01.txt
  • - draft-ietf-tsvwg-tcp-mib-extension-03.txt
  • - draft-ietf-tsvwg-tcp-eifel-response-03.txt
  • Request For Comments:
    RFCStatusTitle
    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
    RFC3168 PS The Addition of Explicit Congestion Notification (ECN) to IP
    RFC3309 PS Stream Control Transmission Protocol (SCTP) Checksum Change
    RFC3390 PS Increasing TCP's Initial Window
    RFC3436 PS Transport Layer Security over Stream Control Transmission Protocol
    RFC3448 PS TCP Friendly Rate Control (TFRC):Protocol Specification

    Current Meeting Report

    Minutes taken by Spencer Dawkins
    
    ==================================
    Transport Area Working Group TSVWG
    ==================================
    
    Allison Mankin and Jon Peterson
    
    Scott has been replaced by Jon as AD but will still be active
    
    Kireeti - Status of RSVP change document
    	RSVP has become very popular, people outside IETF want to change it
    	this causes difficulties for interoperation - how do we prevent 
    breaking RSVP?
    		recent code points RFC from completely outside IETF with a lot of 
    pushback
    	give RSVP IANA considerations that it's never had before
    		previous considerations draft had expired
    	give three code points (normal use, experimental use, 
    first-come-first-served)
    		really need a "standards action" code point, too
    	also need PS RFC to initiate behavior changes
    	is this important?
    
    	Andy Malis: this is absolutely needed - 
    		IANA is working with no guidelines whatesoever
    		even first-come-first-served space is broken
    		Bob Braden is now the gatekeeper and things are confusing
    	
    	Bob Braden has suggested name-based sand boxes - not much reaction - do 
    people care?
    	Allison: IESG suggested names not reflect owners for 
    maintainability
    
    	Philip Matthews: IS-IS has the same issues 
    		and is dealing with them in the same way
    		Split between class numbers and C-types?
    	
    	will be discussed on TSVWG mailing list
    
    Jukka Manner - Localized RSVP (LRSVP)
    	end-to-end QoS is rarely available
    	backbones fast and reliable
    	access networks are bottleneck congestion points
    	using a small enhancement to RSVP that can coexist with RSVP
    	Local Indication and Expedited Refresh bits allow coexistence
    	Open issues - addressing, asymmetric routing, interworking with 
    end-to-end RSVP, security
    
    	Steve Casner: each end signals its own access network?
    	A: end-to-end is preferable, this is fall-back
    
    	Steve Silverman: is "local" on a LAN?
    	A: "local" access network
    
    	Tom Hiller: 3GPP does things almost identical to this
    		not documented in RFCs because never leaves walled garden
    
    John Bennett - IP measurement OAM problem problem statement
    
    	measure ping, traceroute, etc.
    	can't do this because ot ICMP blocking, flow-specific routes, 
    hop-by-hop vs. end-to-end
    	want to measure increasingly specific things (take HTTP redirect into 
    account, etc)
    	can't figure out which hop is the problem
    	need a new protocol that can be processed in fast path - no control
    	"polite" protocol
    	passes through firewalls, NATs, etc.
    	"IP Measurement Protocol" - IPMP Echo, IPMP Information Request
    		proposed by Andrew McGregor a couple of years ago
    	bennett-00 changes adds redirection, port numbers, TLVs
    	mcgregor-00 and bennet-01 also make changes to previous proposal
    
    	Peter Neuman - would like to measure downstream with standardized 
    protocol
    	Q: also have a draft we'd like to be considered
    	A: looking at general level of interest first	
    
    Sally Floyd - draft-floyd-tcp-highspeed-02.txt
    	Quickstart revision is also out for comments
    	adding a new response function for TCPs on links with very low error 
    rates
    	revision adds discussion of TCP with multiple connections
    		Scalable TCP from Tom Kelly
    	Adds a section on choosing parameters
    	Adds discussion on P-MTU, window scaling, etc.
    	Shows simulation results from Evandro de Souza
    	in a drop-tail queue? would work better with small P
    	Need feedback from community before Experimental RFC
    	Limited Slowstart proposal is also related
    	Other changes? Higher dupack threshold, etc.
    	TCP Quickstart isn't ready to be Experimental RFC - needs more 
    research
    	
    	Allison: what is the complexity?
    	A: maintain a table instead of always cutting in half
    	Eric Nordmark: current reference implementation uses scaled math
    		cutting in half is easy, cutting by 22.9 percent is harder
    	A: could approximate by shifting
    	Matt Mathis: uses integer arithmetic
    	Reiner: why don't smaller congestion windows get to use this?
    	A: need to pick targets for response functions for divergence from 
    standard TCP
    		motivation for picking is that TCP is successful now, so small changes
    	Matt Mathis: Fairness on the Internet is because of standard response 
    function
    		can't let everybody dork with their response function - no fairness
    	Q: Not good at translating from drop rates to technologies
    	A: starting at 10**-6 packet loss rates, High Speed TCP seems to make a big 
    difference
    	Mike from Digital Fountain: have you tried parallel sessions of HSTCP?
    	A: yes, pointed to from web page, so far it looks fine
    		congestion network would be better off if you're using HSTCP
    	Joe Touch: use RSVP for SYN, because we're in slow path anyway
    	A: maybe, but not yet
    	Joe Touch: point solution for 10-gig Ethernet? more dynamic than you're 
    thinking about
    	A: can you talk about this on the list?
    
            hum to adopt as WG item 
    
    Ethan Blanton - draft-blanton-dsack-use-02.txt
    
    	building from Atlanta discussion
    	solved real loss during recovery
    	what do we do now?
    
    	Randall Stewart: perfectly safe, move it forward
    	hum to adopt as WG item
    
    Ethan Blanton 
    draft-blanton-tcp-reordering-00.txt
    
    	can we recover our congestion window?
    	need to prevent massive burst at window reversion time
    	need to prevent spurious fast retransmits
    	presenting four schemes of increasing complexity
    	most conservative scheme is most complexity
    	need more data, would like to hear alternative schemes
    	spurious RTOs is explicitly out of scope
    	Matt Mathis: there are lots of heuristics hidden in real TCPs that will 
    cloud your results
    	Mark Allman: should this sort of algorithm be Experimental? They're 
    conservative
    	Allison: some RFCs are really experiments, some are really for 
    immediate use
    	Sally: Experimental after one real implementation?
    	Allison: We use "experimental" to mean several different things
    	Sally: Texas A&M proposal could be added to this work
    	
    Mark Allman - 
    draft-allman-tcp-early-rexmt-00.txt
    
    	No oppositions based on the list traffic, right?
    	splitting this work out from Limited Transmit
    	less resistent to reordering, but ...
    	Spencer: worse cases are bad in macro sense but effect on user may 
    justify this
    
    Sally Floyd - Proposal for newreno standardization
    	Newreno is widely deployed and is still experimental - move it 
    forward?
    	please identify any major fixes this would require (but not other 
    ideas/changes)
    
    Reiner Ludwig - Redundant data in TCP?
    	TCP-friendly with quotas on good and bad bytes?
    	please feed back to the mailing list
    
    Randall Stewart - 
    draft-stewart-tsvwg-prsctp-03.txt
    
    	Phil Cochran - SCTP bakeoff at UDelaware June 1-8 (unofficial)
    	PR-SCTP has been around for a while - the first service designed by the 
    spec  provides "timed reliability"
    	"abandon" stale chunks of data
    	still make congestion window (downward) adjustments
    	only enabled if both sides understand it!
    	three independent implementations, all interop tested
    	seven additional implementations coming
    
    	Mark Allman: making it easier to throw useless data into the network?
    		should be considered the way we're considering Reiner's proposal
    	Randall: will construct a scenario on the list
    
    	David Black: this is the opposite of Reiner's proposal
    	Randall: better than I could have said it
    
    	Allison: noticed spec made possible to change the lifetime after it was 
    set, suggests interesting race conditions, API complexity in name of 
    flexibility/power...
    	Phil: lots of good issues...
    		agree that if you can change lifetime values, this creates race 
    conditions
    		larger question is about creating lots of new services
    		two parts of proposals - on the wire part is what we need to 
    standardize
    			policy is internal to a node
    	Randall: realistic, can't change this in internal 
    implementations today
    	
    	Mark: more motivation on the list?
    	Randall: unreliable stream didn't simplify anything (per previous 
    connectathon)
    	Mark: couldn't you simplify per-stream, not just per-packet?
    	Phil: good points for application writers, but these are service 
    definition API issues
    	Randall - I could do what you're saying in the current 
    implementation
    	David Black: setting timeouts is valuable in some scenario
    
            Chairs: review to be continued on list.
    

    Slides

    None received.