2.8.22 Transport Area Working Group (tsvwg)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-10-18


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:

Jon Peterson <jon.peterson@neustar.biz>

Mailing Lists:

General Discussion: tsvwg@ietf.org
To Subscribe: tsvwg-request@ietf.org
In Body: subscribe email_address
Archive: http://www.ietf.org/mail-archive/web/tsvwg/index.html

Description of Working Group:

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
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 SCTP unreliable transport mode to IESG for consideration as a Proposed Standard
Mar 04  Submit early retransmission to IESG for consideration as Experimental
Mar 04  Submit SCTP Implementer's Guide to IESG for consideration as an Informational RFC
Apr 04  Submit Eifel response to IESG for consideration as a Proposed Standard
Jun 04  ECN Nonce procedure submitted to IESG for consideration as Proposed Standard
Sep 04  Submit ID for SCTP API for consideration as an Informational RFC
Sep 09  TCP-Friendly Variable Rate Control unicast congestion control submitted to IESG for consideration as a Proposed Standard


  • draft-ietf-tsvwg-tcp-nonce-04.txt
  • draft-ietf-tsvwg-addip-sctp-09.txt
  • draft-ietf-tsvwg-sctpsocket-09.txt
  • draft-ietf-tsvwg-sctpimpguide-12.txt
  • draft-ietf-tsvwg-tcp-mib-extension-05.txt
  • draft-ietf-tsvwg-tcp-eifel-response-06.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
    RFC3649 E HighSpeed TCP for Large Congestion Windows
    RFC3708 E Using TCP DSACKs and SCTP Duplicate TSNs to Detect Spurious Retransmissions
    RFC3742 E Limited Slow-Start for TCP with Large Congestion Windows
    RFC3758 Standard SCTP Partial Reliability Extension
    RFC3782 Standard The NewReno Modification to TCP's Fast Recovery Algorithm
    RFC3828 Standard The UDP-Lite Protocol

    Current Meeting Report

    Transport Area WG (tsvwg)

    These notes were kindly and expertly scribed by Gorry Fairhurst.
    Any errors have been edited in by the Chairs, of course.

    TSVWG Wednesday, November 10 at 1530-1730

    Allison Mankin (AM) <mankin@psg.com>
    Jon Peterson (JP) <jon.peterson@neustar.biz>

    * Agenda bashing/Notetaker/Intro (chairs)
    JP: No changes.

    * RSVP Bandwidth reduction
    James Polk

    RSVP sets up reservations based on many properties. Presentation shows how to reduce the bandwidth of an allocated flow. Open issues - what happens if ResvErr is not responded to?

    Aaron: Why RSVP rather than NSIS?
    James Polk: RSVP has running code.
    Fred Baker (FB): NSIS has not chosen to work on these issues.
    AM: What are the issues we need to work on in NSIS?
    FB: Ability to pre-empt, etc.

    JP: How many people have read this ID?
    A few people.
    JP: How many neglected to put their hands up?
    AM: I'd like more people to read things.
    ?: How many people have read the prior version?
    JP: Hum called (among those who had read this).
    There was a substantial hum supporting this proposal to the IESG as a TSVWG work item.

    - -----

    * Wide-Area Network

    Fred Baker (FB)
    Tunnels are common in military networks, and multiple layered tunnels between enclaves are common. There is a real need to do pre-emption here. The problem with RSVP is that you would have to traditionally remove the flow (from a crypto), and all the calls would suffer. Race conditions occur too. We'd be interested in this also being a WG document.
    Joe Touch (JT): In slide 3, you have tunnels over tunnels - and this is something I am familiar with in the Xbone. In the next slide, this layering doesn't appear?
    FB: This diagram is simpler, read the document, it's recursive.
    JT: This has 2 levels?
    FB: Yes, this slide. I am telling you the environment that is the reason for doing what James wants to.

    JP: How many people have read the ID?
    10 or so.
    AM/JP: Would anyone like to support this? Does anyone have views?
    ?: I have not read this, but from what I see, I would support this.
    Jacob: Is the ID in the repository?
    JP: Yes, it's there - see the URL on the list. (There was a line-break in the URL.)

    JP: How do we proceed?
    ?: VPNs are common - both in military and civil nets. RSVP is also becoming more common.
    Aaron Falk (AF): So, here is a process comment: A similar issue came up in the TCPM WG with an ID and there was a small number of supporters - we considered a possibility of getting reviewers to assess and report on the draft, to see if the document was useful to pursue in the group.
    ?2: There are a small set of people building real solutions, and this community will benefit from tackling these issues.
    JT: If there are not that many people interested in this at this meeting, it means the IETF is not involved in the issues.
    AF: Is this informed apathy or ... apathy?
    JT: You're getting a signal that this is not in that interest (so the document could be informational).
    Melissa Shore (MS): I think this is Informational. It's here in tsvwg, because RSVP expertise is here, although what worries me is it is a complex architecture - there is a judgment call on complexity. I'm nervous on IPSsec with different applications and mixing features in a short document - I want many reviewers.
    JP: The IETF is a community of volunteers. Where there is energy, we do work, and help this to become a productive work.
    MS: It's nearly impossible to stop bad work. It shouldn't be this easy to kill good work.
    MS: This merits a WG review and process time.
    Tom Henderson (TH): I'd like to support this - it is an important problem with my company (Boeing). RFCs help prevent peculiar solutions to problems.
    AM: We can work on this problem in TSVWG, but we should ensure the NSIS WG is fully aware of this work.

    Jose Bart (JB): Scott Bradner said that pre-emption was a bad concept, in a previous meeting.
    FB: In this particular case, pre-emption is going to happen: There are important critical (life-saving) cases.
    JT: This work is relevant to a large customer (military).
    AM: Hard pre-emption on a global inter-domain case is a hard problem. Can't we do something at the link-layer to get some of this support? - Implementing inter-domain pre-emption needs to address many problems. We could do several sessions at the IETF on this.
    ?: Should we hold a BoF on pre-emption?
    AM: No. [I think I tried to say because it needs to be cross-area].
    ?: If we go this way, this will in future become an interoperable problem.
    JP: RSVP already supports pre-emption.
    AM: RSVP put pre-emption in where COPS used RSVP in a third-party, policy managed manner - it was not generic.
    Ted: What is the case against doing this?
    JP: The ADs wanted this WG to open-up and do some thinking, we've done this: The can is open now.
    JT: Can we organise a WG meeting for the people who care and avoid the tsvwg getting bogged down.
    JP: I think it is important for these issues to go in front of the people in the tsvwg.
    JP: I'd like to call a hum on doing this work?
    Hum, in favour.


    * Diffserv Basic Classes
    Kok Ho Chan (KC)
    Reviewers comments have been received - and there will be a new rev soon. This document is close to completion - comments are requested from the WG. Should this document be a BCP or INFO (WG or Individual)?

    JP: Opinions please?
    AM: The applications user community was asked for opinions on whether this should become a BCP v. INFO and they will respond to the list.

    JP: The IESG will ask us if the methods in the ID are a required way to do these things: do we need to make this a BCP?
    ?: This draft is well written. Diffserv is being deployed. Can the carriers using DS validate the classes, to make sure this makes sense.
    FB: I've been to a variety of carriers and large enterprises to look at this. The document was valuable to them - no one said they did not want the document.
    David Black: This is a well-written document, all my review comments have been addressed. I don't know if the text is prescriptive or there may be alternative ways of doing this.
    ?: I've been working with people who work with VoIP and knew nothing about the networking aspects, and when shown this, they stopped asking stupid questions...
    JP: It certainly has informational value.
    ?: This is better published as informational, because it defines many classes (a large set could cause confusions).
    We got this feedback in a previous rev. The latest rev says you don't need to support all the classes (you can aggregate several classes to a single treatment).
    Bruce Davie: Even if the text says so, people tend to jump straight to the contents of a table. Publishing as INFO is a good warning to such people.
    JP: I agree with Bruce, the warning text surrounding a table is often loss when people cite a reference - this offers good guidance.
    FB: We would like to prepare another rev.
    JP: Is this next rev suitable for a WG document (as INFO)?
    Humm - in favour of adopting this.


    * Quickstart

    Sally Floyd.
    This draft was previously presented to the WG and expired. A fair amount of work has been done since then, and this is now brought back to tsvwg. Data was presented showing NS behaviour. A case made for using an IP-option.

    JT: Would this be a good mechanism that could also be tied to XCP - so that
    this becomes a mode.
    SF: Quickstart is not a congestion control measure - the use is occasional, normally at the start of a session. Quickstart is good at figuring out what to do in starting conditions. XCP has more parts (and more power).
    JT: If I run Quickstart now, and then later XCP is deployed, we could use the XCP mechanisms with these methods. I'd rather see a single TCP mechanism, if this can be done.
    SF: XCP offers much more info. If you just want a larger initial window, you don't need this info.
    ?: What does change when you do Active Queue Management (AQM)? Oscillation, worse?
    SF: No, there are no complications - You only say yes, if the AQM say there is no standing queue.
    Mark Handley (MH): Could we have a worse than best effort case using diffserv, that would have the same benefit?
    SF: You'd need to know that this code-point was supported, when the host sends.
    MH: If you know this, it should serve the same purpose.
    SF: Lower than best effort has differences.
    ?: Lower than best effort can end up with head-of-line blocking, that would
    cause an impact even with the lower class.

    Gorry Fairhurst (GF): We need to consider tunnels that hide lower layer router behaviours (see earlier talks on VPNs), and it's hard to know what happens in tunnels.
    SF: There are some mechanisms described to help this, if there are problems, tell us.
    GF: Will do, would be useful to talk about on the list.

    JT: Two questions: Is this a Work item for tsvwg? Is it for PS?
    JT: I'm hesitant at going to PS with things that modify TCP. I am in favour of this being Experimental.
    MH: This is an IP change *AND* a transport change - it needs wider review.
    JP: Is this good for a WG work item?
    JP: In favour of proposing this to IESG as a WG Item.
    JP: Is this good for a PS?
    Small Hummm
    JP: In favour of adopting as a PS, so it seems more feasible for taking forward for Experimental.


    * Transport Mobility

    Wesley Eddy (WE)
    This uses existing protocols for mobility using SIP, DNS, etc. Is there room
    for another mobile IP protocol in the IETF?
    Is this good for an Informational document?

    JT: This does not cite any documents from the multi-6 WG, which did review and document why this was not the way to this - because of the shifting-sands problem with lower-layer decisions. This ID conflicts with this.
    WE: Yes, thanks for pointing this out.
    TH: There are issues that need to change things at the transport layer - this keeps coming up - this could be implementation specific, there's also binding issues, do you need a general mechanism?
    ?: There is a (mobile-sctp) ID that describes the case where both end-points are moving at the same time. You need a daemon to scan interfaces. The Transport Layer is normally implemented in the Kernel.
    ?: Transport mobility is cheap to deploy.
    JP: Several action items have been raised, please address these on on the list.


    * XCP

    Aaron Falk
    This is a research project, it is not an intended WG item. There is ns code, web pages, and a mailing list that are open to discuss this topic. XCP uses explicit signaling from XCP routers to find congestion in the network. A feedback loop returns the discovered bottleneck allocation. There is work on fair-sharing with TCP; split connections; etc. This ID is to make the community aware of current work, and invite contributions.


    * SCTP NAT Traversal

    Qiaobing Xie (QX)
    Presentation reviewing guidelines and solutions for dealing with SCTP association transversing NAT and similar middleboxes, and discussing implications of traversing several NATs. Is this a good candidate for an INFO document?

    MS: If you are multi-homed - is a chunk sent on each address?
    QX: No, only once.
    MS: An inter-NAT protocol is really not a good idea.
    QX: This is for future study.
    MS: Just say, "don't do this" rather than "for future study".
    JP: Please also send this to the behave WG (who know and are interested in
    NATs) - you may receive good feedback.


    * RSVP for MPLS-TE
    Francois Le Faucheur (FLF)
    Presentation describing admission control for flows within MPLS Traffic Engineering (TE) tunnels or MPLS Diffserv-aware MPLS Traffic Engineering (DS-TE) Tunnels. The ID discusses aggregation of RSVP end-to-end reservations. Reviewed changes from -00 to -01, including use of a RSVP proxy to aggregate ingress to the tunnel. Open issues were described and will align with Hierarchical LSP work. The authors would like to progress this work in TSVWG. We should send a note to MPLS WG to ensure visibility of this work within TSVWG.

    AM: This (tsvwg) is the place were MPLS and Transport meet. My opinion is that it is right to work on this here. Some clarifications are needed, for different cases, etc. A new rev will help this to be clearer, and then the transport area can better understand the issue. TSVWG'ers please do ASK questions about this.
    ?: I don't understand what RSVP-TE is, and how this relates to RSVP - Since RSVP-TE is not a product of TSVWG.
    JP: No time to answer in the tsvwg meeting...
    ?: What is the difference with TE and DS?
    FLF: The core is an MPLS DS core. MPLS did not create a new QoS mechanism in the data plane.
    ?: This is good work.

    JP: Meeting closed at 17:30.


    RSVP Bandwidth Reduction in TSVWG
    Nested VPNs
    DiffServ Service Classes -04
    Quick-Start for TCP and IP
    An Architecture for Transport Layer Mobility
    XCP: The eXplicit Control Protocol
    SCTP NAT Traversal Considerations