From tsvwg-admin@ietf.org Mon Jul 3 02:49:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27404 for ; Mon, 3 Jul 2000 02:49:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15853; Mon, 3 Jul 2000 02:36:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15822 for ; Mon, 3 Jul 2000 02:36:50 -0400 (EDT) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27357 for ; Mon, 3 Jul 2000 02:36:49 -0400 (EDT) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.10.0/8.10.0) id e636ahH01866; Sun, 2 Jul 2000 23:36:43 -0700 (PDT) Message-Id: <200007030636.e636ahH01866@daffy.ee.lbl.gov> To: Chris Aston Cc: "'tsvwg@ietf.org'" Subject: Re: [Tsvwg] Status changes of "TCP Congestion Window Validation" In-reply-to: Your message of Fri, 30 Jun 2000 17:25:38 PDT. Date: Sun, 02 Jul 2000 23:36:43 PDT From: Vern Paxson Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org > Can anyone help me understand the reasons behind the status changes of the > "TCP Congestion Window Validation" RFC? > > In the mail to tsvwg of 30 Oct 99 it talks about considering it as a > "Proposed Standard". Then in April 2000 it was approved by the IESG for > publication, but as an "Informational" RFC. Then just a few days ago it was > published as RFC 2861, but as an "Experimental" RFC. > > I guess I've got two questions: > > 1) What was the reasoning behind (and implications of) the status changes in > this RFC? So far I haven't been able to find any email discussion about it. It started off as a candidate for Proposed because we initially thought it would be a non-controversial change. The discussion at the DC IETF brought up a point of contention (what constants to use when decaying the window), and consequently the ADs decided to target it for Experimental. The document was never being considered for Informational - the approval announcement with that status rather than Experimental was an error by the IESG secretariat in the post-Adelaide crunch, which was fixed as soon as it was detected. > 2) More generally, does this mean that it's not possible to assume anything > about the final status of an internet draft ie do you really have to wait > for it to be published by the RFC editor? It will usually have the status for which it's last-called. Documents are sometimes downgraded by the IESG from Proposed to Experimental or Informational, if the technology has some significant problems or unanswered questions, or is critical enough that it's important to encourage experimentation (this is often the case for changes to TCP). Vern _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Thu Jul 20 09:43:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14279 for ; Thu, 20 Jul 2000 09:43:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14901; Thu, 20 Jul 2000 09:36:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14872 for ; Thu, 20 Jul 2000 09:36:26 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10178 for ; Thu, 20 Jul 2000 09:36:25 -0400 (EDT) Received: from guns (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA27627 for ; Thu, 20 Jul 2000 09:36:26 -0400 (EDT) Message-Id: <200007201336.JAA27627@lombok-fi.lerc.nasa.gov> To: tsvwg@ietf.org From: Mark Allman Reply-To: mallman@grc.nasa.gov Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Big Bang Baby Date: Thu, 20 Jul 2000 09:36:26 -0400 Subject: [Tsvwg] new I-D on modified cwnd increase during slow start Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Folks- A week or so ago I submitted the following Internet-Draft: Mark Allman. TCP Congestion Control with Appropriate Byte Counting, July 2000. Internet-Draft draft-allman-tcp-abc-00.txt (work in progress). http://ftp.ietf.org/internet-drafts/draft-allman-tcp-abc-00.txt The document outlines an alternate method for increasing cwnd during slow start called "Appropriate Byte Counting". I have requested a little time to chat about this at the upcoming tsvwg meeting, but I made the request quite late in the game and I haven't heard whether Scott and Allison will have any time available for this topic. But, I wanted to give everyone a heads up on the draft just in case we get to talk about it. And, even if there is no time in tsvwg for this, I'd still like to hear comments in the hall or on the list! Thanks, allman --- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Mon Jul 31 20:23:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14370 for ; Mon, 31 Jul 2000 20:23:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14439; Mon, 31 Jul 2000 20:19:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14411 for ; Mon, 31 Jul 2000 20:19:37 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13904; Mon, 31 Jul 2000 20:19:35 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id RAA14956; Mon, 31 Jul 2000 17:19:35 -0700 (PDT) Message-Id: <200008010019.RAA14956@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-ed@ISI.EDU, tsvwg@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 31 Jul 2000 17:19:35 -0700 From: RFC Editor Subject: [Tsvwg] RFC 2883 on SACK Extension Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2883 Title: An Extension to the Selective Acknowledgement (SACK) Option for TCP Author(s): S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky Status: Standards Track Date: July 2000 Mailbox: floyd@aciri.org, mahdavi@novell.com, mathis@psc.edu, podolsky@eecs.berkeley.edu Pages: 17 Characters: 35794 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-floyd-sack-00.txt URL: ftp://ftp.isi.edu/in-notes/rfc2883.txt This note defines an extension of the Selective Acknowledgement (SACK) Option [RFC2018] for TCP. RFC 2018 specified the use of the SACK option for acknowledging out-of-sequence data not covered by TCP's cumulative acknowledgement field. This note extends RFC 2018 by specifying the use of the SACK option for acknowledging duplicate packets. This note suggests that when duplicate packets are received, the first block of the SACK option field can be used to report the sequence numbers of the packet that triggered the acknowledgement. This extension to the SACK option allows the TCP sender to infer the order of packets received at the receiver, allowing the sender to infer when it has unnecessarily retransmitted a packet. A TCP sender could then use this information for more robust operation in an environment of reordered packets [BPS99], ACK loss, packet replication, and/or early retransmit timeouts. This document is a product of the Transport Area Working Group Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000731171605.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2883 --OtherAccess Content-Type: Message/External-body; name="rfc2883.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000731171605.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg