Last Modified: 2003-03-04
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:
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
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.