Last Modified: 2004-10-18
| 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 |
| 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 |
| 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 |
|
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 ========================================= CHAIRS: Allison Mankin (AM) <mankin@psg.com> Jon Peterson (JP) <jon.peterson@neustar.biz> * Agenda bashing/Notetaker/Intro (chairs) JP: No changes. ------ * RSVP Bandwidth reduction http://www.ietf.org/internet-drafts/draft-polk-tsvwg-rsvp-bw-reduction-00.txt 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? None. AM: I'd like more people to read things. ?: How many people have read the prior version? Few. 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 http://www.ietf.org/internet-drafts/ draft-baker-tsvwg-vpn-signaled-preemption-01.txt 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 http://www.ietf.org/internet-drafts/draft-baker-diffserv-basic-classes-04.txt 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 http://www.ietf.org/internet-drafts/draft-amit-quick-start-03.txt 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? Hummm 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 http://www.ietf.org/internet-drafts/draft-eddy-tlmarch-00.txt 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 http://www.ietf.org/internet-drafts/draft-falk-xcp-spec-00.txt 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 http://www.ietf.org/internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt 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 http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01.txt 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. |