From nobody Fri Apr 1 07:16:27 2016 Return-Path: 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 B089D12D5AA; Fri, 1 Apr 2016 07:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RFvP2xkuImn; Fri, 1 Apr 2016 07:16:10 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140B712D0F7; Fri, 1 Apr 2016 07:16:10 -0700 (PDT) Received: from 182.178.189.80.dyn.plus.net ([80.189.178.182]:52460 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1alzrr-0006Gl-7O; Fri, 01 Apr 2016 15:16:07 +0100 To: Aaron Falk References: <56C71869.9080503@bobbriscoe.net> <20160219182359.GA74531@verdi> <56CACCB1.2080502@bobbriscoe.net> From: Bob Briscoe Message-ID: <56FE82A5.1090304@bobbriscoe.net> Date: Fri, 1 Apr 2016 15:16:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050708010900050605010608" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: tcpm IETF list , tsvwg IETF list , TCP Prague List , "tsv-ads@ietf.org" , AQM IETF list Subject: Re: [tcpm] [aqm] [tcpPrague] [tsvwg] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 14:16:12 -0000 This is a multi-part message in MIME format. --------------050708010900050605010608 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Aaron, Thanks for reminding me. I completely lost track of doing this back in Feb (typically a symptom of my machine crashing, 'cos my own memory got corrupted years ago). I have requested a room from the secretariat for a 1hr session on Thursday 8 Apr 2016, preferably 9-10am, otherwise 16:20-17:20pm. I'll confirm on these lists as soon as I know. If we get 1st choice, apologies to those who were hoping to enjoy the new relaxed 10am start to IETF meetings The 2nd choice was picked in an attempt to avoid any relevant WG sessions, but it does clash with the fun-packed IAOC Meeting Venue Selection Criteria & Procedures BoF. Cheers Bob On 30/03/16 21:13, Aaron Falk wrote: > Did this get scheduled? > > --aaron > > On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF > > > wrote: > > Just to try to be helpful ... > > On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe > wrote: > > John, > > On 19/02/16 18:23, John Leslie wrote: > > Bob Briscoe > wrote: > > I'm cross-posting 'cos this impacts 3 IETF WGs and > interested implementers. > > We would like to propose a Bar BoF at the Buenos Aires > IETF, about L4S, > DualQ and solutions to the TCP Prague Requirements. > > This feels like it belongs as a non-WG-forming formal BoF. > > It describes work spanning at least three WGs; and > could benefit from > formal scheduling to avoid conflicts with those WGs and > others. > > OTOH, it really isn't to the point where a WG charter > can reasonably > be drafted. First we must decide whether the work _can_ be > split among > existing WGs. > > However this may turn out, I wish to participate remotely. > > OK, we'll see if the secretariat can help us with that. > > > I believe that happens at http://www.ietf.org/meeting/amreq.html. > If you put "TSV" in as "type of meeting", your happy TSV ADs would > see the request. > > Thanks, > > Spencer > > Unfortunately we ran out of time for the formal BoF deadline > on Friday. > > > Bob > > > -- > John Leslie > > > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------050708010900050605010608 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Aaron,

Thanks for reminding me.
I completely lost track of doing this back in Feb (typically a symptom of my machine crashing, 'cos my own memory got corrupted years ago).

I have requested a room from the secretariat for a 1hr session on Thursday 8 Apr 2016, preferably 9-10am, otherwise 16:20-17:20pm.
I'll confirm on these lists as soon as I know.

If we get 1st choice, apologies to those who were hoping to enjoy the new relaxed 10am start to IETF meetings
The 2nd choice was picked in an attempt to avoid any relevant WG sessions, but it does clash with the fun-packed IAOC Meeting Venue Selection Criteria & Procedures BoF.

Cheers



Bob

On 30/03/16 21:13, Aaron Falk wrote:
Did this get scheduled?

--aaron

On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Just to try to be helpful ...

On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
John,

On 19/02/16 18:23, John Leslie wrote:
Bob Briscoe <ietf@bobbriscoe.net> wrote:
I'm cross-posting 'cos this impacts 3 IETF WGs and interested implementers.

We would like to propose a Bar BoF at the Buenos Aires IETF, about L4S,
DualQ and solutions to the TCP Prague Requirements.
    This feels like it belongs as a non-WG-forming formal BoF.

    It describes work spanning at least three WGs; and could benefit from
formal scheduling to avoid conflicts with those WGs and others.

    OTOH, it really isn't to the point where a WG charter can reasonably
be drafted. First we must decide whether the work _can_ be split among
existing WGs.

    However this may turn out, I wish to participate remotely.
 OK, we'll see if the secretariat can help us with that.
I believe that happens at http://www.ietf.org/meeting/amreq.html. If you put "TSV" in as "type of meeting", your happy TSV ADs would see the request.

Thanks,

Spencer
 
Unfortunately we ran out of time for the formal BoF deadline on Friday.


Bob


--
John Leslie <john@jlc.net>

_______________________________________________
tcpPrague mailing list
tcpPrague@ietf.org
https://www.ietf.org/mailman/listinfo/tcpprague

--
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/



_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm




_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------050708010900050605010608-- From nobody Sun Apr 3 00:48:21 2016 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0715A12D1BC for ; Sun, 3 Apr 2016 00:48:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160403074820.2921.74270.idtracker@ietfa.amsl.com> Date: Sun, 03 Apr 2016 00:48:20 -0700 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 07:48:20 -0000 Changed milestone "Submit document on Retransmission Timeout Considerations as Best Current Practice RFC", added draft-ietf-tcpm-rto-consider to milestone. Changed milestone "Submit specification of more accurate ECN feedback in TCP to the IESG for publication as an Experimental RFC", added draft-ietf-tcpm-accurate-ecn to milestone. URL: https://datatracker.ietf.org/wg/tcpm/charter/ From nobody Mon Apr 4 01:35:26 2016 Return-Path: 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 7F14712D19D for ; Mon, 4 Apr 2016 01:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmoVJ6qMPGnN for ; Mon, 4 Apr 2016 01:35:22 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C01412D19B for ; Mon, 4 Apr 2016 01:35:22 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id DA50B6B8F531F for ; Mon, 4 Apr 2016 08:35:18 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u348ZKPf003043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 4 Apr 2016 08:35:20 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u348ZICF010518 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 4 Apr 2016 10:35:19 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.46]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 4 Apr 2016 10:35:19 +0200 From: "Scharf, Michael (Nokia - DE)" To: "tcpm@ietf.org Extensions" Thread-Topic: TCPM document status Thread-Index: AdGOTOrYRiRhZRstQGy2q/hiwtyTZw== Date: Mon, 4 Apr 2016 08:35:19 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4876DA22@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] TCPM document status X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 08:35:24 -0000 Hi all, Please find below a short summary of the status of the TCPM WG. Please let us know any comments or suggestions. Thanks Yoshi, Pasi, Michael TCPM chairs TCP Maintenance and Minor Extensions (TCPM) Working Group Status of documents =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Recent RFCs * draft-ietf-tcpm-rtorestart - published as RFC 7765 WG Documents (Post WGLC) * draft-ietf-tcpm-undeployed - in RFC Editor queue WG Documents (Active) * draft-ietf-tcpm-rfc793bis - New version with minor updates has been submitted (2016-03-21) * draft-ietf-tcpm-tcp-edo - Not much mailing list discussion recently - Implementer feedback would be very useful * draft-ietf-tcpm-dctcp - Reviews needed, charter milestone is Dec. 2015 * draft-ietf-tcpm-cubic - New version has been submitted (2016-01-18) - Good recent mailing list discussion * draft-ietf-tcpm-accurate-ecn=20 - Initial WG document submitted (2015-12-14) =09 * draft-ietf-tcpm-rto-consider - Relatively stable document, close to WGLC From nobody Tue Apr 5 05:03:04 2016 Return-Path: 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 03F4412D532; Tue, 5 Apr 2016 05:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRAsEX6mIOd8; Tue, 5 Apr 2016 05:02:58 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5DC512D1E1; Tue, 5 Apr 2016 05:02:53 -0700 (PDT) Received: from dhcp-b315.meeting.ietf.org ([31.133.179.21]:48593) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1anPh2-0006vZ-Rc; Tue, 05 Apr 2016 13:02:50 +0100 To: Aaron Falk , Spencer Dawkins at IETF , Mirja Kuehlewind References: <56C71869.9080503@bobbriscoe.net> <20160219182359.GA74531@verdi> <56CACCB1.2080502@bobbriscoe.net> From: Bob Briscoe Message-ID: <5703A963.6090306@bobbriscoe.net> Date: Tue, 5 Apr 2016 13:02:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------060501040200060605040004" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: tcpm IETF list , tsvwg IETF list , "tsv-ads@ietf.org" , TCP Prague List , AQM IETF list Subject: Re: [tcpm] [aqm] [tcpPrague] [tsvwg] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 12:03:02 -0000 This is a multi-part message in MIME format. --------------060501040200060605040004 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Folks, We have a time and room for this Bar BoF: Date/time: 09:00 - 10:00 ART (= 12-13:00 UTC) Thu 7 Apr 2016 Room: Quebracho B We have the regular IETF remote attendance facilities in that room. The room is not being used for the following session, so we don't have to vacate early. We're building the agenda - will send shortly. We want to allow most time for people to talk from the floor. The general structure will be: * Introduction/Background * Clarification Questions * Recent Activity: Design / Evaluation / Industry * Build a standardisation roadmap * Build a BoF for the Berlin timeframe, and should it be non-WG forming. * Discussion / Q&A Sorry for delay setting this up. My fault. I've bcc'd a few people who have been asking about this specifically. Bob On 30/03/16 21:13, Aaron Falk wrote: > Did this get scheduled? > > --aaron > > On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF > > > wrote: > > Just to try to be helpful ... > > On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe > wrote: > > John, > > On 19/02/16 18:23, John Leslie wrote: > > Bob Briscoe > wrote: > > I'm cross-posting 'cos this impacts 3 IETF WGs and > interested implementers. > > We would like to propose a Bar BoF at the Buenos Aires > IETF, about L4S, > DualQ and solutions to the TCP Prague Requirements. > > This feels like it belongs as a non-WG-forming formal BoF. > > It describes work spanning at least three WGs; and > could benefit from > formal scheduling to avoid conflicts with those WGs and > others. > > OTOH, it really isn't to the point where a WG charter > can reasonably > be drafted. First we must decide whether the work _can_ be > split among > existing WGs. > > However this may turn out, I wish to participate remotely. > > OK, we'll see if the secretariat can help us with that. > > > I believe that happens at http://www.ietf.org/meeting/amreq.html. > If you put "TSV" in as "type of meeting", your happy TSV ADs would > see the request. > > Thanks, > > Spencer > > Unfortunately we ran out of time for the formal BoF deadline > on Friday. > > > Bob > > > -- > John Leslie > > > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------060501040200060605040004 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Folks,

We have a time and room for this Bar BoF:
Date/time: 09:00 - 10:00 ART (= 12-13:00 UTC) Thu 7 Apr 2016
Room: Quebracho B

We have the regular IETF remote attendance facilities in that room.
The room is not being used for the following session, so we don't have to vacate early.

We're building the agenda - will send shortly.
We want to allow most time for people to talk from the floor.

The general structure will be:
* Introduction/Background
* Clarification Questions
* Recent Activity: Design / Evaluation / Industry
* Build a standardisation roadmap
* Build a BoF for the Berlin timeframe, and should it be non-WG forming.
* Discussion / Q&A

Sorry for delay setting this up. My fault.
I've bcc'd a few people who have been asking about this specifically.


Bob

On 30/03/16 21:13, Aaron Falk wrote:
Did this get scheduled?

--aaron

On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Just to try to be helpful ...

On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
John,

On 19/02/16 18:23, John Leslie wrote:
Bob Briscoe <ietf@bobbriscoe.net> wrote:
I'm cross-posting 'cos this impacts 3 IETF WGs and interested implementers.

We would like to propose a Bar BoF at the Buenos Aires IETF, about L4S,
DualQ and solutions to the TCP Prague Requirements.
    This feels like it belongs as a non-WG-forming formal BoF.

    It describes work spanning at least three WGs; and could benefit from
formal scheduling to avoid conflicts with those WGs and others.

    OTOH, it really isn't to the point where a WG charter can reasonably
be drafted. First we must decide whether the work _can_ be split among
existing WGs.

    However this may turn out, I wish to participate remotely.
 OK, we'll see if the secretariat can help us with that.
I believe that happens at http://www.ietf.org/meeting/amreq.html. If you put "TSV" in as "type of meeting", your happy TSV ADs would see the request.

Thanks,

Spencer
 
Unfortunately we ran out of time for the formal BoF deadline on Friday.


Bob


--
John Leslie <john@jlc.net>

_______________________________________________
tcpPrague mailing list
tcpPrague@ietf.org
https://www.ietf.org/mailman/listinfo/tcpprague

--
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/



_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm




_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------060501040200060605040004-- From nobody Tue Apr 5 05:58:40 2016 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF9112D5C9; Tue, 5 Apr 2016 05:58:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160405125837.25935.67768.idtracker@ietfa.amsl.com> Date: Tue, 05 Apr 2016 05:58:37 -0700 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rto-consider-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 12:58:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions of the IETF. Title : Retransmission Timeout Considerations Author : Mark Allman Filename : draft-ietf-tcpm-rto-consider-02.txt Pages : 7 Date : 2016-04-05 Abstract: Each implementation of a retransmission timeout mechanism must balance correctness and timeliness and therefore no implementation suits all situations. This document provides high-level guidance for retransmission timeout schemes appropriate for general use in the Internet. Within the guidelines, implementations have latitude to define particulars that best address each situation. Terminology The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rto-consider-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 6 16:44:31 2016 Return-Path: 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 3F8A212D6BA; Wed, 6 Apr 2016 16:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 462U04aHfEdD; Wed, 6 Apr 2016 16:44:19 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA5512D612; Wed, 6 Apr 2016 16:44:18 -0700 (PDT) Received: from dhcp-b315.meeting.ietf.org ([31.133.179.21]:51398) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1anx7M-0006Ql-FL; Thu, 07 Apr 2016 00:44:14 +0100 References: <56C71869.9080503@bobbriscoe.net> <20160219182359.GA74531@verdi> <56CACCB1.2080502@bobbriscoe.net> <5703A963.6090306@bobbriscoe.net> From: Bob Briscoe To: tcpm IETF list , tsvwg IETF list , TCP Prague List , AQM IETF list Message-ID: <57059F43.1050406@bobbriscoe.net> Date: Thu, 7 Apr 2016 00:44:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5703A963.6090306@bobbriscoe.net> Content-Type: multipart/alternative; boundary="------------010603060201010808070705" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: "tsv-ads@ietf.org" Subject: Re: [tcpm] [aqm] [tcpPrague] [tsvwg] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 23:44:22 -0000 This is a multi-part message in MIME format. --------------010603060201010808070705 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Folks, Reminder, agenda & supporting materials below for the Bar BoF on L4S / DualQ Coupled AQM / TCP Prague *Event details** *Date/time: 09:00 - 10:00 local time (ART = 12-13:00 UTC) Thu 7 Apr 2016 Room: Quebracho B *Supporting materials / background:** *https://riteproject.eu/dctth/ To use the time effectively, it will be assumed that people have a working knowledge of what the technology is, and a rough idea of how it works. For those wanting an introduction, a useful 2-pager in the IETF Journal is linked from the above, plus videos of the demos etc.b Or chat with us afterwards *Proposed Agenda:** ***09:00 * Note Well, Agenda Bashing [Bob] * Introduction/Background (very brief) [Bob] * Clarification Questions 09:15 * Status updates [Koen to lead], e.g.: - what people are doing on parts of the problem: - planned work - evaluation work - interest in implementing - willingness to review 09:40 * Build a standardisation roadmap [Bob to lead] * Build a BoF for the Berlin time-frame - should it be non-WG forming? - volunteers to help with organisation / writing problem statement, etc. - which mailing list? - what name? * Discussion / Q&A 09:55 end Most time will be allowed for people to talk from the floor. Cheers Bob & Koen On 05/04/16 13:02, Bob Briscoe wrote: > Folks, > > We have a time and room for this Bar BoF: > Date/time: 09:00 - 10:00 ART (= 12-13:00 UTC) Thu 7 Apr 2016 > Room: Quebracho B > > We have the regular IETF remote attendance facilities in that room. > The room is not being used for the following session, so we don't have > to vacate early. > > Sorry for delay setting this up. My fault. > I've bcc'd a few people who have been asking about this specifically. > > > Bob > > On 30/03/16 21:13, Aaron Falk wrote: >> Did this get scheduled? >> >> --aaron >> >> On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF >> wrote: >> >> Just to try to be helpful ... >> >> On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe >> wrote: >> >> John, >> >> On 19/02/16 18:23, John Leslie wrote: >> >> Bob Briscoe > > wrote: >> >> I'm cross-posting 'cos this impacts 3 IETF WGs and >> interested implementers. >> >> We would like to propose a Bar BoF at the Buenos >> Aires IETF, about L4S, >> DualQ and solutions to the TCP Prague Requirements. >> >> This feels like it belongs as a non-WG-forming formal >> BoF. >> >> It describes work spanning at least three WGs; and >> could benefit from >> formal scheduling to avoid conflicts with those WGs and >> others. >> >> OTOH, it really isn't to the point where a WG charter >> can reasonably >> be drafted. First we must decide whether the work _can_ >> be split among >> existing WGs. >> >> However this may turn out, I wish to participate >> remotely. >> >> OK, we'll see if the secretariat can help us with that. >> >> >> I believe that happens at http://www.ietf.org/meeting/amreq.html. >> If you put "TSV" in as "type of meeting", your happy TSV ADs >> would see the request. >> >> Thanks, >> >> Spencer >> >> Unfortunately we ran out of time for the formal BoF deadline >> on Friday. >> >> >> Bob >> >> >> -- >> John Leslie > >> >> _______________________________________________ >> tcpPrague mailing list >> tcpPrague@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpprague >> >> >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> >> >> >> >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ --------------010603060201010808070705 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Folks,

Reminder, agenda & supporting materials below for the Bar BoF on L4S / DualQ Coupled AQM / TCP Prague

Event details
Date/time: 09:00 - 10:00 local time (ART = 12-13:00 UTC) Thu 7 Apr 2016
Room: Quebracho B

Supporting materials / background:
https://riteproject.eu/dctth/
To use the time effectively, it will be assumed that people have a working knowledge of what the technology is, and a rough idea of how it works.
For those wanting an introduction, a useful 2-pager in the IETF Journal is linked from the above, plus videos of the demos etc.b
Or chat with us afterwards

Proposed Agenda:
 09:00
* Note Well, Agenda Bashing [Bob]
* Introduction/Background (very brief) [Bob]
* Clarification Questions
09:15
* Status updates [Koen to lead], e.g.:
  - what people are doing on parts of the problem:
  - planned work
  - evaluation work
  - interest in implementing
  - willingness to review
09:40
* Build a standardisation roadmap [Bob to lead]
* Build a BoF for the Berlin time-frame
   - should it be non-WG forming?
   - volunteers to help with organisation / writing problem statement, etc.
   - which mailing list?
   - what name?
* Discussion / Q&A
09:55 end

Most time will be allowed for people to talk from the floor.

Cheers


Bob & Koen

On 05/04/16 13:02, Bob Briscoe wrote:
Folks,

We have a time and room for this Bar BoF:
Date/time: 09:00 - 10:00 ART (= 12-13:00 UTC) Thu 7 Apr 2016
Room: Quebracho B

We have the regular IETF remote attendance facilities in that room.
The room is not being used for the following session, so we don't have to vacate early.

Sorry for delay setting this up. My fault.
I've bcc'd a few people who have been asking about this specifically.


Bob

On 30/03/16 21:13, Aaron Falk wrote:
Did this get scheduled?

--aaron

On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Just to try to be helpful ...

On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
John,

On 19/02/16 18:23, John Leslie wrote:
Bob Briscoe <ietf@bobbriscoe.net> wrote:
I'm cross-posting 'cos this impacts 3 IETF WGs and interested implementers.

We would like to propose a Bar BoF at the Buenos Aires IETF, about L4S,
DualQ and solutions to the TCP Prague Requirements.
    This feels like it belongs as a non-WG-forming formal BoF.

    It describes work spanning at least three WGs; and could benefit from
formal scheduling to avoid conflicts with those WGs and others.

    OTOH, it really isn't to the point where a WG charter can reasonably
be drafted. First we must decide whether the work _can_ be split among
existing WGs.

    However this may turn out, I wish to participate remotely.
 OK, we'll see if the secretariat can help us with that.
I believe that happens at http://www.ietf.org/meeting/amreq.html. If you put "TSV" in as "type of meeting", your happy TSV ADs would see the request.

Thanks,

Spencer
 
Unfortunately we ran out of time for the formal BoF deadline on Friday.


Bob


--
John Leslie <john@jlc.net>

_______________________________________________
tcpPrague mailing list
tcpPrague@ietf.org
https://www.ietf.org/mailman/listinfo/tcpprague

--
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/



_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm




_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------010603060201010808070705-- From nobody Thu Apr 7 02:55:37 2016 Return-Path: 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 223EE12D117 for ; Thu, 7 Apr 2016 02:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_lSzY3TMK9S for ; Thu, 7 Apr 2016 02:55:35 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4AF12D0DC for ; Thu, 7 Apr 2016 02:55:35 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 72B1835A986BC; Thu, 7 Apr 2016 09:55:31 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u379tUTk026319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Apr 2016 09:55:32 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u379tN41028904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Apr 2016 11:55:30 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.46]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 7 Apr 2016 11:55:23 +0200 From: "Scharf, Michael (Nokia - DE)" To: "mallman@icir.org" Thread-Topic: Applicability of draft-ietf-tcpm-rto-consider-02 to non-IETF protocols Thread-Index: AdGQs5nMLAfVLbPZRdSnoeQUvIu3RQ== Date: Thu, 7 Apr 2016 09:55:23 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48780E7F@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: [tcpm] Applicability of draft-ietf-tcpm-rto-consider-02 to non-IETF protocols X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 09:55:37 -0000 I have read -02 and I have run into an issue with the new text therein.=20 I think we should ensure that the content of this document is applicable to= protocols that run over the Internet but that are not standardized by the = IETF. For instance, UDP-based gaming protocols would come into my mind. I think the current wording in -02 is overly restrictive: An exception is made to this rule if an IETF standardized mechanism is used to determine that a particular loss is due to a non-congestion event (e.g., packet corruption). I think it is sufficient to have a mechanism to detect non-congestion event= s. To me, it does not matter whether this mechanism is standardized by the = IETF. The standardization may not even be possible if that mechanism is tig= htly tied into a non-IETF protocol. Also, "standardization" seems to exclud= e informational/experimental RFCs and I am not sure if I agree that they sh= ould be excluded here. The following wording also seems to implicitly assume that IETF standards a= re used as basis of a protocol: A non-goal of this document is to in any way specify individual deviations from current IETF standardized RTO specifications that any particular implementation may exhibit. Rather, we provide a set of over-arching guidelines that all RTO mechanisms should follow. This wording makes sense for TCP. But, again, I'd prefer a wording that app= lies to all protocols running over the Internet no matter whether the proto= col mechanics use IETF standards as basis, or not. Michael (with chair hat off) From nobody Thu Apr 7 03:45:04 2016 Return-Path: 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 C682312D105; Thu, 7 Apr 2016 03:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCQBy0mWCunQ; Thu, 7 Apr 2016 03:44:57 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33B1B12D09C; Thu, 7 Apr 2016 03:44:57 -0700 (PDT) Received: from [201.250.51.33] (port=25661 helo=[192.168.1.54]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1ao7Qk-0002IU-Ci; Thu, 07 Apr 2016 11:44:55 +0100 To: tcpm IETF list , tsvwg IETF list , TCP Prague List , AQM IETF list References: <56C71869.9080503@bobbriscoe.net> <20160219182359.GA74531@verdi> <56CACCB1.2080502@bobbriscoe.net> <5703A963.6090306@bobbriscoe.net> <57059F43.1050406@bobbriscoe.net> From: Bob Briscoe Message-ID: <57063A22.2010709@bobbriscoe.net> Date: Thu, 7 Apr 2016 11:44:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <57059F43.1050406@bobbriscoe.net> Content-Type: multipart/alternative; boundary="------------040709030009070906000508" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: "tsv-ads@ietf.org" Subject: Re: [tcpm] [aqm] [tcpPrague] [tsvwg] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 10:45:01 -0000 This is a multi-part message in MIME format. --------------040709030009070906000508 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Folks, Some slides to frame the discussion at 9am this morning are uploaded to: https://riteproject.eu/dctth/#ietf-bar-bof Nonetheless, we want most of the time to be for discussion. Phil Eardley has agreed to chair the meeting. He has suggested: *Aim of meeting:** ** To determine whether there is interest in working on this. * To work out how to get the IETF to work on these pieces (ie the meeting is not primarily a technical discussion) Aaron Falk has kindly agreed to take notes. We will need a volunteer for jabber scribe, as we have remote attendees. Cheers Bob On 07/04/16 00:44, Bob Briscoe wrote: > Folks, > > Reminder, agenda & supporting materials below for the Bar BoF on L4S / > DualQ Coupled AQM / TCP Prague > > *Event details** > *Date/time: 09:00 - 10:00 local time (ART = 12-13:00 UTC) Thu 7 Apr 2016 > Room: Quebracho B > > *Supporting materials / background:** > *https://riteproject.eu/dctth/ > To use the time effectively, it will be assumed that people have a > working knowledge of what the technology is, and a rough idea of how > it works. > For those wanting an introduction, a useful 2-pager in the IETF > Journal is linked from the above, plus videos of the demos etc.b > Or chat with us afterwards > > *Proposed Agenda:** > ***09:00 > * Note Well, Agenda Bashing [Bob] > * Introduction/Background (very brief) [Bob] > * Clarification Questions > 09:15 > * Status updates [Koen to lead], e.g.: > - what people are doing on parts of the problem: > - planned work > - evaluation work > - interest in implementing > - willingness to review > 09:40 > * Build a standardisation roadmap [Bob to lead] > * Build a BoF for the Berlin time-frame > - should it be non-WG forming? > - volunteers to help with organisation / writing problem statement, > etc. > - which mailing list? > - what name? > * Discussion / Q&A > 09:55 end > > Most time will be allowed for people to talk from the floor. > > Cheers > > > Bob & Koen > > On 05/04/16 13:02, Bob Briscoe wrote: >> Folks, >> >> We have a time and room for this Bar BoF: >> Date/time: 09:00 - 10:00 ART (= 12-13:00 UTC) Thu 7 Apr 2016 >> Room: Quebracho B >> >> We have the regular IETF remote attendance facilities in that room. >> The room is not being used for the following session, so we don't >> have to vacate early. >> >> Sorry for delay setting this up. My fault. >> I've bcc'd a few people who have been asking about this specifically. >> >> >> Bob >> >> On 30/03/16 21:13, Aaron Falk wrote: >>> Did this get scheduled? >>> >>> --aaron >>> >>> On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF >>> wrote: >>> >>> Just to try to be helpful ... >>> >>> On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe >>> wrote: >>> >>> John, >>> >>> On 19/02/16 18:23, John Leslie wrote: >>> >>> Bob Briscoe >> > wrote: >>> >>> I'm cross-posting 'cos this impacts 3 IETF WGs and >>> interested implementers. >>> >>> We would like to propose a Bar BoF at the Buenos >>> Aires IETF, about L4S, >>> DualQ and solutions to the TCP Prague Requirements. >>> >>> This feels like it belongs as a non-WG-forming >>> formal BoF. >>> >>> It describes work spanning at least three WGs; and >>> could benefit from >>> formal scheduling to avoid conflicts with those WGs and >>> others. >>> >>> OTOH, it really isn't to the point where a WG >>> charter can reasonably >>> be drafted. First we must decide whether the work _can_ >>> be split among >>> existing WGs. >>> >>> However this may turn out, I wish to participate >>> remotely. >>> >>> OK, we'll see if the secretariat can help us with that. >>> >>> >>> I believe that happens at >>> http://www.ietf.org/meeting/amreq.html. If you put "TSV" in as >>> "type of meeting", your happy TSV ADs would see the request. >>> >>> Thanks, >>> >>> Spencer >>> >>> Unfortunately we ran out of time for the formal BoF deadline >>> on Friday. >>> >>> >>> Bob >>> >>> >>> -- >>> John Leslie >>> >>> _______________________________________________ >>> tcpPrague mailing list >>> tcpPrague@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpprague >>> >>> >>> -- >>> ________________________________________________________________ >>> Bob Briscoe http://bobbriscoe.net/ >>> >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >>> >>> >>> >>> _______________________________________________ >>> aqm mailing list >>> aqm@ietf.org >>> https://www.ietf.org/mailman/listinfo/aqm >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ --------------040709030009070906000508 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Folks,

Some slides to frame the discussion at 9am this morning are uploaded to:
https://riteproject.eu/dctth/#ietf-bar-bof
Nonetheless, we want most of the time to be for discussion.

Phil Eardley has agreed to chair the meeting. He has suggested:
Aim of meeting:
* To determine whether there is interest in working on this.
* To work out how to get the IETF to work on these pieces (ie the meeting is not primarily a technical discussion)

Aaron Falk has kindly agreed to take notes.
We will need a volunteer for jabber scribe, as we have remote attendees.

Cheers


Bob


On 07/04/16 00:44, Bob Briscoe wrote:
Folks,

Reminder, agenda & supporting materials below for the Bar BoF on L4S / DualQ Coupled AQM / TCP Prague

Event details
Date/time: 09:00 - 10:00 local time (ART = 12-13:00 UTC) Thu 7 Apr 2016
Room: Quebracho B

Supporting materials / background:
https://riteproject.eu/dctth/
To use the time effectively, it will be assumed that people have a working knowledge of what the technology is, and a rough idea of how it works.
For those wanting an introduction, a useful 2-pager in the IETF Journal is linked from the above, plus videos of the demos etc.b
Or chat with us afterwards

Proposed Agenda:
 09:00
* Note Well, Agenda Bashing [Bob]
* Introduction/Background (very brief) [Bob]
* Clarification Questions
09:15
* Status updates [Koen to lead], e.g.:
  - what people are doing on parts of the problem:
  - planned work
  - evaluation work
  - interest in implementing
  - willingness to review
09:40
* Build a standardisation roadmap [Bob to lead]
* Build a BoF for the Berlin time-frame
   - should it be non-WG forming?
   - volunteers to help with organisation / writing problem statement, etc.
   - which mailing list?
   - what name?
* Discussion / Q&A
09:55 end

Most time will be allowed for people to talk from the floor.

Cheers


Bob & Koen

On 05/04/16 13:02, Bob Briscoe wrote:
Folks,

We have a time and room for this Bar BoF:
Date/time: 09:00 - 10:00 ART (= 12-13:00 UTC) Thu 7 Apr 2016
Room: Quebracho B

We have the regular IETF remote attendance facilities in that room.
The room is not being used for the following session, so we don't have to vacate early.

Sorry for delay setting this up. My fault.
I've bcc'd a few people who have been asking about this specifically.


Bob

On 30/03/16 21:13, Aaron Falk wrote:
Did this get scheduled?

--aaron

On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Just to try to be helpful ...

On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
John,

On 19/02/16 18:23, John Leslie wrote:
Bob Briscoe <ietf@bobbriscoe.net> wrote:
I'm cross-posting 'cos this impacts 3 IETF WGs and interested implementers.

We would like to propose a Bar BoF at the Buenos Aires IETF, about L4S,
DualQ and solutions to the TCP Prague Requirements.
    This feels like it belongs as a non-WG-forming formal BoF.

    It describes work spanning at least three WGs; and could benefit from
formal scheduling to avoid conflicts with those WGs and others.

    OTOH, it really isn't to the point where a WG charter can reasonably
be drafted. First we must decide whether the work _can_ be split among
existing WGs.

    However this may turn out, I wish to participate remotely.
 OK, we'll see if the secretariat can help us with that.
I believe that happens at http://www.ietf.org/meeting/amreq.html. If you put "TSV" in as "type of meeting", your happy TSV ADs would see the request.

Thanks,

Spencer
 
Unfortunately we ran out of time for the formal BoF deadline on Friday.


Bob


--
John Leslie <john@jlc.net>

_______________________________________________
tcpPrague mailing list
tcpPrague@ietf.org
https://www.ietf.org/mailman/listinfo/tcpprague

--
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/



_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm




_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------040709030009070906000508-- From nobody Thu Apr 7 05:03:41 2016 Return-Path: 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 2AE8112D81C; Thu, 7 Apr 2016 05:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hf0jGygGSnYX; Thu, 7 Apr 2016 05:03:31 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75FA212D80A; Thu, 7 Apr 2016 05:03:30 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id t10so93443738ywa.0; Thu, 07 Apr 2016 05:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=/o47WtiqAn9oDvlejLzpHUw7mbRf+8UXh53heJjsDPI=; b=Ki3l1JJgZbzB/mjpxJoL0Xk4/T8TMPxodAFp8iESifL2v81hHjM6CWFTyrEkrigu7+ Rz7HDBxn7rIt6BVC50h0KJyM4uhQmI+DJBrujCTS5wQts/toMBFKcLvCv1TCyRuE2QCi MqNdfc2Q5j2UCK4ZhXzhLBUdOKsTXNSLfgEvE00IUllUE0vlZcZy7l1Ww6X7n6Qd5vTr P4EERIPum6WtXYGOHLXHHdxQ9puSCdxW7XXEPepj8YoWXyT+p0Qp7mTI8H/YyH4Avbz0 FvqiCXlTg6xNUt0XMkmDmskVg3EGQwezZE4QKd6ooPFGnvvkeT/z6kcyn7JfBG3R9hZu 8eQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/o47WtiqAn9oDvlejLzpHUw7mbRf+8UXh53heJjsDPI=; b=atcuoF4iaS2gBmR3NAh0cKvhfpJsAI5UF70BZ1Xv45oKZCW+iDdWgqDXEc/nmqHGUD DzxmxyD5piIrQimmGa5Mez2wQ/A8TB0Dx+rY7tJacyfj+Q9wlonIdWIm3TjEoAPiJtGt JqUWJotLNP77wS+MnDpmZ8YVUJFwnzklru44OCSG4BLsE0b94Xd1CY/v/MtXM5gNWcJA 4ODe8xRiuhCxWFrjy5zEIJIMM+9ZfPTXPSezkXExwCz63npI1kjvmADvrVA4N2nneyVV kgh5mrzNM5fjUnU23T4fJ0L4rltc7FQIlFG3+nVvgPSMqlgLUK2bLJRHoQQhwEU6eX/E glNA== X-Gm-Message-State: AD7BkJJ3EIIieoPO27GiwWhfppJBCCq8J3AHckbzyw2c7UQ94ZVcTDS3rv+ZBy/B3vW1c3488Q1zuJyIjY/77w== MIME-Version: 1.0 X-Received: by 10.13.225.148 with SMTP id k142mr1484448ywe.91.1460030609677; Thu, 07 Apr 2016 05:03:29 -0700 (PDT) Received: by 10.37.70.198 with HTTP; Thu, 7 Apr 2016 05:03:29 -0700 (PDT) In-Reply-To: <72E3332E-9B19-4C69-9E74-48205E7D2F43@isoc.org> References: <56C71869.9080503@bobbriscoe.net> <20160219182359.GA74531@verdi> <56CACCB1.2080502@bobbriscoe.net> <5703A963.6090306@bobbriscoe.net> <57059F43.1050406@bobbriscoe.net> <57063A22.2010709@bobbriscoe.net> <72E3332E-9B19-4C69-9E74-48205E7D2F43@isoc.org> Date: Thu, 7 Apr 2016 09:03:29 -0300 Message-ID: From: Aaron Falk To: Matthew Ford Content-Type: multipart/alternative; boundary=94eb2c077550d9fce1052fe3dde8 Archived-At: Cc: tcpm IETF list , tsvwg IETF list , TCP Prague List , "tsv-ads@ietf.org" , AQM IETF list Subject: Re: [tcpm] [tsvwg] [aqm] [tcpPrague] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 12:03:34 -0000 --94eb2c077550d9fce1052fe3dde8 Content-Type: text/plain; charset=UTF-8 Note taking is happening here: http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-l4s-barbof On Thu, Apr 7, 2016 at 8:13 AM, Matthew Ford wrote: > Thanks for sharing these in advance Bob. Slide 10 of the first deck is > priceless! > > > On 7 Apr 2016, at 07:44, Bob Briscoe wrote: > > > > Folks, > > > > Some slides to frame the discussion at 9am this morning are uploaded to: > > https://riteproject.eu/dctth/#ietf-bar-bof > > Nonetheless, we want most of the time to be for discussion. > > > > Phil Eardley has agreed to chair the meeting. He has suggested: > > Aim of meeting: > > * To determine whether there is interest in working on this. > > * To work out how to get the IETF to work on these pieces (ie the > meeting is not primarily a technical discussion) > > > > Aaron Falk has kindly agreed to take notes. > > We will need a volunteer for jabber scribe, as we have remote attendees. > > > > Cheers > > > > > > Bob > > > > > > On 07/04/16 00:44, Bob Briscoe wrote: > >> Folks, > >> > >> Reminder, agenda & supporting materials below for the Bar BoF on L4S / > DualQ Coupled AQM / TCP Prague > >> > >> Event details > >> Date/time: 09:00 - 10:00 local time (ART = 12-13:00 UTC) Thu 7 Apr 2016 > >> Room: Quebracho B > >> > >> Supporting materials / background: > >> https://riteproject.eu/dctth/ > >> To use the time effectively, it will be assumed that people have a > working knowledge of what the technology is, and a rough idea of how it > works. > >> For those wanting an introduction, a useful 2-pager in the IETF Journal > is linked from the above, plus videos of the demos etc.b > >> Or chat with us afterwards > >> > >> Proposed Agenda: > >> 09:00 > >> * Note Well, Agenda Bashing [Bob] > >> * Introduction/Background (very brief) [Bob] > >> * Clarification Questions > >> 09:15 > >> * Status updates [Koen to lead], e.g.: > >> - what people are doing on parts of the problem: > >> - planned work > >> - evaluation work > >> - interest in implementing > >> - willingness to review > >> 09:40 > >> * Build a standardisation roadmap [Bob to lead] > >> * Build a BoF for the Berlin time-frame > >> - should it be non-WG forming? > >> - volunteers to help with organisation / writing problem statement, > etc. > >> - which mailing list? > >> - what name? > >> * Discussion / Q&A > >> 09:55 end > >> > >> Most time will be allowed for people to talk from the floor. > >> > >> Cheers > >> > >> > >> Bob & Koen > >> > >> On 05/04/16 13:02, Bob Briscoe wrote: > >>> Folks, > >>> > >>> We have a time and room for this Bar BoF: > >>> Date/time: 09:00 - 10:00 ART (= 12-13:00 UTC) Thu 7 Apr 2016 > >>> Room: Quebracho B > >>> > >>> We have the regular IETF remote attendance facilities in that room. > >>> The room is not being used for the following session, so we don't have > to vacate early. > >>> > >>> Sorry for delay setting this up. My fault. > >>> I've bcc'd a few people who have been asking about this specifically. > >>> > >>> > >>> Bob > >>> > >>> On 30/03/16 21:13, Aaron Falk wrote: > >>>> Did this get scheduled? > >>>> > >>>> --aaron > >>>> > >>>> On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > >>>> Just to try to be helpful ... > >>>> > >>>> On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe > wrote: > >>>> John, > >>>> > >>>> On 19/02/16 18:23, John Leslie wrote: > >>>> Bob Briscoe wrote: > >>>> I'm cross-posting 'cos this impacts 3 IETF WGs and interested > implementers. > >>>> > >>>> We would like to propose a Bar BoF at the Buenos Aires IETF, about > L4S, > >>>> DualQ and solutions to the TCP Prague Requirements. > >>>> This feels like it belongs as a non-WG-forming formal BoF. > >>>> > >>>> It describes work spanning at least three WGs; and could benefit > from > >>>> formal scheduling to avoid conflicts with those WGs and others. > >>>> > >>>> OTOH, it really isn't to the point where a WG charter can > reasonably > >>>> be drafted. First we must decide whether the work _can_ be split among > >>>> existing WGs. > >>>> > >>>> However this may turn out, I wish to participate remotely. > >>>> OK, we'll see if the secretariat can help us with that. > >>>> > >>>> I believe that happens at http://www.ietf.org/meeting/amreq.html. If > you put "TSV" in as "type of meeting", your happy TSV ADs would see the > request. > >>>> > >>>> Thanks, > >>>> > >>>> Spencer > >>>> > >>>> Unfortunately we ran out of time for the formal BoF deadline on > Friday. > >>>> > >>>> > >>>> Bob > >>>> > >>>> > >>>> -- > >>>> John Leslie > >>>> > >>>> _______________________________________________ > >>>> tcpPrague mailing list > >>>> tcpPrague@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tcpprague > >>>> > >>>> -- > >>>> ________________________________________________________________ > >>>> Bob Briscoe http://bobbriscoe.net/ > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> tcpm mailing list > >>>> tcpm@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tcpm > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> aqm mailing list > >>>> > >>>> aqm@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/aqm > >>> > >>> -- > >>> ________________________________________________________________ > >>> Bob Briscoe > >>> http://bobbriscoe.net/ > >>> > >>> -- > >>> ________________________________________________________________ > >>> Bob Briscoe > >>> http://bobbriscoe.net/ > >>> > >>> -- > >>> ________________________________________________________________ > >>> Bob Briscoe > >>> http://bobbriscoe.net/ > >>> > >>> -- > >>> ________________________________________________________________ > >>> Bob Briscoe > >>> http://bobbriscoe.net/ > >>> > >>> -- > >>> ________________________________________________________________ > >>> Bob Briscoe > >>> http://bobbriscoe.net/ > >>> > >>> -- > >>> ________________________________________________________________ > >>> Bob Briscoe > >>> http://bobbriscoe.net/ > >> > >> -- > >> ________________________________________________________________ > >> Bob Briscoe > >> http://bobbriscoe.net/ > > _______________________________________________ > > aqm mailing list > > aqm@ietf.org > > https://www.ietf.org/mailman/listinfo/aqm > > --94eb2c077550d9fce1052fe3dde8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Apr 7, 2016 at 8:13 AM, M= atthew Ford <ford@isoc.org> wrote:
Thanks for sharing these in advance Bob. Slide 10 of the first deck = is priceless!

> On 7 Apr 2016, at 07:44, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>
> Folks,
>
> Some slides to frame the discussion at 9am this morning are uploaded t= o:
> https://riteproject.eu/dctth/#ietf-bar-bof
> Nonetheless, we want most of the time to be for discussion.
>
> Phil Eardley has agreed to chair the meeting. He has suggested:
> Aim of meeting:
> * To determine whether there is interest in working on this.
> * To work out how to get the IETF to work on these pieces (ie the meet= ing is not primarily a technical discussion)
>
> Aaron Falk has kindly agreed to take notes.
> We will need a volunteer for jabber scribe, as we have remote attendee= s.
>
> Cheers
>
>
> Bob
>
>
> On 07/04/16 00:44, Bob Briscoe wrote:
>> Folks,
>>
>> Reminder, agenda & supporting materials below for the Bar BoF = on L4S / DualQ Coupled AQM / TCP Prague
>>
>> Event details
>> Date/time: 09:00 - 10:00 local time (ART =3D 12-13:00 UTC) Thu 7 A= pr 2016
>> Room: Quebracho B
>>
>> Supporting materials / background:
>> https://riteproject.eu/dctth/
>> To use the time effectively, it will be assumed that people have a= working knowledge of what the technology is, and a rough idea of how it wo= rks.
>> For those wanting an introduction, a useful 2-pager in the IETF Jo= urnal is linked from the above, plus videos of the demos etc.b
>> Or chat with us afterwards
>>
>> Proposed Agenda:
>> 09:00
>> * Note Well, Agenda Bashing [Bob]
>> * Introduction/Background (very brief) [Bob]
>> * Clarification Questions
>> 09:15
>> * Status updates [Koen to lead], e.g.:
>>=C2=A0 =C2=A0- what people are doing on parts of the problem:
>>=C2=A0 =C2=A0- planned work
>>=C2=A0 =C2=A0- evaluation work
>>=C2=A0 =C2=A0- interest in implementing
>>=C2=A0 =C2=A0- willingness to review
>> 09:40
>> * Build a standardisation roadmap [Bob to lead]
>> * Build a BoF for the Berlin time-frame
>>=C2=A0 =C2=A0 - should it be non-WG forming?
>>=C2=A0 =C2=A0 - volunteers to help with organisation / writing prob= lem statement, etc.
>>=C2=A0 =C2=A0 - which mailing list?
>>=C2=A0 =C2=A0 - what name?
>> * Discussion / Q&A
>> 09:55 end
>>
>> Most time will be allowed for people to talk from the floor.
>>
>> Cheers
>>
>>
>> Bob & Koen
>>
>> On 05/04/16 13:02, Bob Briscoe wrote:
>>> Folks,
>>>
>>> We have a time and room for this Bar BoF:
>>> Date/time: 09:00 - 10:00 ART (=3D 12-13:00 UTC) Thu 7 Apr 2016=
>>> Room: Quebracho B
>>>
>>> We have the regular IETF remote attendance facilities in that = room.
>>> The room is not being used for the following session, so we do= n't have to vacate early.
>>>
>>> Sorry for delay setting this up. My fault.
>>> I've bcc'd a few people who have been asking about thi= s specifically.
>>>
>>>
>>> Bob
>>>
>>> On 30/03/16 21:13, Aaron Falk wrote:
>>>> Did this get scheduled?
>>>>
>>>> --aaron
>>>>
>>>> On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF = <spencerdawkins.ietf@gm= ail.com> wrote:
>>>> Just to try to be helpful ...
>>>>
>>>> On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>>>> John,
>>>>
>>>> On 19/02/16 18:23, John Leslie wrote:
>>>> Bob Briscoe <iet= f@bobbriscoe.net> wrote:
>>>> I'm cross-posting 'cos this impacts 3 IETF WGs and= interested implementers.
>>>>
>>>> We would like to propose a Bar BoF at the Buenos Aires IET= F, about L4S,
>>>> DualQ and solutions to the TCP Prague Requirements.
>>>>=C2=A0 =C2=A0 =C2=A0This feels like it belongs as a non-WG-= forming formal BoF.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0It describes work spanning at least thr= ee WGs; and could benefit from
>>>> formal scheduling to avoid conflicts with those WGs and ot= hers.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0OTOH, it really isn't to the point = where a WG charter can reasonably
>>>> be drafted. First we must decide whether the work _can_ be= split among
>>>> existing WGs.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0However this may turn out, I wish to pa= rticipate remotely.
>>>> OK, we'll see if the secretariat can help us with that= .
>>>>
>>>> I believe that happens at http://www.ietf.org= /meeting/amreq.html. If you put "TSV" in as "type of mee= ting", your happy TSV ADs would see the request.
>>>>
>>>> Thanks,
>>>>
>>>> Spencer
>>>>
>>>> Unfortunately we ran out of time for the formal BoF deadli= ne on Friday.
>>>>
>>>>
>>>> Bob
>>>>
>>>>
>>>> --
>>>> John Leslie <john@jlc.n= et>
>>>>
>>>> _______________________________________________
>>>> tcpPrague mailing list
>>>> tcpPrague@ietf.org
>>>> https://www.ietf.org/mailman/listinf= o/tcpprague
>>>>
>>>> --
>>>> __________________________________________________________= ______
>>>> Bob Briscoe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://bob= briscoe.net/
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> tcpm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tcp= m
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aqm mailing list
>>>>
>>>> aqm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/aqm=
>>>
>>> --
>>> ______________________________________________________________= __
>>> Bob Briscoe
>>> http://bobbriscoe.net/
>>>
>>> --
>>> ______________________________________________________________= __
>>> Bob Briscoe
>>> http://bobbriscoe.net/
>>>
>>> --
>>> ______________________________________________________________= __
>>> Bob Briscoe
>>> http://bobbriscoe.net/
>>>
>>> --
>>> ______________________________________________________________= __
>>> Bob Briscoe
>>> http://bobbriscoe.net/
>>>
>>> --
>>> ______________________________________________________________= __
>>> Bob Briscoe
>>> http://bobbriscoe.net/
>>>
>>> --
>>> ______________________________________________________________= __
>>> Bob Briscoe
>>> http://bobbriscoe.net/
>>
>> --
>> ________________________________________________________________ >> Bob Briscoe
>> http://bobbriscoe.net/
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm


--94eb2c077550d9fce1052fe3dde8-- From nobody Thu Apr 7 06:10:34 2016 Return-Path: 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 8D39412D1D6 for ; Thu, 7 Apr 2016 06:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-U1OzZ4WUgU for ; Thu, 7 Apr 2016 06:10:28 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71A9612D957 for ; Thu, 7 Apr 2016 06:10:07 -0700 (PDT) Received: from lawyers.icir.org (obrien.ICSI.Berkeley.EDU [192.150.187.23]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u37DA6we029244; Thu, 7 Apr 2016 06:10:06 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 25BF9419A4CD; Thu, 7 Apr 2016 09:10:06 -0400 (EDT) To: "Scharf\, Michael \(Nokia - DE\)" From: Mark Allman In-Reply-To: <655C07320163294895BBADA28372AF5D48780E7F@FR712WXCHMBA15.zeu.alcatel-lucent.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Wishlist X-URL-0: http://www.icir.org/mallman-files/Document36819.html MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 07 Apr 2016 09:10:06 -0400 Message-ID: <3905.1460034606@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Applicability of draft-ietf-tcpm-rto-consider-02 to non-IETF protocols X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 13:10:32 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Michael! I am having a difficult time understanding these points. My high order bits ... - This is an effort within the standards process and so setting it in that context seems fine to me. - The guidelines certainly could apply to protocols outside the IETF's purview and I'd be fine with others using them (and in fact would hope they would). However, that to me doesn't suggest we loosen the language. > I think the current wording in -02 is overly restrictive: >=20 > An exception is made to this rule if an IETF standardized > mechanism is used to determine that a particular loss is due to > a non-congestion event (e.g., packet corruption). Let's be clear: This document does not change the state of things. For context, the whole guideline you snipped from is: (4) Retransmission timeouts MUST be taken as indications of congestion in the network and the sending rate adapted using a standard mechanism (e.g., TCP collapses the congestion window to one segment [RFC5681]). This ensures network safety. An exception is made to this rule if an IETF standardized mechanism is used to determine that a particular loss is due to a non-congestion event (e.g., packet corruption). In such a case a congestion control action is not required. Additionally, RTO-triggered congestion control actions may be reversed when a standard mechanism determines that the cause of the loss was not congestion after all. Guideline (4) says nothing new. I.e., the state of the standards is: (a) loss is assumed to indicate congestion (b) congestion results in a load reduction (c) if we have agreed on some mechanism to refute (a) then we can skip (b)=20 That is the state of the standards. This document is consistent with reality in this respect but does not change it. This is the state of things with or without this document. > I think it is sufficient to have a mechanism to detect > non-congestion events. This changes the state of the world. I.e., here is my mechanism for detecting non-congestion loss: - when we detect loss, roll random number R in [0.0,1.0] - if R >=3D 0.95 decide loss is congestion-based, else decide the loss is non-congestion-based Why 0.95? Because I just *know* 95% of the losses are not related to congestion of course! And, Yes, I Am Just That Damn Smart. I think we'd all agree that is a stupid mechanism. But, by suggesting it is sufficient for any-old-mechanism to exist to determine the difference between congestion and non-congestion losses we have to be OK with my stupid mechanism or any other crackpot idea that someone cooks up. I Am Not OK With That. > To me, it does not matter whether this mechanism is standardized > by the IETF. The standardization may not even be possible if that > mechanism is tightly tied into a non-IETF protocol. OK, fine. But, these are cases where someone is already operating outside the standards process. And, that may well be fine. But, I don't see how that is going to de-rail someone from using the guidelines in this document. > Also, "standardization" seems to exclude > informational/experimental RFCs and I am not sure if I agree that > they should be excluded here. True- these are excluded. But, that is the reality of the world. I.e., strictly speaking these shouldn't be used by TCP or SCTP or whatever either. If you think they are OK for wide-spread use then it seems to me that the right path is to get them on the standards track. The wrong path seems to just say anything goes. > The following wording also seems to implicitly assume that IETF > standards are used as basis of a protocol:=20 >=20 > A non-goal of this document is to in any way specify > individual deviations from current IETF standardized RTO > specifications that any particular implementation may exhibit. > Rather, we provide a set of over-arching guidelines that all > RTO mechanisms should follow. >=20 > This wording makes sense for TCP. But, again, I'd prefer a wording > that applies to all protocols running over the Internet no matter > whether the protocol mechanics use IETF standards as basis, or > not.=20 Again, I do not follow. The intent here---although I am not sure I like the words now that I am reading them---is to say that the document is not meant as a change to individual RTO mechanisms already standardized. E.g., the document will not be specifying new SRTT gains in TCP's RTO. I would not have thought that to be controversial. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlcGXC0ACgkQWyrrWs4yIs4suwCgmHU1lO8Q/2V8Gs76B7+87oXr gB0AnA/UGwX3gSDkllw6Jl3M9yw0G25B =eazl -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Thu Apr 7 07:13:53 2016 Return-Path: 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 61E5C12D5C2 for ; Thu, 7 Apr 2016 07:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBoz6gs3QnHN for ; Thu, 7 Apr 2016 07:13:43 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33FC912D550 for ; Thu, 7 Apr 2016 07:13:39 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 706F6E340C504; Thu, 7 Apr 2016 14:13:33 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u37EDamc012352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Apr 2016 14:13:36 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u37ECpNe018586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Apr 2016 16:13:34 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.46]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 7 Apr 2016 16:13:06 +0200 From: "Scharf, Michael (Nokia - DE)" To: "mallman@icir.org" Thread-Topic: Applicability of draft-ietf-tcpm-rto-consider-02 to non-IETF protocols Thread-Index: AQHRkM7azq1zPd7vdkOQaXYzDTfEYZ9+hEcg Date: Thu, 7 Apr 2016 14:13:05 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4878189A@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D48780E7F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <3905.1460034606@lawyers.icir.org> In-Reply-To: <3905.1460034606@lawyers.icir.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Applicability of draft-ietf-tcpm-rto-consider-02 to non-IETF protocols X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 14:13:47 -0000 OK, I'll try again: I think it would make sense that an implementer e.g. of= an UDP-based gaming protocol would be able to ensure that his protocol ful= fills the requirements in this BCP ... even if that protocol does not use a= ny protocol semantic in any standardized IETF transport protocol (e.g., TCP= , SCTP, ...), and even if this (hypothetical) protocol may never show up in= the IETF standards process. Not all protocols and algorithms running in the general Internet are specif= ied in IETF standards track documents. But hopefully an implementer would s= till understand that it would be useful to implement an RTO mechanism fulfi= lling these requirements. The simple remedy is not to insist on IETF standa= rdized mechanisms in the document, but just describe the required basic fun= ctionality at a high-level. That's what I suggest. The document is actually= meets those objectives very well, except in the few paragraphs in which th= e word "standardized" shows up. Michael From nobody Thu Apr 7 07:43:02 2016 Return-Path: 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 19C4A12D97E for ; Thu, 7 Apr 2016 07:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3cSaPEvdj93 for ; Thu, 7 Apr 2016 07:42:59 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1492112D9AA for ; Thu, 7 Apr 2016 07:28:36 -0700 (PDT) Received: from lawyers.icir.org (obrien.ICSI.Berkeley.EDU [192.150.187.23]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u37ESZVe006145; Thu, 7 Apr 2016 07:28:35 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id D802941AE8CC; Thu, 7 Apr 2016 10:28:34 -0400 (EDT) To: "Scharf\, Michael \(Nokia - DE\)" From: Mark Allman In-Reply-To: <655C07320163294895BBADA28372AF5D4878189A@FR712WXCHMBA15.zeu.alcatel-lucent.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Wishlist X-URL-0: http://www.icir.org/mallman-files/Document91703.html MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 07 Apr 2016 10:28:34 -0400 Message-ID: <16468.1460039314@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Applicability of draft-ietf-tcpm-rto-consider-02 to non-IETF protocols X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 14:43:01 -0000 --=-------459435943823349593450 Content-Type: text/plain You did not address my counter-points. > OK, I'll try again: I think it would make sense that an > implementer e.g. of an UDP-based gaming protocol would be able to > ensure that his protocol fulfills the requirements in this BCP > ... even if that protocol does not use any protocol semantic in > any standardized IETF transport protocol What about this document makes you think someone working on some non-IETF protocol would not be able to follow the guidelines? allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlcGbpAACgkQWyrrWs4yIs7L6wCfW0K+bw0/4bsRj0+dkiC29Ktb FqwAnRPuNhrmARIiyQ0ygzjy5xzNAY+n =/I4j -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Thu Apr 7 08:02:37 2016 Return-Path: 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 858A412D79B; Thu, 7 Apr 2016 04:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ur9r_HaWyzED; Thu, 7 Apr 2016 04:13:52 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0078.outbound.protection.outlook.com [207.46.100.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA8412D788; Thu, 7 Apr 2016 04:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VR2ELoPi5R+OSBQ0O1DK+gz//GUkVHLyi/Ep6bfoAnI=; b=BVTjO87M7ggkInvJ41G9dz+2p7Dr+uNN8oaCGxxkcZD+s63pmZ9tAfKBci9gKsv/BkiIZmZSX741y7htNeDMEvFcsXqHzum3VB+V3eUxLvnVjcwbGHvuAzFYmddWkmwjj+LgWIqIuAJkcDxJXGALBkjCtOZr/PlACBJMaEn23Sg= Authentication-Results: bobbriscoe.net; dkim=none (message not signed) header.d=none;bobbriscoe.net; dmarc=none action=none header.from=isoc.org; Received: from [IPv6:2001:67c:370:144:2496:426e:70ba:5bcf] (2001:67c:370:144:2496:426e:70ba:5bcf) by BY2PR06MB2213.namprd06.prod.outlook.com (10.166.113.151) with Microsoft SMTP Server (TLS) id 15.1.453.26; Thu, 7 Apr 2016 11:13:48 +0000 MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset="windows-1252" From: Matthew Ford In-Reply-To: <57063A22.2010709@bobbriscoe.net> Date: Thu, 7 Apr 2016 08:13:41 -0300 Content-Transfer-Encoding: quoted-printable Message-ID: <72E3332E-9B19-4C69-9E74-48205E7D2F43@isoc.org> References: <56C71869.9080503@bobbriscoe.net> <20160219182359.GA74531@verdi> <56CACCB1.2080502@bobbriscoe.net> <5703A963.6090306@bobbriscoe.net> <57059F43.1050406@bobbriscoe.net> <57063A22.2010709@bobbriscoe.net> To: Bob Briscoe X-Mailer: Apple Mail (2.3124) X-Originating-IP: [2001:67c:370:144:2496:426e:70ba:5bcf] X-ClientProxiedBy: BY2PR1001CA0053.namprd10.prod.outlook.com (10.164.163.21) To BY2PR06MB2213.namprd06.prod.outlook.com (10.166.113.151) X-MS-Office365-Filtering-Correlation-Id: 4323bb5c-54d6-4731-f9a2-08d35ed5b2bb X-Microsoft-Exchange-Diagnostics: 1; BY2PR06MB2213; 2:fSSzgsY42iRzI47uWAjHVWrnVw9lYAJQ4FNey7fvjsxSzFCtdO9Aa+bE4Lzh07OWXkjr6kQ4UGdhAMmcN+tYZs9DMZacuuPuOYazmCDTQpne/kAdGLoKhInGU6r9JOJn5U2kA9NuJyamyjPyvwONhVTp5XqZah//053VJy/W3KEjp8DTI/Z8Lx1UzH6J7QH3; 3:shP6o2jQw3epkXsG+2js+hzpKBFafvhUJ7kmessGKoF1d9DRw7VwJTZqA6h/1huZ4S33aALFODZYE6BGv8Jtev5kHNstPv8lQLTdPRaaaPaX0M1vT/y6FryWRJsUYWdN X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR06MB2213; X-Microsoft-Exchange-Diagnostics: 1; BY2PR06MB2213; 25:kc3yRtRW5z55xPLMA0j3LYhRmwUsvj+hncafzKSaQyO0X6tl5kaYv9QFGhjLX2wx/WCSXKF7nRBBmia3zTxyxBNqgXBOM3PATxL3upZqbPFtB7LjAjFLxiuS/LsYZh4zUcSNsZ5ZO/MMcZGhN7zkRXKVbgjexzA9FoCIqAtDVu+lXu8OvdTH05zgTB6MQF8scZnRdC9E0zIb0+HSHqwgzYhCKKRdDJXeTVEs3is7/ed6ltYEmzowBqMwWgP6cki/EQzAiSKLYIZu5pahm4c5Y6aalR5uEzhscEXjRMYfAkWQlX4hg7mPSfe+J2ho1QdnBeVlx1Pac9szKcXCDk7HVyd00vMVDmYwGAMAqktIg+OuKjFhocjNBgevnc7qFtZrWK9t9tXMimcOY5DY3H604qREAAatxP4/DLZ/WPd3nnDiRQKcLEUXMOmX0b3EC9VWrddfLGYQSP6xkNfv82uGNJomH0vC6g0VEKS87LtBQAz2pjaUmRl+vq4mV53EbXLolDhrS9OE5+rhIWZL9Np7yRdpnOtvtPPGFXFCCbGmsmq4Z2X1RNk/1phb1uZq0/kM+7URba9Y6F/XaefOkud/FUE9nD8KheA3a61cjAlt4X1bAOxthsGdSB7fy4EhdEFCS6b2/WOQK0LCy3P9oAPHfHKCKWa6d4OphQN+9jCLXeI= X-Microsoft-Exchange-Diagnostics: 1; BY2PR06MB2213; 20:BuEOyUyE91ytPtvlBFh/Aqyq7iJnvzIEPC/xbNg6YgyKeb/iXm6v6DMt3daltSUSflIp/ac+D5SJ3vq+HDLd5GWimh+vFjrMnHIOwsyhmr//L/6JbJ6Sf21DsGNwVb1/Qm1Kk4jM8Y7pF5ljOsZSc6GVx0OMcBWg3cc7FwFS46IyVgUETI9PK7P2DwV16AoAeDRYn7LmMRloTjAoUoZjOSOuNTncXm7zIcZcYPOrTUs405J1RUoSyAy+2uFtuhJzFDJcoer+3RKkOiTnB2rMQFvLsM+FIMxEU2Dpj16mj5wZar3NoV9HmOgwIilu8GvvU6dnp2lgydAYY83LzvfeQcqXWOAjUePKNDsD1PJ++fJqXX9pXtZfnsTQnBfGK5UHP6tlfHp0seHB767owJSUVGGayJnhAu4GAiMB4ZOyOgTDIQUqRdSafwKuzZhKdy0B7kNtoFisv4aNB3xyMRX8n047aiMHphBZsBeirvtXou0VtiUUOiD9FIzi2j5YsK8k; 4:NLIfRNtUSRV5jVQt05s5nkFAoOkbEtow/Adhv+vnJbb9kVKYnrldjrfIVz17NPsrM9KhE049mON9b3ab18UcbVbbP9QyT7o9M4V2zl3LreokP8xDeVk6SeY1Z3iB0W2ufYULB5Xxir4wlXuizda/fa+RzVSCqbna+BBUuJgF8MFG2IbLJ4wPFEE0uLsgy/lnb41P2C9HxMMX9AnVE9Go4CxNiFs+rMgsrZXpg3vHvCVWwSTKoIDw9jCyyHZHeSEu+h6TwRfy4LKmD1e2pUkFVs5VnVlaX277ZgXNEycGas8co4EJ1KwfpkgPI/bODVTXXDbdom/BdaHelRM2ndaNYXr/fX+z1v4RhHBHJ8GUKGHCaQxASquXJfltfYcH39k4 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BY2PR06MB2213; BCL:0; PCL:0; RULEID:; SRVR:BY2PR06MB2213; X-Forefront-PRVS: 0905A6B2C7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(52604005)(78114003)(497574002)(377454003)(24454002)(33656002)(47776003)(93886004)(4326007)(164054004)(92566002)(189998001)(50226001)(110136002)(86362001)(15395725005)(5008740100001)(2906002)(1096002)(586003)(42186005)(19580395003)(83716003)(19580405001)(6116002)(82746002)(36756003)(81166005)(2950100001)(15975445007)(77096005)(76176999)(57306001)(50986999)(50466002)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR06MB2213; H:[IPv6:2001:67c:370:144:2496:426e:70ba:5bcf]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BY2PR06MB2213; 23:XawH+f1LKZRDXqS/nO8+lhGu00+Uqc7PQ3wOy?= =?Windows-1252?Q?L3X4fEub7g0PFQSyJCw7IMtMokGm0tb6wwbka+VlBpXg3NqE2FsVb+qa?= =?Windows-1252?Q?C81CLC7v53IK/ZIsFxc6tniZMlnfVFYyw+fdHgRD0HCDCQi9S7l9Qsmj?= =?Windows-1252?Q?UUDnEthQBB/nPVTQt0zJA0dJ9YS4G+Ab1zsTM2x3QB4rYJzop760HTyC?= =?Windows-1252?Q?bKGiGaYJATiR2iTqplZqmBcdg+XILwgpLfIS9PFvwEbPM8M7q7W230Wq?= =?Windows-1252?Q?v0wpHoteTkkceYb8xeLcwrziHIoIZvHMQEHujZaoff6o2woNlv1N1raN?= =?Windows-1252?Q?gABeIXr9QarMyM6x+theFVaAiFyPAs2IviaBG8kRZyxmGqbOusOkAAO3?= =?Windows-1252?Q?IJlD3pV8CUuaObASUQApS+REGzRKX39rCD0tA0wOS3JpAS4hI6LEH9/M?= =?Windows-1252?Q?AVGb4Or5kd7op84Wlmof+XbWQcSivEk8csmJmOfXHDEoe4mPtcutflku?= =?Windows-1252?Q?rjqT2bwV8XC0l4Q7kNW//zV/R3A70unjr83SvN2Awb2rlToteX6qqtmp?= =?Windows-1252?Q?121V/ah4nBfWJk7j1cXTSst61Olg9DvI5ibXjJQf7vyVKQPWQXPZant+?= =?Windows-1252?Q?WLqL/TTMvgdIk7A8n156yJlXugCoMHF0HI/18paJqpkG06qiO6uaAXQa?= =?Windows-1252?Q?XMJDKBKCOWuGHwy3C/2f0cEYvR5erWXGmy8nX3XsvuOCsdvqBuQF2uye?= =?Windows-1252?Q?C+prOey8TUaNbOuFfLzovJmm9NkOMLtfkGisDPLwRz9JbJN7vlzIWEk2?= =?Windows-1252?Q?it/OnGbsC6EShuyxyvBd2WXGn/B0lxGkWjnJrcqv7JyqmHKWf+//dJHh?= =?Windows-1252?Q?dCvLz5lNQOolk7emDAY6+e1wbafzVarGEKuHt1VLSEYIt94wSrHCCnIA?= =?Windows-1252?Q?f5u/LiYVfci2mi/6uh9UWKObX4g6aJFnZhWRtrn1xUWYva+Zbih+VenQ?= =?Windows-1252?Q?yJXz4md9aCLliCW+lUid6VyOkD2LlbPTU8UsBzMdIgB5HNJB0p8vkOkV?= =?Windows-1252?Q?B3+E5PvVhX1HFUxUos1BD00jrhTrtmcEcrY?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR06MB2213; 5:i+jD8rNryH/bM6vcuyk/hBLhIR+yuPCxtVQqsAzMw45aI/1bpQVFWAR31hoE6eG+bfozz9Mn1rOxB9t+CG3XtMPXadQHVmeAoHCRE51h3jb3CmqKkx0It+4ec0KfCT9euok4ZuJYpWd+CI93czngbA==; 24:0HOPScpDhqSFE3m4KLztPls6ExH9FpE/wEcOpQ2R7uZjS83F/ST7lpyKO59qSyZ9n/wUxo1xLQHrim7FHAq9evoek0AWUhAZd3Iisw3m3dY= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Apr 2016 11:13:48.8923 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR06MB2213 Archived-At: X-Mailman-Approved-At: Thu, 07 Apr 2016 08:02:36 -0700 Cc: tcpm IETF list , tsvwg IETF list , "tsv-ads@ietf.org" , TCP Prague List , AQM IETF list Subject: Re: [tcpm] [aqm] [tcpPrague] [tsvwg] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 11:13:56 -0000 Thanks for sharing these in advance Bob. Slide 10 of the first deck is = priceless! > On 7 Apr 2016, at 07:44, Bob Briscoe wrote: >=20 > Folks, >=20 > Some slides to frame the discussion at 9am this morning are uploaded = to: > https://riteproject.eu/dctth/#ietf-bar-bof > Nonetheless, we want most of the time to be for discussion. >=20 > Phil Eardley has agreed to chair the meeting. He has suggested: > Aim of meeting: > * To determine whether there is interest in working on this. > * To work out how to get the IETF to work on these pieces (ie the = meeting is not primarily a technical discussion) >=20 > Aaron Falk has kindly agreed to take notes. > We will need a volunteer for jabber scribe, as we have remote = attendees. >=20 > Cheers >=20 >=20 > Bob >=20 >=20 > On 07/04/16 00:44, Bob Briscoe wrote: >> Folks, >>=20 >> Reminder, agenda & supporting materials below for the Bar BoF on L4S = / DualQ Coupled AQM / TCP Prague >>=20 >> Event details >> Date/time: 09:00 - 10:00 local time (ART =3D 12-13:00 UTC) Thu 7 Apr = 2016 >> Room: Quebracho B >>=20 >> Supporting materials / background: >> https://riteproject.eu/dctth/ >> To use the time effectively, it will be assumed that people have a = working knowledge of what the technology is, and a rough idea of how it = works. >> For those wanting an introduction, a useful 2-pager in the IETF = Journal is linked from the above, plus videos of the demos etc.b=20 >> Or chat with us afterwards >>=20 >> Proposed Agenda: >> 09:00 >> * Note Well, Agenda Bashing [Bob] >> * Introduction/Background (very brief) [Bob] >> * Clarification Questions >> 09:15=20 >> * Status updates [Koen to lead], e.g.: >> - what people are doing on parts of the problem: >> - planned work >> - evaluation work >> - interest in implementing >> - willingness to review >> 09:40 >> * Build a standardisation roadmap [Bob to lead] >> * Build a BoF for the Berlin time-frame >> - should it be non-WG forming? >> - volunteers to help with organisation / writing problem = statement, etc. >> - which mailing list? >> - what name? >> * Discussion / Q&A >> 09:55 end >>=20 >> Most time will be allowed for people to talk from the floor. >>=20 >> Cheers >>=20 >>=20 >> Bob & Koen >>=20 >> On 05/04/16 13:02, Bob Briscoe wrote: >>> Folks, >>>=20 >>> We have a time and room for this Bar BoF: >>> Date/time: 09:00 - 10:00 ART (=3D 12-13:00 UTC) Thu 7 Apr 2016 >>> Room: Quebracho B >>>=20 >>> We have the regular IETF remote attendance facilities in that room. >>> The room is not being used for the following session, so we don't = have to vacate early. >>>=20 >>> Sorry for delay setting this up. My fault. >>> I've bcc'd a few people who have been asking about this = specifically. >>>=20 >>>=20 >>> Bob >>>=20 >>> On 30/03/16 21:13, Aaron Falk wrote: >>>> Did this get scheduled? >>>>=20 >>>> --aaron >>>>=20 >>>> On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF = wrote: >>>> Just to try to be helpful ... >>>>=20 >>>> On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe = wrote: >>>> John, >>>>=20 >>>> On 19/02/16 18:23, John Leslie wrote: >>>> Bob Briscoe wrote: >>>> I'm cross-posting 'cos this impacts 3 IETF WGs and interested = implementers. >>>>=20 >>>> We would like to propose a Bar BoF at the Buenos Aires IETF, about = L4S, >>>> DualQ and solutions to the TCP Prague Requirements. >>>> This feels like it belongs as a non-WG-forming formal BoF. >>>>=20 >>>> It describes work spanning at least three WGs; and could = benefit from >>>> formal scheduling to avoid conflicts with those WGs and others. >>>>=20 >>>> OTOH, it really isn't to the point where a WG charter can = reasonably >>>> be drafted. First we must decide whether the work _can_ be split = among >>>> existing WGs. >>>>=20 >>>> However this may turn out, I wish to participate remotely. >>>> OK, we'll see if the secretariat can help us with that. >>>>=20 >>>> I believe that happens at http://www.ietf.org/meeting/amreq.html. = If you put "TSV" in as "type of meeting", your happy TSV ADs would see = the request. >>>>=20 >>>> Thanks, >>>>=20 >>>> Spencer >>>> =20 >>>> Unfortunately we ran out of time for the formal BoF deadline on = Friday. >>>>=20 >>>>=20 >>>> Bob >>>>=20 >>>>=20 >>>> -- >>>> John Leslie >>>>=20 >>>> _______________________________________________ >>>> tcpPrague mailing list >>>> tcpPrague@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpprague >>>>=20 >>>> --=20 >>>> ________________________________________________________________ >>>> Bob Briscoe http://bobbriscoe.net/ >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> aqm mailing list >>>>=20 >>>> aqm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/aqm >>>=20 >>> --=20 >>> ________________________________________________________________ >>> Bob Briscoe =20 >>> http://bobbriscoe.net/ >>>=20 >>> --=20 >>> ________________________________________________________________ >>> Bob Briscoe =20 >>> http://bobbriscoe.net/ >>>=20 >>> --=20 >>> ________________________________________________________________ >>> Bob Briscoe =20 >>> http://bobbriscoe.net/ >>>=20 >>> --=20 >>> ________________________________________________________________ >>> Bob Briscoe =20 >>> http://bobbriscoe.net/ >>>=20 >>> --=20 >>> ________________________________________________________________ >>> Bob Briscoe =20 >>> http://bobbriscoe.net/ >>>=20 >>> --=20 >>> ________________________________________________________________ >>> Bob Briscoe =20 >>> http://bobbriscoe.net/ >>=20 >> --=20 >> ________________________________________________________________ >> Bob Briscoe =20 >> http://bobbriscoe.net/ > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From nobody Thu Apr 7 08:15:25 2016 Return-Path: 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 A556D12D94E for ; Thu, 7 Apr 2016 08:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0-yetft4Rzc for ; Thu, 7 Apr 2016 08:15:17 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85B6D12D915 for ; Thu, 7 Apr 2016 08:02:54 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id D686AC5A1FCA9; Thu, 7 Apr 2016 15:02:49 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u37F2qBt023666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Apr 2016 15:02:52 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u37F2NFg010940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Apr 2016 17:02:50 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.46]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 7 Apr 2016 17:02:09 +0200 From: "Scharf, Michael (Nokia - DE)" To: "mallman@icir.org" Thread-Topic: Applicability of draft-ietf-tcpm-rto-consider-02 to non-IETF protocols Thread-Index: AQHRkNnDzq1zPd7vdkOQaXYzDTfEYZ9+klXg Date: Thu, 7 Apr 2016 15:02:08 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48781BBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D4878189A@FR712WXCHMBA15.zeu.alcatel-lucent.com> <16468.1460039314@lawyers.icir.org> In-Reply-To: <16468.1460039314@lawyers.icir.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Applicability of draft-ietf-tcpm-rto-consider-02 to non-IETF protocols X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 15:15:18 -0000 Regarding: An exception is made to this rule if an IETF standardized mechanism is used to determine that a particular loss is due to a non-congestion event (e.g., packet corruption). =20 This excludes non-IETF standardized methods to detect non-congestion events= . For the RTO mechanism it does not matter whether the mechanism that can d= etect a non-congestion event is standardized by the IETF or not. That mecha= nism could also be done in IEEE, ITU-T, or elsewhere, provided that it work= s (which will be the actual problem, not what SDO standardizes it). Also, in my reading a non-IETF protocol may not be able to fulfill the foll= owing rule if it cannot implement F-RTO or some of the TCP-ish SACK mechani= sms, which is (out-of-my-head, sorry if I miss something) the only standard= ized mechanism the IETF has: Additionally, RTO-triggered congestion control actions may be reversed when a standard mechanism determines that the cause of the loss was not congestion after all. I think somebody could design a protocol that cannot use F-RTO. With a narr= ow understanding of "standardized" even Eifel Detection (RFC 3522) is not a= llowed because it is only experimental. Mandating "standardization" in this= sentence does even make less sense to me than in the previous example. Removing the words "standardized" and "IETF standardized" should sort this = out. Michael -----Original Message----- From: mallman@icir.org [mailto:mallman@icir.org]=20 Sent: Thursday, April 07, 2016 4:29 PM To: Scharf, Michael (Nokia - DE) Cc: tcpm@ietf.org Extensions Subject: Re: Applicability of draft-ietf-tcpm-rto-consider-02 to non-IETF p= rotocols=20 You did not address my counter-points. > OK, I'll try again: I think it would make sense that an implementer=20 > e.g. of an UDP-based gaming protocol would be able to ensure that his=20 > protocol fulfills the requirements in this BCP ... even if that=20 > protocol does not use any protocol semantic in any standardized IETF=20 > transport protocol What about this document makes you think someone working on some non-IETF p= rotocol would not be able to follow the guidelines? allman From nobody Thu Apr 7 09:01:42 2016 Return-Path: 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 24E1E12D196 for ; Thu, 7 Apr 2016 09:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wimCm08KchI for ; Thu, 7 Apr 2016 09:01:38 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09ACB12D18F for ; Thu, 7 Apr 2016 09:01:38 -0700 (PDT) Received: from lawyers.icir.org (obrien.ICSI.Berkeley.EDU [192.150.187.23]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u37G1b7E014851; Thu, 7 Apr 2016 09:01:37 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id C100241BE025; Thu, 7 Apr 2016 12:01:36 -0400 (EDT) To: "Scharf\, Michael \(Nokia - DE\)" From: Mark Allman In-Reply-To: <655C07320163294895BBADA28372AF5D48781BBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Wishlist X-URL-0: http://www.icir.org/mallman-files/Document45729.jpg X-URL-1: http://www.icir.org/mallman-files/Document42530.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 07 Apr 2016 12:01:36 -0400 Message-ID: <31513.1460044896@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Applicability of draft-ietf-tcpm-rto-consider-02 to non-IETF protocols X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 16:01:41 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > Regarding: >=20 > An exception is made to this rule if an IETF standardized > mechanism is used to determine that a particular loss is due to > a non-congestion event (e.g., packet corruption).=20=20 >=20 > This excludes non-IETF standardized methods to detect > non-congestion events. I agree. But, the (inconvenient) reality here is that non-IETF standardized methods to detect non-congestion events are already excluded by the standards! Not because of this document. On the contrary, this document simply reflects current reality in this space. This document is not a congestion control document and does not seek to make changes to congestion control. You don't have to like reality. Maybe you think there is a document akin to this one for detecting non-congestion losses. I.e., a set of guidelines that if followed would allow one to determine a loss is not congestion-based and therefore to prevent a congestion reaction. If so, please write that document and we can talk about it. But, that is not this document. > Removing the words "standardized" and "IETF standardized" should > sort this out.=20 I do not support that approach. That is a backdoor change to congestion control. It is beyond the scope of this document. And, if it should be done at all it should be done in the full light of day and not buried in this document. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlcGhF4ACgkQWyrrWs4yIs6oogCfVyp6PGUzMR2GZ4O1EUr8vDVz Sh8An079YK6VZ83NcwhU7gW0s0aUH05W =f/dm -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Thu Apr 7 09:08:04 2016 Return-Path: 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 F0A3412D0B8 for ; Thu, 7 Apr 2016 09:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5X6fBBrnTMt for ; Thu, 7 Apr 2016 09:08:01 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:703]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07D812D0CA for ; Thu, 7 Apr 2016 09:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9zHxk4m9rsRR90ouJ5H+AxplTAXSGm61FG7Ji+8hQQI=; b=WcJFh1IrF52g0NH/xwPtO0fZ5ciYXsdHvYCy3xzQjQeKvVRfglo3+kI8+zjTcccUYMKht2Tdz7+wRSzE1gcVPtC4mlJIYj3xp+SBsgLgRr3fwrpgPwbAeT+UW5q3dh0fiNSConFsY5dxBeAWnTalCR8ZZ5Gv5Ui6evBco7E2xPo= Received: from BN3PR0501MB1345.namprd05.prod.outlook.com (10.160.183.22) by BN3PR0501MB1347.namprd05.prod.outlook.com (10.160.183.24) with Microsoft SMTP Server (TLS) id 15.1.447.15; Thu, 7 Apr 2016 16:07:43 +0000 Received: from BN3PR0501MB1345.namprd05.prod.outlook.com ([10.160.183.22]) by BN3PR0501MB1345.namprd05.prod.outlook.com ([10.160.183.22]) with mapi id 15.01.0447.029; Thu, 7 Apr 2016 16:07:43 +0000 From: Jonathan Looney To: "Scharf, Michael (Nokia - DE)" , "mallman@icir.org" Thread-Topic: [tcpm] Applicability of draft-ietf-tcpm-rto-consider-02 to non-IETF protocols Thread-Index: AQHRkM7gewPjfialwUy1CbOleR0Vkp9+jZaAgAAEVACAAAlgAP//z0OA Date: Thu, 7 Apr 2016 16:07:42 +0000 Message-ID: <0960AC8F-E3AA-4950-98AC-50CD37C914F1@juniper.net> References: <655C07320163294895BBADA28372AF5D4878189A@FR712WXCHMBA15.zeu.alcatel-lucent.com> <16468.1460039314@lawyers.icir.org> <655C07320163294895BBADA28372AF5D48781BBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48781BBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-ms-office365-filtering-correlation-id: 121cdcfe-dc45-4638-5c67-08d35efec04b x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1347; 5:xN9M7epM1iL5PGlD37OYEglZahtWfBcqDNNmxplNrdXF0rTDcBtqSp6MzLvKSnyql9bBImljl6UeMOgqICQMvatuxA/lmms+STa0XYg3dkVgBjgMYpEjoMyZk684VIpaD6/NJn60Ww7pa3qO0rqV1w==; 24:vYW/iOLr+tAv1T95DnoenmfsX5uWfSnzkE7XkL5bjh01sKmbdRoTZ4uCI6tDWPEcHfFzEDN1fCx8Kw3LgHHCnjhEhAQVIMNyVTYN3ZiILrg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1347; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BN3PR0501MB1347; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1347; x-forefront-prvs: 0905A6B2C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(1096002)(11100500001)(586003)(5004730100002)(83506001)(1220700001)(33656002)(2906002)(66066001)(3280700002)(86362001)(230783001)(81166005)(3660700001)(3846002)(6116002)(2501003)(82746002)(102836003)(4326007)(19580405001)(5008740100001)(19580395003)(10400500002)(87936001)(76176999)(54356999)(50986999)(106116001)(92566002)(36756003)(2950100001)(83716003)(2900100001)(5001770100001)(5002640100001)(189998001)(77096005)(122556002)(99286002)(4001350100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1347; H:BN3PR0501MB1345.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <6A1AB5EE55C453468A97D4CE635543F3@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2016 16:07:42.8649 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1347 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Applicability of draft-ietf-tcpm-rto-consider-02 to non-IETF protocols X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 16:08:03 -0000 T24gNC83LzE2LCAxMTowMiBBTSwgInRjcG0gb24gYmVoYWxmIG9mIFNjaGFyZiwgTWljaGFlbCAo Tm9raWEgLSBERSkiIDx0Y3BtLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIG1pY2hhZWwu c2NoYXJmQG5va2lhLmNvbT4gd3JvdGU6DQoNCj5SZW1vdmluZyB0aGUgd29yZHMgInN0YW5kYXJk aXplZCIgYW5kICJJRVRGIHN0YW5kYXJkaXplZCIgc2hvdWxkIHNvcnQgdGhpcyBvdXQuDQoNCk15 IDIgY2VudHM6DQoNCkkgdGhpbmsgeW91J3JlIHN1Z2dlc3Rpbmcgd2Ugd2FsayBhIGZpbmUgbGlu ZSBiZXR3ZWVuIGJlaW5nIGNsZWFyIHRoYXQgd2UgYXJlIG5vdCBjaGFuZ2luZyBleGlzdGluZyBJ RVRGIHNwZWNzIChieSBhbGxvd2luZyBhbnkgbWVjaGFuaXNtIHdoYXRzb2V2ZXIpLCB3aGlsZSBh bHNvIG1ha2luZyB0aGlzIGdlbmVyYWxpemVkIGVub3VnaCB0byBiZSB3aWRlbHkgdXNlZnVsLiBJ IGFncmVlIHRoYXQgd291bGQgYmUgZ29vZCwgaWYgcG9zc2libGUuDQoNCldoYXQgYWJvdXQgaW5z dGVhZCBoYXZpbmcgYSBnZW5lcmFsIHN0YXRlbWVudCB0aGF0IHdlIG11c3QgdXNlIElFVEYgbWVj aGFuaXNtcyB3aGVuIGFwcGxpZWQgdG8gSUVURiBwcm90b2NvbHMsIG9yIHNvbWV0aGluZyBsaWtl IHRoYXQ/DQoNCkpvbmF0aGFuDQo= From nobody Thu Apr 7 10:34:29 2016 Return-Path: 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 A0C4F12D1A3 for ; Thu, 7 Apr 2016 10:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2aD-zyVqsMh for ; Thu, 7 Apr 2016 10:34:14 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807E912D54D for ; Thu, 7 Apr 2016 10:34:14 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id A65463BA65EBA; Thu, 7 Apr 2016 17:34:09 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u37HYCTA010273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Apr 2016 17:34:12 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u37HY6a0030674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Apr 2016 19:34:09 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.46]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 7 Apr 2016 19:34:09 +0200 From: "Scharf, Michael (Nokia - DE)" To: EXT Jonathan Looney , "mallman@icir.org" Thread-Topic: [tcpm] Applicability of draft-ietf-tcpm-rto-consider-02 to non-IETF protocols Thread-Index: AQHRkOemmQBAX5IxDU2/hMk3MxXxoJ9+umog Date: Thu, 7 Apr 2016 17:34:08 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4878217F@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D4878189A@FR712WXCHMBA15.zeu.alcatel-lucent.com> <16468.1460039314@lawyers.icir.org> <655C07320163294895BBADA28372AF5D48781BBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0960AC8F-E3AA-4950-98AC-50CD37C914F1@juniper.net> In-Reply-To: <0960AC8F-E3AA-4950-98AC-50CD37C914F1@juniper.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Applicability of draft-ietf-tcpm-rto-consider-02 to non-IETF protocols X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 17:34:27 -0000 PiA+UmVtb3ZpbmcgdGhlIHdvcmRzICJzdGFuZGFyZGl6ZWQiIGFuZCAiSUVURiBzdGFuZGFyZGl6 ZWQiIHNob3VsZCBzb3J0DQo+IHRoaXMgb3V0Lg0KPiANCj4gTXkgMiBjZW50czoNCj4gDQo+IEkg dGhpbmsgeW91J3JlIHN1Z2dlc3Rpbmcgd2Ugd2FsayBhIGZpbmUgbGluZSBiZXR3ZWVuIGJlaW5n IGNsZWFyIHRoYXQNCj4gd2UgYXJlIG5vdCBjaGFuZ2luZyBleGlzdGluZyBJRVRGIHNwZWNzIChi eSBhbGxvd2luZyBhbnkgbWVjaGFuaXNtDQo+IHdoYXRzb2V2ZXIpLCB3aGlsZSBhbHNvIG1ha2lu ZyB0aGlzIGdlbmVyYWxpemVkIGVub3VnaCB0byBiZSB3aWRlbHkNCj4gdXNlZnVsLiBJIGFncmVl IHRoYXQgd291bGQgYmUgZ29vZCwgaWYgcG9zc2libGUuDQo+IA0KPiBXaGF0IGFib3V0IGluc3Rl YWQgaGF2aW5nIGEgZ2VuZXJhbCBzdGF0ZW1lbnQgdGhhdCB3ZSBtdXN0IHVzZSBJRVRGDQo+IG1l Y2hhbmlzbXMgd2hlbiBhcHBsaWVkIHRvIElFVEYgcHJvdG9jb2xzLCBvciBzb21ldGhpbmcgbGlr ZSB0aGF0Pw0KDQpZZXMsIHRoaXMgc29tZXRoaW5nIGxpa2UgdGhhdCB3b3VsZCB3b3JrIGZvciBt ZS4NCg0KSW4gZ2VuZXJhbCwgSSB0aGluayB0aGF0IHRoaXMgZGlzY3Vzc2lvbiBzaG93cyB0aGF0 IGEgYmV0dGVyIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IGlzIG5lZWRlZCwgZS5nLiwgaW4gdGhl IGludHJvZHVjdGlvbi4gVGhhdCBjb3VsZCBiZSBhbiBhcHByb3ByaWF0ZSBwbGFjZSB0byBhZGQg c3VjaCBhIHNlbnRlbmNlLiBUaGVuLCB0aGUgdGhlIGFjdHVhbCByZXF1aXJlbWVudHMgY291bGQg YmUgbGltaXRlZCB0byB0ZWNobmljYWwgbWVjaGFuaXNtcy4NCg0KSSBiZWxpZXZlIHRoaXMgZG9j dW1lbnQgc2hvdWxkIG1vcmUgZXhwbGljaXRseSBkaXN0aW5ndWlzaCAuLi4NCg0KKGEpIEFwcGxp Y2FiaWxpdHkgdG8gVENQIGltcGxlbWVudGF0aW9ucyBub3QgbmVjZXNzYXJpbHkgZm9sbG93aW5n IHRoZSBzdGFuZGFyZHMtdHJhY2sgUkZDcyBmb3IgUlRPIGNhbGN1bGF0aW9uDQoNCihiKSBBcHBs aWNhYmlsaXR5IHRvIFJUTyBjYWxjdWxhdGlvbiBpbiBJRVRGIHByb3RvY29scyBvdGhlciB0aGFu IFRDUCBoYXZpbmcgc3RhbmRhcmRzLXRyYWNrIHNwZWNpZmljYXRpb25zDQoNCihjKSBBcHBsaWNh YmlsaXR5IHRvIFJUTyBjYWxjdWxhdGlvbnMgaW4gYW55IG90aGVyIHByb3RvY29sIHJ1bm5pbmcg aW4gdGhlIEludGVybmV0DQoNCldpdGhpbiBvdXIgY2hhcnRlciwgVENQTSBjYW4gcHVibGlzaCBu b3JtYXRpdmUgc3BlY2lmaWNhdGlvbnMgZm9yIChhKS4gUmVnYXJkaW5nIChiKSwgVENQTSdzIG1h bmRhdGUgaXMgbGltaXRlZCBzaW5jZSB0aGVyZSBhcmUgZXhpc3RpbmcgcHJvcG9zZWQgc3RhbmRh cmQgUkZDcyBmb3IgSUVURiBwcm90b2NvbHMgdGhhdCBhcmUgbm90IGZ1bGx5IGNvbXBsaWFudCB0 byB0aGlzIGxpc3Qgb2YgcmVxdWlyZW1lbnRzLiBUaGlzIGlzIHRoZSByZWFsaXR5LiBUaGVyZWZv cmUsIGl0IHNlZW1zIHRvIG1lIHRoYXQgdGhpcyBkb2N1bWVudCBuZWVkcyBhIG1vcmUgZXhwbGlj aXQgc3RhdGVtZW50IG9mIHRoZSBmb3JtICJUaGlzIGRvY3VtZW50IGRvZXMgbm90IGludGVuZCB0 byBjaGFuZ2UgYW55IGV4aXN0aW5nIElFVEYgc3RhbmRhcmQiLiAoYykgc2VlbXMgdG8gYmUgYW5v dGhlciBhcmVhIGluIHdoaWNoIHRoaXMgZG9jdW1lbnQgY2FuIGJlIHVzZWZ1bCBidXQgaWYgYSBw cm90b2NvbCBpcyBub3Qgc3RhbmRhcmRpemVkIGluIHRoZSBJRVRGIHdlIGNhbm5vdCBtYWtlIGFz c3VtcHRpb25zIGhvdyB0aGUgUlRPIG1lY2hhbmlzbSwgbG9zcyByZWNvdmVyeSwgZXRjLiBpbnRl cm5hbGx5IHdvcmtzLiBGb3IgKGMpIGEgcmVtYWluZGVyIHRoYXQgYSBwcm90b2NvbCBuZWVkcyBm dXJ0aGVyIG1lY2hhbmlzbXMgZm9yIGNvbmdlc3Rpb24gY29udHJvbCBjb3VsZCBiZSBhZGRlZCwg dG9vLg0KDQpNaWNoYWVsDQo= From nobody Thu Apr 7 17:49:39 2016 Return-Path: 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 3D2E712D0E9; Thu, 7 Apr 2016 17:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xg5Y-mvRAC5Y; Thu, 7 Apr 2016 17:49:36 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B95412D0BA; Thu, 7 Apr 2016 17:49:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B40C3180013; Thu, 7 Apr 2016 17:48:38 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160408004838.B40C3180013@rfc-editor.org> Date: Thu, 7 Apr 2016 17:48:38 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 7805 on Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 00:49:38 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7805 Title: Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status Author: A. Zimmermann, W. Eddy, L. Eggert Status: Informational Stream: IETF Date: April 2016 Mailbox: alexander@zimmermann.eu.com, wes@mti-systems.com, lars@netapp.com Pages: 8 Characters: 15754 Obsoletes: RFC 675, RFC 721, RFC 761, RFC 813, RFC 816, RFC 879, RFC 896, RFC 1078, RFC 6013 Updates: RFC 7414 I-D Tag: draft-ietf-tcpm-undeployed-03.txt URL: https://www.rfc-editor.org/info/rfc7805 DOI: http://dx.doi.org/10.17487/RFC7805 This document reclassifies several TCP extensions and TCP-related documents that either have been superseded, have never seen widespread use, or are no longer recommended for use to "Historic" status. The affected documents are RFCs 675, 721, 761, 813, 816, 879, 896, 1078, and 6013. Additionally, this document reclassifies RFCs 700, 794, 814, 817, 872, 889, 964, and 1071 to "Informational" status. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Apr 15 06:14:43 2016 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C831B12D166; Fri, 15 Apr 2016 06:14:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160415131440.15168.43269.idtracker@ietfa.amsl.com> Date: Fri, 15 Apr 2016 06:14:40 -0700 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rto-consider-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 13:14:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions of the IETF. Title : Retransmission Timeout Considerations Author : Mark Allman Filename : draft-ietf-tcpm-rto-consider-03.txt Pages : 9 Date : 2016-04-15 Abstract: Each implementation of a retransmission timeout mechanism represents a balance between correctness and timeliness and therefore no implementation suits all situations. This document provides high-level requirements for retransmission timeout schemes appropriate for general use in the Internet. Within the requirements, implementations have latitude to define particulars that best address each situation. Terminology The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rto-consider-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 15 06:22:03 2016 Return-Path: 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 16A6312E2AD for ; Fri, 15 Apr 2016 06:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jx4ArE3pTpqF for ; Fri, 15 Apr 2016 06:21:59 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83F312E306 for ; Fri, 15 Apr 2016 06:21:59 -0700 (PDT) Received: from lawyers.icir.org (obrien.ICSI.Berkeley.EDU [192.150.187.23]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u3FDLxAP006870 for ; Fri, 15 Apr 2016 06:21:59 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id CFC4F42B6A7B for ; Fri, 15 Apr 2016 09:21:58 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman In-Reply-To: <20160415131440.15168.43269.idtracker@ietfa.amsl.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Just the Way You Are X-URL-0: http://www.icir.org/mallman-files/Document86894.doc MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 15 Apr 2016 09:21:58 -0400 Message-ID: <16919.1460726518@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rto-consider-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 13:22:01 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the TCP Maintenance and > Minor Extensions of the IETF. >=20 > Title : Retransmission Timeout Considerations > Author : Mark Allman > Filename : draft-ietf-tcpm-rto-consider-03.txt > Pages : 9 > Date : 2016-04-15 Folks- This new version has two basic sets of changes: (1) I did a light editing pass over the whole document. Nothing big was changed here, but a bunch of small stuff was cleaned up. (2) I have been chatting with Michael. While we do not agree on some things, it is clear that the document's position in the world was not well described. I added a new section after the intro to address this. To my mind this is not a changing of the document's positioning at all. And, this should be completely non-controversial and is how people seem to have been reading it and commenting to me. It is a page of new text and it probably needs some editorial work (at least). So, if folks could take a look at this, I'd much appreciate it. Thanks, allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlcQ6vYACgkQWyrrWs4yIs5iIACfXOBl9ZRGXr7UhnzWARFGKoIJ /DoAoJlrdvxgU3COQQNYIUXEV4WC0SIO =YoVz -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Mon Apr 25 09:01:38 2016 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2EA12D52D; Mon, 25 Apr 2016 09:01:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160425160134.28316.99538.idtracker@ietfa.amsl.com> Date: Mon, 25 Apr 2016 09:01:34 -0700 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 16:01:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions of the IETF. Title : TCP Extended Data Offset Option Authors : Joe Touch Wesley M. Eddy Filename : draft-ietf-tcpm-tcp-edo-05.txt Pages : 23 Date : 2016-04-25 Abstract: TCP segments include a Data Offset field to indicate space for TCP options but the size of the field can limit the space available for complex options such as SACK and Multipath TCP and can limit the combination of such options supported in a single connection. This document updates RFC 793 with an optional TCP extension to that space to support the use of multiple large options. It also explains why the initial SYN of a connection cannot be extending a single segment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-edo/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-tcp-edo-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 25 09:12:49 2016 Return-Path: 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 0558212D1AB; Mon, 25 Apr 2016 09:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWvcLltCgYtU; Mon, 25 Apr 2016 09:12:31 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E8A12D52D; Mon, 25 Apr 2016 09:04:41 -0700 (PDT) Received: from [128.9.184.60] ([128.9.184.60]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u3PG46ZR022181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 25 Apr 2016 09:04:06 -0700 (PDT) To: internet-drafts@ietf.org, i-d-announce@ietf.org References: <20160425160134.28316.99538.idtracker@ietfa.amsl.com> From: Joe Touch Message-ID: <571E3FF5.7010107@isi.edu> Date: Mon, 25 Apr 2016 09:04:05 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160425160134.28316.99538.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u3PG46ZR022181 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: tcpm@ietf.org, touch@isi.edu Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 16:12:33 -0000 Hi, all, This is a placeholder update; there are no changes except to update the references as needed. Joe On 4/25/2016 9:01 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions of the IETF. > > Title : TCP Extended Data Offset Option > Authors : Joe Touch > Wesley M. Eddy > Filename : draft-ietf-tcpm-tcp-edo-05.txt > Pages : 23 > Date : 2016-04-25 > > Abstract: > TCP segments include a Data Offset field to indicate space for TCP > options but the size of the field can limit the space available for > complex options such as SACK and Multipath TCP and can limit the > combination of such options supported in a single connection. This > document updates RFC 793 with an optional TCP extension to that > space to support the use of multiple large options. It also explains > why the initial SYN of a connection cannot be extending a single > segment. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-edo/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-tcp-edo-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Apr 25 11:57:40 2016 Return-Path: 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 7C87012D601 for ; Mon, 25 Apr 2016 11:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnw3fEAEKx54 for ; Mon, 25 Apr 2016 11:57:37 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 053B812D669 for ; Mon, 25 Apr 2016 11:57:31 -0700 (PDT) Received: from dhcp-207-151.erg.abdn.ac.uk (dhcp-207-151.erg.abdn.ac.uk [139.133.207.151]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 156F21B001B9; Mon, 25 Apr 2016 20:09:46 +0100 (BST) References: <655C07320163294895BBADA28372AF5D4878189A@FR712WXCHMBA15.zeu.alcatel-lucent.com> <16468.1460039314@lawyers.icir.org> <655C07320163294895BBADA28372AF5D48781BBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0960AC8F-E3AA-4950-98AC-50CD37C914F1@juniper.net> <655C07320163294895BBADA28372AF5D4878217F@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: "Scharf, Michael (Nokia - DE)" , "tcpm@ietf.org Extensions" From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: <571E6899.3040205@erg.abdn.ac.uk> Date: Mon, 25 Apr 2016 19:57:29 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <655C07320163294895BBADA28372AF5D4878217F@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mallman@icir.org" Subject: [tcpm] Applicability of draft-ietf-tcpm-rto-consider-03 for STCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 18:57:39 -0000 On SCTP.... I've looked at the above ID and see it mentions SCTP alongside TCP. If this ID does apply to SCTP, then I'd suggest the document editor (Mark) gets some inputs from those who maintain the SCTP specs to make sure the language is also correct for SCTP. It would be wise to also post a note about the new version of the ID to TSVWG, where SCTP is normally discussed, to get feedback there. The final decision on what to do with SCTP really should come from TSVWG, although I'd expect recommendations for TCP to also apply to SCTP (unless there is a good reason). Gorry From nobody Mon Apr 25 17:20:43 2016 Return-Path: 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 5E1B412D09C for ; Mon, 25 Apr 2016 17:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVo-2frY9JDY for ; Mon, 25 Apr 2016 17:20:40 -0700 (PDT) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id A618712B00A for ; Mon, 25 Apr 2016 17:20:40 -0700 (PDT) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 187BB170C8 for ; Mon, 25 Apr 2016 17:20:40 -0700 (PDT) Date: Mon, 25 Apr 2016 17:20:40 -0700 From: hiren panchasara To: tcpm@ietf.org Message-ID: <20160426002040.GL33164@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qo7zVO9a9OQ5oQtr" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [tcpm] Discrepancy in guidance about cwnd at loss? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 00:20:42 -0000 --qo7zVO9a9OQ5oQtr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In case of Fast Recovery, what should cwnd be when the loss is realized on 3rd dupack? In RFC6675 5. Algorithm Details, (4.2) says: "ssthresh = cwnd = (FlightSize / 2) The congestion window (cwnd) and slow start threshold (ssthresh) are reduced to half of FlightSize per [RFC5681]." But looking at RFC5681 3.2. Fast Retransmit/Fast Recovery, (3) says: "The lost segment starting at SND.UNA MUST be retransmitted and cwnd set to ssthresh plus 3*SMSS." 'per [RFC5681]' seems wrong in RFC6675. Or am I missing or mis-interpreting something? Cheers, Hiren --qo7zVO9a9OQ5oQtr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJXHrRRXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lc+MH/3cYhi3HZ0xLG+XDfRgrhabZ fd84vUqqB1rb2fgbN8tk3Fj38LoywvJHPLndc9iNMAoHky2Q1Fl21F8V7eI2RkKL 2i9JlD5or4mrTpgo9VNa7PCmm21wEVBZheCxyBTCrhz2PMq5IJqRAtLuejw5gpsr UFF7ky95WDh+Bg/gJ8qa+rQPHr7axpGIgcHjuy50z6KNRlbbN6cPoefLw53QlMl0 0zYjSWYWFFXF36dDmiA6AvjDgasaycHOAYgdbNHLqYIcX3Cl0RcHUWyio7LI6ejQ QyrwyXJ4uJmBWTZTLW0lIaGh2fCr8skoKzFqQj+xVXWSLc8lVS4cP4LiXbmuJ7c= =ufyN -----END PGP SIGNATURE----- --qo7zVO9a9OQ5oQtr-- From nobody Mon Apr 25 20:09:46 2016 Return-Path: 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 7131512B05F for ; Mon, 25 Apr 2016 20:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-lg4FvC-JsA for ; Mon, 25 Apr 2016 20:09:41 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9D912B04A for ; Mon, 25 Apr 2016 20:09:41 -0700 (PDT) Received: from lawyers.icir.org (obrien.ICSI.Berkeley.EDU [192.150.187.23]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u3Q39eGC004038; Mon, 25 Apr 2016 20:09:40 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 0632643966F1; Mon, 25 Apr 2016 23:09:39 -0400 (EDT) To: hiren panchasara From: Mark Allman In-Reply-To: <20160426002040.GL33164@strugglingcoder.info> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Hey Tonight X-URL-0: http://www.icir.org/mallman-files/Document37378.doc X-URL-1: http://www.icir.org/mallman-files/Document37682.pdf X-URL-2: http://www.icir.org/mallman-files/Document88382.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 25 Apr 2016 23:09:38 -0400 Message-ID: <33933.1461640178@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] Discrepancy in guidance about cwnd at loss? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 03:09:45 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > But looking at RFC5681 3.2. Fast Retransmit/Fast Recovery, (3) says: > "The lost segment starting at SND.UNA MUST be retransmitted and cwnd set > to ssthresh plus 3*SMSS." >=20 > 'per [RFC5681]' seems wrong in RFC6675. Or am I missing or > mis-interpreting something? The plus 3*SMSS is an artificial construct to allow additional sending before loss recovery is over. You have to read through the fast recovery algorithm to see how it works. Ultimately, (1) we don't send more than FlightSize/2 and (2) cwnd is dropped back to ssthresh (i.e., FlightSize/2). So, the "per [RFC5681]" is correct. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlce2/IACgkQWyrrWs4yIs7LvACeOVNhNDnlrInDFN/LerKCOBKu v/MAn1dWolcndaLLmm12xtM2sg53GzDw =Yu7V -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Mon Apr 25 21:57:57 2016 Return-Path: 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 0A5C312B03D for ; Mon, 25 Apr 2016 21:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.697 X-Spam-Level: X-Spam-Status: No, score=-3.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wuc9H-iqcKL0 for ; Mon, 25 Apr 2016 21:57:55 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12AAA12B01B for ; Mon, 25 Apr 2016 21:57:55 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id u206so11813233wme.1 for ; Mon, 25 Apr 2016 21:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bEkK2H9gn62J/3DiP/mp8V2cIJiwDR5Xd+b12tvh0FY=; b=fm3LFOMkoRgVIAGf1ejp0VkoSXhGhELhUlJoRH7Y4/4W7/nGF5XdWM3JqlLbvzHR+Y Mjhtulwznvnp/cfMl9di5QwEPAhIdEbmrOctXYS6/ZEOgJbWx73zB/ImmoGb5S3jQASt OCq28bGCGzkSnUOZ+ahsqkgF/MSwmpi6mlct3VLUNgiNcp+WRSn1cGu9UU2wfFQTAM/I OXnBTAyp3QbGDpZafcRGBmlPNNJiEYdyv7R+Iebt8mJQ80rc70XPXC9ZngVXHdNrP8i4 oxP6iuKDcMxo3RFxpYa/N/Yo94ftp24WzvaSpj3qro7Uvs0F+E/PSgXlbqL2XKQ8trTm iAgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bEkK2H9gn62J/3DiP/mp8V2cIJiwDR5Xd+b12tvh0FY=; b=epOsdc8rA1bpiEIUiNnzSMSM7hTwbnFUV4+G550LG5rkY7WcnxTwloNc1KjaVDAUDY Nvh+bT9gZTJ9Kuy1wFgKsXc2HylFd5M0aRNsT82opHsEXwHbV6TTOS1DbqEGVivZSjSw UoDAn9xngyh0N5sgM1G43QnbwmZXlClWiv1NmQKksFtzIkbe59RQ89IWm8/D40lHlNJ+ 2XQNIx6xGCe86eDdr79HLyq/JmqYB2LZKZTvCfcvGzxJr75BZ+gCtVMoLrIuoa/5Oqgv VJI/n/MvjlnHDi49o2sKfkyz8IFUokSmx8MFjqMT4LxvMYP0fFphf4nOqVUFOk+MQ1Wh wcwQ== X-Gm-Message-State: AOPr4FWwqOOY9//fS6GZ34Z5VeBgT38AJu9YPxyKlFOZ9kXniGzOB3K0duqaTAwivjGNNVlwTjviZVJ2ecJ87MYZ X-Received: by 10.28.227.130 with SMTP id a124mr1149910wmh.2.1461646673485; Mon, 25 Apr 2016 21:57:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.153.199 with HTTP; Mon, 25 Apr 2016 21:57:13 -0700 (PDT) In-Reply-To: <33933.1461640178@lawyers.icir.org> References: <20160426002040.GL33164@strugglingcoder.info> <33933.1461640178@lawyers.icir.org> From: Yuchung Cheng Date: Mon, 25 Apr 2016 21:57:13 -0700 Message-ID: To: "mallman@icir.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Discrepancy in guidance about cwnd at loss? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 04:57:57 -0000 On Mon, Apr 25, 2016 at 8:09 PM, Mark Allman wrote: > >> But looking at RFC5681 3.2. Fast Retransmit/Fast Recovery, (3) says: >> "The lost segment starting at SND.UNA MUST be retransmitted and cwnd set >> to ssthresh plus 3*SMSS." >> >> 'per [RFC5681]' seems wrong in RFC6675. Or am I missing or >> mis-interpreting something? > > The plus 3*SMSS is an artificial construct to allow additional > sending before loss recovery is over. You have to read through the > fast recovery algorithm to see how it works. Ultimately, (1) we > don't send more than FlightSize/2 and (2) cwnd is dropped back to > ssthresh (i.e., FlightSize/2). The key is that 3*SMSS inflation magic is to deal with non-SACK situation. in RFC 6675 this is not needed b/c the sacked packets are discounted in the 'pipe' variable. Linux folded the former trick into the pipe algorithm by emulating the sacked_out counters (tcp_add_reno_sack()) when receiving DUPACKs on non-sack connections. > > So, the "per [RFC5681]" is correct. > > allman > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Tue Apr 26 00:08:17 2016 Return-Path: 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 47EC512B021 for ; Tue, 26 Apr 2016 00:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQUibXMtwYj2 for ; Tue, 26 Apr 2016 00:08:14 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45EEE1200A0 for ; Tue, 26 Apr 2016 00:08:13 -0700 (PDT) Received: from mail-yw0-f175.google.com (mail-yw0-f175.google.com [209.85.161.175]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2CF33278484 for ; Tue, 26 Apr 2016 16:08:12 +0900 (JST) Received: by mail-yw0-f175.google.com with SMTP id o66so5910336ywc.3 for ; Tue, 26 Apr 2016 00:08:12 -0700 (PDT) X-Gm-Message-State: AOPr4FWYAV69pIIUKr0g1D+JZ+Cx4dSpE8FHa4CAvZksYpdO5Ii7hF5ZQBnxajMg/NrFYsuIGdLeh1oKVw1BCA== MIME-Version: 1.0 X-Received: by 10.13.253.1 with SMTP id n1mr513566ywf.83.1461654490771; Tue, 26 Apr 2016 00:08:10 -0700 (PDT) Received: by 10.13.196.3 with HTTP; Tue, 26 Apr 2016 00:08:10 -0700 (PDT) In-Reply-To: <20160426002040.GL33164@strugglingcoder.info> References: <20160426002040.GL33164@strugglingcoder.info> Date: Tue, 26 Apr 2016 00:08:10 -0700 X-Gmail-Original-Message-ID: Message-ID: From: Yoshifumi Nishida To: hiren panchasara Content-Type: multipart/alternative; boundary=94eb2c06c9b0b51ccf05315df42a Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Discrepancy in guidance about cwnd at loss? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 07:08:16 -0000 --94eb2c06c9b0b51ccf05315df42a Content-Type: text/plain; charset=UTF-8 Hi Hiren, It's ok because the behavior will be the same in principal as Mark and Yuchung explained. Let's use a simple example. Say cwnd=4 and you've sent S1, S2, S3, S4, but S1 is lost while S2, S3, S4 have arrived at the receiver. If you follow RFC5681 description, after receiving 3 dup acks, cwnd = 2+3 = 5. In this case, the left edge of the window is S1 and the right edge will be S5 as cwnd = 5. This allows you to transmit S5. In case of RFC6675, cwnd = 2 and pipe size = 1. (because S2, S3, S4 have been SACKed) This also allows you to send S5. Thanks, -- Yoshi On Mon, Apr 25, 2016 at 5:20 PM, hiren panchasara < hiren@strugglingcoder.info> wrote: > In case of Fast Recovery, what should cwnd be when the loss is realized > on 3rd dupack? > > In RFC6675 5. Algorithm Details, (4.2) says: > "ssthresh = cwnd = (FlightSize / 2) > The congestion window (cwnd) and slow start threshold > (ssthresh) are reduced to half of FlightSize per [RFC5681]." > > But looking at RFC5681 3.2. Fast Retransmit/Fast Recovery, (3) says: > "The lost segment starting at SND.UNA MUST be retransmitted and cwnd set > to ssthresh plus 3*SMSS." > > 'per [RFC5681]' seems wrong in RFC6675. Or am I missing or > mis-interpreting something? > > Cheers, > Hiren > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > --94eb2c06c9b0b51ccf05315df42a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Hiren,

It= 's ok because the behavior will be the same in principal as Mark and Yu= chung explained.
Let's use a simple exa= mple.
Say cwnd=3D4 and you've sent S1, = S2, S3, S4, but S1 is lost while S2, S3, S4 have arrived at the receiver.
If you follow RFC5681 description, after rec= eiving 3 dup acks, cwnd =3D 2+3 =3D 5.=C2=A0
In this case, the left edge of the window is S1 and the right edge will b= e S5 as cwnd =3D 5. This allows you to transmit S5.

In case of RFC6675, cwnd =3D = 2 and pipe size =3D 1. (because S2, S3, S4 have been SACKed)
This also allows you to send S5.

Thanks,
--
Yoshi

On Mon, Apr 25, 2016 at 5:20 PM, hir= en panchasara <hiren@strugglingcoder.info> wrote:
In case of Fast Recovery, what should cwnd= be when the loss is realized
on 3rd dupack?

In RFC6675 5. Algorithm Details, (4.2) says:
"ssthresh =3D cwnd =3D (FlightSize / 2)
The congestion window (cwnd) and slow start threshold
(ssthresh) are reduced to half of FlightSize per [RFC5681]."

But looking at RFC5681 3.2.=C2=A0 Fast Retransmit/Fast Recovery, (3) says:<= br> "The lost segment starting at SND.UNA MUST be retransmitted and cwnd s= et
to ssthresh plus 3*SMSS."

'per [RFC5681]' seems wrong in RFC6675. Or am I missing or
mis-interpreting something?

Cheers,
Hiren

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm


--94eb2c06c9b0b51ccf05315df42a-- From nobody Tue Apr 26 08:40:57 2016 Return-Path: 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 5201212D505 for ; Tue, 26 Apr 2016 08:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9Em8L-8lYgU for ; Tue, 26 Apr 2016 08:40:52 -0700 (PDT) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3A96612D509 for ; Tue, 26 Apr 2016 08:40:51 -0700 (PDT) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 94F1E173F6; Tue, 26 Apr 2016 08:40:50 -0700 (PDT) Date: Tue, 26 Apr 2016 08:40:50 -0700 From: hiren panchasara To: Yuchung Cheng Message-ID: <20160426154050.GM33164@strugglingcoder.info> References: <20160426002040.GL33164@strugglingcoder.info> <33933.1461640178@lawyers.icir.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5V5c01chtBAiSHoy" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "tcpm@ietf.org Extensions" , "mallman@icir.org" Subject: Re: [tcpm] Discrepancy in guidance about cwnd at loss? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 15:40:55 -0000 --5V5c01chtBAiSHoy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On 04/25/16 at 09:57P, Yuchung Cheng wrote: > On Mon, Apr 25, 2016 at 8:09 PM, Mark Allman wrote: > > > >> But looking at RFC5681 3.2. Fast Retransmit/Fast Recovery, (3) says: > >> "The lost segment starting at SND.UNA MUST be retransmitted and cwnd set > >> to ssthresh plus 3*SMSS." > >> > >> 'per [RFC5681]' seems wrong in RFC6675. Or am I missing or > >> mis-interpreting something? > > > > The plus 3*SMSS is an artificial construct to allow additional > > sending before loss recovery is over. You have to read through the > > fast recovery algorithm to see how it works. Ultimately, (1) we > > don't send more than FlightSize/2 and (2) cwnd is dropped back to > > ssthresh (i.e., FlightSize/2). > The key is that 3*SMSS inflation magic is to deal with non-SACK > situation. Ah, okay. This is what I was missing. > in RFC 6675 this is not needed b/c the sacked packets are > discounted in the 'pipe' variable. Linux folded the former trick into > the pipe algorithm by emulating the sacked_out counters > (tcp_add_reno_sack()) when receiving DUPACKs on non-sack connections. Thanks a lot for taking time and explaining. Cheers, Hiren --5V5c01chtBAiSHoy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJXH4v8XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lspYIAJflb7hukUOvFjoE64q09yZK wtn/zaFy6oY6zbS42K6E6Fa31AHQNVX9Sc6Ubid2zJd0+h7tFSBL8GcTLffUyynZ 7rkp4TCsXGAwE6IgITwWpyQGpM/lK8IHSTpLJK6ir2mjEZROeQkcSKRJOC/N4w9Y Ne8b9j2VDatVSEI060Dyga0PvwtnV10wq7AOwBHyLGPjWdBa21f5K514rA345A/g 7+q2bEn3XuZATKw3T6ahJu5sdtbQ1M/9u6x6DeFou4D87uLHEexT55GxKS2LV7aY j8Fe64ZCWAdrAoNyQRED8h2J+CznEypnyMrXG55oYvtXz27oSVAQSgKE92DofoI= =dDi8 -----END PGP SIGNATURE----- --5V5c01chtBAiSHoy-- From nobody Tue Apr 26 08:42:11 2016 Return-Path: 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 AD15012D50A for ; Tue, 26 Apr 2016 08:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZdhH61g895m for ; Tue, 26 Apr 2016 08:42:09 -0700 (PDT) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id DF71512D4FE for ; Tue, 26 Apr 2016 08:42:09 -0700 (PDT) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id A2A1E17405; Tue, 26 Apr 2016 08:42:09 -0700 (PDT) Date: Tue, 26 Apr 2016 08:42:09 -0700 From: hiren panchasara To: Yoshifumi Nishida Message-ID: <20160426154209.GN33164@strugglingcoder.info> References: <20160426002040.GL33164@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Rzq/nSLlHy1djmXS" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Discrepancy in guidance about cwnd at loss? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 15:42:10 -0000 --Rzq/nSLlHy1djmXS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 04/26/16 at 12:08P, Yoshifumi Nishida wrote: > Hi Hiren, >=20 > It's ok because the behavior will be the same in principal as Mark and > Yuchung explained. > Let's use a simple example. > Say cwnd=3D4 and you've sent S1, S2, S3, S4, but S1 is lost while S2, S3,= S4 > have arrived at the receiver. > If you follow RFC5681 description, after receiving 3 dup acks, cwnd =3D 2= +3 =3D > 5. > In this case, the left edge of the window is S1 and the right edge will be > S5 as cwnd =3D 5. This allows you to transmit S5. >=20 > In case of RFC6675, cwnd =3D 2 and pipe size =3D 1. (because S2, S3, S4 h= ave > been SACKed) > This also allows you to send S5. Thank you for providing the example. :-) Cheers, Hiren --Rzq/nSLlHy1djmXS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJXH4xRXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/llv8H/jL8HLzK5LfYYSnfUJTKKIKU 7TtUPk4VmXGSjDDjSUoMaiSRo0xluEigSAcb5nt97gWmJotTBOBgee/rjI3hM3iV Dmxl94/hEiq+TNcqmNzLFutCFgc6F+YLCIUM/aHmwYVToYauVa1y5BC0uaecNK6n CKTpdx1z0FsX8lsEMuoX5UezOCqgr5qfj7zAX++eHXUc3dEDT4tusRL0OzQbMuX4 itbMxg2fZ4X7BmerU1A2fYp9dvDxcTa8YGZyfs5tqTdxRUxw4M34VejPQvfnwMt5 RCdcZZ20ApNnRSRre+mbBd5d8DHv1nuSkIpZGhhjE70AAP7c0+AWy0Uy4lVE+RE= =NmJ5 -----END PGP SIGNATURE----- --Rzq/nSLlHy1djmXS-- From nobody Wed Apr 27 01:13:42 2016 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0781312B03C; Wed, 27 Apr 2016 01:13:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160427081340.25273.31299.idtracker@ietfa.amsl.com> Date: Wed, 27 Apr 2016 01:13:40 -0700 Archived-At: Cc: tcpm@ietf.org, ietf@kuehlewind.net, tcpm-chairs@ietf.org Subject: [tcpm] tcpm - New Meeting Session Request for IETF 96 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 08:13:41 -0000 A new meeting session request has just been submitted by Michael Scharf, a Chair of the tcpm working group. --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Michael Scharf Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 70 Conflicts to Avoid: First Priority: tsvwg tsvarea taps mptcp tcpinc httpbis iccrg maprg accord Second Priority: rmcat rtcweb aqm dclcrg Third Priority: ippm teas Special Requests: ---------------------------------------------------------