2.8.18 Transport Area Working Group (tsvwg)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-20

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
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
  • - draft-xiao-tcp-prec-03.txt
  • - draft-ietf-tsvwg-tcp-nonce-04.txt
  • - draft-ietf-tsvwg-addip-sctp-08.txt
  • - draft-ietf-tsvwg-sctpsocket-07.txt
  • - draft-ietf-tsvwg-sctpimpguide-09.txt
  • - draft-ietf-tsvwg-udp-lite-02.txt
  • - draft-ietf-tsvwg-tcp-mib-extension-04.txt
  • - draft-ietf-tsvwg-tcp-eifel-response-04.txt
  • - draft-ietf-tsvwg-prsctp-01.txt
  • - draft-ietf-tsvwg-newreno-01.txt
  • - draft-ietf-tsvwg-dsack-use-02.txt
  • - draft-ietf-tsvwg-highspeed-01.txt
  • - draft-ietf-tsvwg-slowstart-00.txt
  • - draft-ietf-tsvwg-tcp-frto-00.txt
  • Request For Comments:
    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 
    Note taker: Gorry Fairhurst (gorry@erg.abdn.ac.uk)
    Charter Discussion for TCP working group creation (TCPM) (Jon 
    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)
    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)
    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 
    <No comments>
    Reorder/Channel Errors (Sally Floyd for Bhandarkar/Reddy)
    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 
    FAST TCP (Cheng/Low)
    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 
    <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 
    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 
    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)
    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 
    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 
    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 
    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)
    <No presentation - withdrawn from agenda due to author travel glitch>
    IPMP (Matthew Luckie)
    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 
    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 
    RFC1323bis (David Borman)
    This document is well overdue for updating. Important issues need to be 
    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)
    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 
    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)
    <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 
    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)
    <No questions>
    Multi-link Transport (Hosei Matsuoka)
    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 
    Ans: The last hop link is not optimal. Signaling in the wireless link is 
    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 


    Authenticated Chunks for Stream Control Transmission Protocol(SCTP)