Last Modified: 2003-03-04
E-mail Address: firstname.lastname@example.org
To subscribe: email@example.com
In Body: "subscribe sctp-impl
The Transport area receives occasional proposals for the development
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
The tsvwg will serve as the forum for developing these types of
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
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
Request For Comments:
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 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
recent code points RFC from completely outside IETF with a lot of
give RSVP IANA considerations that it's never had before
previous considerations draft had expired
give three code points (normal use, experimental use,
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
Allison: IESG suggested names not reflect owners for
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
can't figure out which hop is the problem
need a new protocol that can be processed in fast path - no control
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
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
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
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
motivation for picking is that TCP is successful now, so small changes
Matt Mathis: Fairness on the Internet is because of standard response
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
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
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
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
Allison: some RFCs are really experiments, some are really for
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 -
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
Sally Floyd - Proposal for newreno standardization
Newreno is widely deployed and is still experimental - move it
please identify any major fixes this would require (but not other
Reiner Ludwig - Redundant data in TCP?
TCP-friendly with quotas on good and bad bytes?
please feed back to the mailing list
Randall Stewart -
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
Phil: lots of good issues...
agree that if you can change lifetime values, this creates race
larger question is about creating lots of new services
two parts of proposals - on the wire part is what we need to
policy is internal to a node
Randall: realistic, can't change this in internal
Mark: more motivation on the list?
Randall: unreliable stream didn't simplify anything (per previous
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
David Black: setting timeouts is valuable in some scenario
Chairs: review to be continued on list.
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.