Re: [tcpm] WGLC for Proportional Rate Reduction

Pasi Sarolahti <pasi.sarolahti@iki.fi> Mon, 03 September 2012 06:53 UTC

Return-Path: <pasi.sarolahti@iki.fi>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8386D21F8464 for <tcpm@ietfa.amsl.com>; Sun, 2 Sep 2012 23:53:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.11
X-Spam-Level:
X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mTTi5pzyffI for <tcpm@ietfa.amsl.com>; Sun, 2 Sep 2012 23:53:58 -0700 (PDT)
Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEA121F84A6 for <tcpm@ietf.org>; Sun, 2 Sep 2012 23:53:58 -0700 (PDT)
Received: from [192.168.10.134] (192.76.146.51) by kirsi2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 502AD3600021A17C; Mon, 3 Sep 2012 09:53:57 +0300
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="iso-8859-1"
From: Pasi Sarolahti <pasi.sarolahti@iki.fi>
In-Reply-To: <CAH56bmDV30UMZvmrErT=3fOGMyhM6espLySyzpCT5Vm0qxdzDw@mail.gmail.com>
Date: Mon, 03 Sep 2012 08:54:01 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F115EB6A-0519-46DC-A0E4-83CFE13CEBBD@iki.fi>
References: <59C900CC-E746-4F54-AF2E-12B12D940D3B@iki.fi> <20120827144313.6624729F0A77@lawyers.icir.org> <CAH56bmDV30UMZvmrErT=3fOGMyhM6espLySyzpCT5Vm0qxdzDw@mail.gmail.com>
To: tcpm@ietf.org
X-Mailer: Apple Mail (2.1278)
Cc: Matt Mathis <mattmathis@google.com>
Subject: Re: [tcpm] WGLC for Proportional Rate Reduction
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Sep 2012 06:53:59 -0000

Hi,

We need to move forward with the Proportional Rate Reduction draft. There have been a couple of comments supporting its publication as Proposed Standard rather than Experimental, but on the hand, Matt made some points for keeping with the current status. Therefore, after discussing with my co-chairs, we think the most appropriate path is to continue as planned, and proceed towards publishing the document as Experimental.

There were also some other comments made in response to the WGLC, so the authors should do a revision based on those before we request publication of the draft.

Thanks for your input!

- Pasi


On Aug 27, 2012, at 9:16 PM, Matt Mathis wrote:

> Sorry for the long radio silence here.
> 
> The only reason to bother with standards track is if there is a need
> to compel reluctant manufacturers to implement and deploy it.
> Customers can then write in their requests for quotes specifications
> such as "must support SACK (RFC 2018), and then suddenly the lack of
> SACK support becomes a high priority issue for some large manufacture
> who shall remain nameless.
> 
> Back in the old days (before 1990) RFC meant "request for comments"
> and there was no such concept as "standards track". We wrote down our
> ideas, and if they were valuable, they became part of the installed
> base.   For PRR this has already come to pass for the installed base
> that is most important to me.
> 
> If management at Apple or Microsoft think PRR isn't worth the effort,
> then making PRR a standard will permit their customers to influence
> their priorities.   Given the extent to which PRR is an across the
> board win, I really don't think this is required.  (However, I could
> change my mind if a TCP engineer at one of the above companies
> indicate that they are getting pushback from their management.)
> 
> Finally there are some details in PRR that are effected by Laminar.  I
> would rather not go to the effort of fixing the current draft to make
> it a proper normative PS, but not totally correct.  (Hint: Yoshifumi
> Nishida's "off by one" comment reflects the difference between pipe
> and total_pipe).
> 
> So here is what I was planning to do:  Push out the current document
> as experimental, and then after Laminar is further along, generate a
> normative respecification using Laminar state variables (probably as
> one section of a larger doc, but that remains TBD).
> 
> Does that make sense?
> 
> Thanks,
> --MM--
> The best way to predict the future is to create it.  - Alan Kay
> 
> 
> On Mon, Aug 27, 2012 at 7:43 AM, Mark Allman <mallman@icir.org> wrote:
>> 
>>> I wonder about the process issues related to changing the status at
>>> this point.
>> 
>> The process is that y'all say someone has suggested the status should be
>> standards track and you want to know what the WG thinks of that.  This
>> document has not left the WG.  I have not seen any declaration that it
>> passed WGLC.  It is within this WG's purview to consider this question.
>> 
>> allman
>> 
>> 
>> 
>> 
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>>