Last Modified: 2003-10-20
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 RFC3517 PS A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP RFC3522 E The Eifel Detection Algorithm for TCP Current Meeting Report
IETF 58 - Monday, November 10 at 0900-1130
==========================================
Transport Area WG (tsvwg) Meeting minutes
CHAIRS: Allison Mankin, AM <mankin@psg.com>
Jon Peterson, JP
<jon.peterson@neustar.biz>
Note taker: Gorry Fairhurst (gorry@erg.abdn.ac.uk)
------------------------
Charter Discussion for TCP working group creation (TCPM) (Jon
Peterson)
JP talked about proposed new charter to allow bug fixes/minor
extensions to TCP and shepherding advancement of TCP documents along
standards track.
tsvwg charter is unchanged by this, remains focussed on tactical,
homeless work.
Q: Is PRSCTP not on the tsvwg charter?
Ans: No, because the new charters do not contain items in final review.
Colin Perkins: Let's be careful the TCPM charter doesn't suck up all the
new research student's papers!
AM: Yes. Large scale issues and major changes (such as FAST) will remain
with tsvwg, that is, where there are wide considerations. The fixes, etc
will go to tcpm.
-------------------------
"Packet Drop" chunk type (Randall Stewart)
http://www.ietf.org/internet-drafts/draf
t-stewart-sctp-pktdrprep-00.txt
Talk about packet loss for satellite link, using a link protocol. For
SCTP, this allows the link to distinguish between packet link loss and
congestion loss.
Matt Mathis: How much does SACK change the results?
Ans: It accounts for most of the difference between TCP and SCTP.
AM: Why didn't you use SACK ?
Ans: We used what we had to hand. SCTP also takes more CPU, but this was not
an issue in the presented results (for 2 Mbps).
JP: Comments to the list please.
-------------------------
Newreno Update (Sally Floyd)
http://www.ietf.org/internet-drafts/draf
t-ietf-tsvwg-newreno-01.txt
Sally Floyd: New Reno has just completed last call. It was now widely
deployed, but still an Experimental STD, so this propose to bring it to
Proposed STD. Added text on FR; Impatient & slow and steady variants; etc.
Mark Allman responded to WG Last call, and this has been
incorporated.
<No comments>
-------------------------
Reorder/Channel Errors (Sally Floyd for Bhandarkar/Reddy)
http://www.ietf.org/internet-drafts/draf
t-bhandarkar-tcp-dcr-00.txt
Sally: This is suggested to come to the meeting for discussion as an
experimental ID.
Comment: There is also a buffering issue (more packets) at the receiver
too. This needs to be taken into the discussion.
Q: There is an issue in that if you are not sending at a high rate, this is
not necessarily a good thing, since it adds delay.
Sally Floyd: Yes and also takes the hit in cwnd reduction.
Q: What's the worse case RTO? - Where is the breakpoint? At what point does
the RTT rise too far, impacting performance?
Ans: The most aggressive RTO is at least twice the PRTT.
Q: Link retransmission can make PRTT become highly variable. How do you
take this into account?
Ans: refer to authors...
John Bennet: If you are only looking at re-odering, this is likely to be on a
timescale that is much less than PRTT.
Sally Floyd: As soon as they see a culmulative ACK, they react to it.
John Bennet: If you knew it was only 20ms of reordering, you may like to
just use this time?
Sally Floyd: There are many papers in this spectrum - this is just one
extreme.
-------------------------
FAST TCP (Cheng/Low)
http://www.ietf.org/internet-drafts/draf
t-jin-wei-low-tcp-fast-01.txt
Should Fast TCP be an IETF Standard (which would be royalty free) or
should it be open to commercialisation? - There's an IPR statement issued
<see slides>.
Scott Bradner: What does the IPR statement do for people who wish to
implement the draft, before it is an IETF STD? How does the IPR work out?
Standards track process is not clear, full standard, etc.
Ans: I don't know the details and logistics of the legal position. The
intention is clear.
Randall Stewart: I work on SCTP, does the IPR also cover SCTP? Would using it
in SCTP violate the patent?
Ans: The current IPR statement applies to TCP.
Scott Bradner: Can we tweak the wording to say all "IETF Congestion
Control" protocols? This constrains it currently to several transport
protocols specified by the IETF, and protects from other uses outside of
this scope (e.g. for specific corporate applications).
Q: If you publish an open Linux source, there are rules for GNU license
that need to be considered.
Ans: We plan to publish the code, the IPR and open source code issues are
different.
<Fast v. Linux Plot>
Q: In this graph did you look at any packet drops?
Ans: Not here.
Q: Do you plan to show a mixture of FAST sharing with Linux and other
TCPs?
Ans: We could show one slide at the end.
Q: So you're saying FAST is not fair to Reno?
Ans: No, we can design for any solution. ...The open issue is how to
select the correct parameters to achieve fairness....
Fred Baker: The simple answer is that Reno will push harder than FAST
because of where the knee is. So FAST gives way to Reno when there is
congestion.
AM: Do the graphs show that FAST is giving way to Reno?
Ans: Not these slides, I do have 1 slide (to show at the end).
Matt Mathis: You didn't say that these results are for a lightly loaded
network, so these are places where Reno does bad for other reasons.
Q: What was the other traffic in the "background traffic" in the
production network results?
Ans: They were likely loaded research networks, we didn't have control of
this background traffic.
<comparison slide not shown, no time remaining>
JP, AM: Let's give this some discussion on the list.
AM: Suggest on list/next time it would be key to show cases with
competing FAST and other TCP.
-------------------------
Link-Up Notification (Spencer Dawkins)
http://www.ietf.org/internet-drafts/draf
t-dawkins-trigtran-linkup-01.txt
Origins of work in PILC WG, and discussion in TrigTran BoF. LinkUp is now a
notification, not a trigger, and it comes from an end host, not a
middlebox. This is now a tsvwg list item.
Comments requested:
Security and Safeness considerations in the draft?
Implementable in TCP?
Interest form other transports
Matt Mathhis: I don't understand where you have a problem: Is this where an
ACK was sent on a link that went down and then was resent? That is, a
duplicate ACK coming back which was the same ACK being sent twice?
Ans: Notification is when you've lost a link for long enough to be in RTO.
Matt Mathhis: If this ACK is a duplicate of an already received ACK, then
the sender RTO timer is not going to be running. If the RTO timer is
running - there's outstanding data in flight. So there's not a problem.
Ans: The situation I'm addressing is relevant to long-latency networks like
GPRS, where a sender can send a fair number of packets that are still
queued for a link when it went down - hence the RTO with a lengthy
backoff.
Mark: Let's talk about this afterwards.
Ans: OK,
Q: Is there an assumption that the link symmetrically goes up and down?
Ans: Either the links go up and down symmetrically, or it's harder to send an
ACK than a data segment, as in GPRS..
Q: Can you have links that revert to half duplex, when they fail?
Ans: Not in the environments I've been working in, but we haven't
considered all environments. This is one of the reasons to ask for input in
TSVWG.
Joe Touch: How long can you hold onto the packet? One router holds it -
another path becomes available, data is exchanged, then the link is
restored
and trigger acts. What happens?
Ans: The proposal does not address this question in this version of
the draft.
Joe Touch: we need also to consider possible insertion of data into the TCP
stream at the wrong point (i.,e. data packets delayed more than one MSL
could be spliced incorrectly into the receive data).
Ans: Some cellular modems have been known to come up after days and send out
queued packets, allsorts of things could happen.
Ans: Some cellular modems have been known to come up after days and send out
queued packets. The proposal does not address this question beyond
current TCP.
Joe Touch: Packets longer than a MSL should be dropped... Can we specify
these devices MUST NOT hold onto packet state for more than the MSL?
Ans: Makes sense, and will be included in the next version of the draft.
Q: Can we get a sense of the applications where this is useful
Ans: We've not characterised all types of links.
AM: Is this TCP-specific really, does it apply to SCTP?
Ans: SCTP seems to be most interested in link-down rather than link-up,
because they have alternate paths that they can use, should a link fail. But
this is our understanding of SCTP from a couple of IETFs back - we're
still interested in hearing if this has changed.
AM: Do we finish this here in tsvwg? Should it be in the new TCPM WG? Is it
ready to be engineered? What other transports is this relevant to?
Mark Handley: DCCP is also interested in link-triggers! It helps to try to
design for the future, not just today's protocols.
Ans: Agree.
Chou: The same issue should also apply to SCTP.
AM: There has been a fair amount of discussion at the IETF. Should this be a
WG item (towards Experimental)?
<Hum taken, and indicated support to do this work. No obvious issues
against this.>
-------------------------
Early Retransmit (Mark Allman)
http://www.ietf.org/internet-drafts/draf
t-allman-tcp-early-rexmt-02.txt
<No presentation - withdrawn from agenda due to author travel glitch>
-------------------------
IPMP (Matthew Luckie)
http://www.ietf.org/internet-drafts/draf
t-mcgregor-ipmp-02.txt
Scott Bradner: This sounds like OAM for TCP?
Ans: Not really,<listed several differences in approach>.
Scott Bradner: I was not meaning to be derogatory, I think OAM can be
useful.
Ans: IPMP is different to the tunnel tracing protocols, for instance.
Scott Bradner: OAM is about finding out what your customers are seeing. You
have similar facilities for the TCP sender (rather than the carrier). It may
be worth looking at the other view, there seems to be so much interest in
OAM these days!
AM: Can people read this ID and send their comments to the list?
Comment: There is some relevant discussions on the IRTF
measurements list.
AM: That is an open list, anyone can see it. Do go to the IRTF list and
look.
-------------------------
RFC1323bis (David Borman)
http://www.ietf.org/internet-drafts/draf
t-jacobson-tsvwg-1323bis-00.txt
This document is well overdue for updating. Important issues need to be
addressed.
Sally Floyd: A non-issue that arises for large windows + timestamps that
arises from the historical way we did things. There's going to be
problems if you don't change the RTO value calculation which was
traditionally (BSD) measured once per PRTT. You can end up using an RTO
calculated only on the last few measurements. A simple fix is to change the
RTO calculation to take it to account the more frequent information that is
available with RTTM.
Ans: Yes, this is a good thing to change, we'll add this to the list.
Chair note: this work would go to the proposed new TCP working group.
-------------------------
Priority Promotion Scheme (Naotaka MORITA)
http://www.ietf.org/internet-drafts/draf
t-morita-tsvwg-pps-01.txt
Q: How is feedback provided on packet drops?
Ans: In the work we use RTCP feedback (based on packet loss).
Q: Looking at Security: how do you prevent a sender from just using a high
priority?
Ans: We use two boxes that monitor the correct behaviour of senders, and
take action.
JP: Can we take a hum on whether there is general interest in doing this in
tsvwg. <hum>
JP: There seems to be rough consensus on doing this in tsvwg.
-------------------------
SCTP Chunk Authentication (Michael Tuexen)
http://www.ietf.org/internet-drafts/draf
t-tuexen-sctp-auth-chunk-00.txt
<bullet 2 on slide about use of IPsec>
Q: Your bullet says an IPsec channel may be used to authenticate control
chunks. Quite what do you mean by this?
Michael Tuexen: I can authenticate an IP packet using IPsec - either all
the packet contents or none of it...However, SCTP packets are made up of a
sequence of packets or chunks. To use IPSEC needs me to look for a
specific packet chunk in the payload. Is this possible? Can IPSEC look
inside a packet?
Comment: This is not possible, now.
Q; Looking at the list of work (replay protection, specs, key
negociation), a lot of this has been done in IPsec. If you use IPsec, you do
have to secure every packet - that's good anyway. So what's the
problem?
Comment : There's a reliance on IP address for IPsec - it's better to fix
IPsec than do something new.
Michael Tuexen: If you do this, you need rekeying.
Comment: Ideally you would split the IP address from the SPI values. If you
know the ID of the sender then this is fine. Is this function used to add an
address? - We don't want a user to see a leaked address and then be given
the ability to hijack the session.
Ans: Yes, that's the case.
Q: How do we then rekey?
Ans: This amounts to lots of work for TLS....
David Black: Extending IPsec is the best action, it makes the work more
worthwhile. We should have a better way to setup the keys. there is a
limit to the volume of information that you can send with one
(manually configured) key, before it becomes a vulnerability
Ans: Yes - let's not replicate work items...
AM: This is a very lively discussion, but we have no time. This should be
taken on the mailing list. Let's take this to the list and discuss the
architecture and issues. It could be exciting.
-------------------------
De-correlated Loss Recovery (Yogesh Prem Swami)
http://www.ietf.org/internet-drafts/draf
t-swami-tsvwg-tcp-dclor-02.txt
http://www.ietf.org/internet-drafts/draf
t-swami-tcp-lmdr-01.txt
<No questions>
-------------------------
Multi-link Transport (Hosei Matsuoka)
http://www.ietf.org/internet-drafts/draf
t-matsuoka-multilink-transport-00.txt
Randall Stewart: In SCTP, we looked into two networks using two
(parallel) paths for SCTP. There are some very difficult scenarios, have you
thought about the effect of where the bottlenecks may be in the
network?
Ans: The last hop link is not optimal. Signaling in the wireless link is
helpful.
Randall Stewart: That's just at the edge. What happens if we have a core
network that adds a bottleneck in the centre of the network? - The
potential scenarios become very significant...
JP: This is really interesting, but we need to take it to the list, we are
out of time.
-------------------------
11:38 Close of
Slides
Authenticated Chunks for Stream Control Transmission Protocol(SCTP)