From nobody Fri Apr 1 07:10:55 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E14612D5CA for ; Fri, 1 Apr 2016 07:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 2b1-jXuo871H for ; Fri, 1 Apr 2016 07:10:52 -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 966DA12D5EF for ; Fri, 1 Apr 2016 07:10:51 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id F2F2A1B00127 for ; Fri, 1 Apr 2016 15:23:01 +0100 (BST) Message-ID: <56FE8167.5040303@erg.abdn.ac.uk> Date: Fri, 01 Apr 2016 15:10:47 +0100 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] Agenda for the TSVWG meetings X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 14:10:54 -0000 The current meeting agenda is posted here: https://datatracker.ietf.org/meeting/95/agenda/tsvwg/ If you are a presenter, please send slides at least 48 hours before the talk, to allow me to me upload them and remote participants to download these before the meeting. Gorry & David (TSVWG CoChairs) From nobody Fri Apr 1 07:16:14 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: [tsvwg] [aqm] [tcpm] [tcpPrague] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area 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 06:22:26 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D060B12D110; Sun, 3 Apr 2016 06:22:18 -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 Tq_yoIQJcRk6; Sun, 3 Apr 2016 06:22:17 -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 9D31412D10D; Sun, 3 Apr 2016 06:22:17 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0B8B9180014; Sun, 3 Apr 2016 06:21:34 -0700 (PDT) To: touch@isi.edu, mallman@bbn.com, floyd@icir.org, craig@bbn.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160403132134.0B8B9180014@rfc-editor.org> Date: Sun, 3 Apr 2016 06:21:34 -0700 (PDT) Archived-At: Cc: mls.ietf@gmail.com, rfc-editor@rfc-editor.org, iesg@ietf.org, tsvwg@ietf.org Subject: [tsvwg] [Errata Verified] RFC3390 (4583) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 13:22:18 -0000 The following errata report has been verified for RFC3390, "Increasing TCP's Initial Window". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3390&eid=4583 -------------------------------------- Status: Verified Type: Technical Reported by: Joe Touch Date Reported: 2016-01-06 Verified by: Martin Stiemerling (IESG) Section: 1. Original Text ------------- This increased initial window is optional: a TCP MAY start with a larger initial window. However, we expect that most general-purpose TCP implementations would choose to use the larger initial congestion window given in equation (1) above. Corrected Text -------------- This increased initial window is optional: a TCP MAY start with a smaller initial window. However, we expect that most general-purpose TCP implementations would choose to use the larger initial congestion window given in equation (1) above. Notes ----- The MAY allows use of values smaller than this document allows, not larger. -------------------------------------- RFC3390 (draft-ietf-tsvwg-initwin-04) -------------------------------------- Title : Increasing TCP's Initial Window Publication Date : October 2002 Author(s) : M. Allman, S. Floyd, C. Partridge Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From nobody Sun Apr 3 14:38:16 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B6312D646; Sun, 3 Apr 2016 14:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.312 X-Spam-Level: X-Spam-Status: No, score=-4.312 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_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 Xtt1liHUzoKj; Sun, 3 Apr 2016 14:38:11 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (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 DC81012D5FE; Sun, 3 Apr 2016 14:38:10 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u33Lc70O005347 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 3 Apr 2016 17:38:07 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com u33Lc70O005347 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1459719488; bh=Utr270PHcC+15W8uDEcsPH3ROr4=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=hKk+niErKWgZaLgkcjbxoNBmQkmnr0g5PlB5Q9FBY2NC1k2I0oz2HnBptexu4EZxh mNvCYEtNnxopnLg00HGjZKBqD1+VLA2CAoxCRCe9Qp/9DWLbdL7c1keB7a0yA7uRz6 tWbeNcRXsvL8DjWooePz9ur5Sa2nCf5KGhWPBmuY= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com u33Lc70O005347 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd03.lss.emc.com (RSA Interceptor); Sun, 3 Apr 2016 17:36:32 -0400 Received: from MXHUB220.corp.emc.com (MXHUB220.corp.emc.com [10.253.68.90]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u33LbtK4028819 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Sun, 3 Apr 2016 17:37:56 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.70]) by MXHUB220.corp.emc.com ([10.253.68.90]) with mapi id 14.03.0266.001; Sun, 3 Apr 2016 17:37:55 -0400 From: "Black, David" To: Magnus Westerlund , Cullen Jennings Thread-Topic: [tsvwg] Last Call: (DSCP and other packet markings for WebRTC QoS) to Proposed Standard Thread-Index: AQHRg5nK94t/8iR5sU+B/9y+8LxFIp9nE2eAgADT/gCACkcQgIAGp9UQ Date: Sun, 3 Apr 2016 21:37:54 +0000 Message-ID: References: <20160321174750.31944.71903.idtracker@ietfa.amsl.com> <56F26AD3.3010403@ericsson.com> <5BB71158-3530-47A2-9A33-811F65B2F677@iii.ca> <56FBBBC1.5060902@ericsson.com> In-Reply-To: <56FBBBC1.5060902@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.47.120] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "tsvwg@ietf.org" , "draft-ietf-tsvwg-rtcweb-qos@ietf.org" , "ietf@ietf.org" , "tsvwg-chairs@ietf.org" Subject: Re: [tsvwg] Last Call: (DSCP and other packet markings for WebRTC QoS) to Proposed Standard X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 21:38:12 -0000 I see a couple of Magnus's points that appear to need additional text in the draft: [1] Flow Type in application-facing browser API: > >>>> o Flow Type: The browser provides this input as it knows if > >>>> the flow is audio, interactive video with or without audio, > >>>> non-interactive video with or without audio, or data. [... snip ...] > The main issue here is that to me it was not clear that "Interactive > Video with or without audio" allows for setting these DSCP values also > for the RTP stream containing audio also. This, I do see a need for > clarification on. Propose an additional sentence: OLD o Flow Type: The browser provides this input as it knows if the flow is audio, interactive video with or without audio, non-interactive video with or without audio, or data. NEW o Flow Type: The browser provides this input as it knows if the flow is audio, interactive video with or without audio, non-interactive video with or without audio, or data. For audio that is associated with a video flow, the flow type of the associated video MAY be used instead of the associated audio type. I hesitate to say anything stronger than "MAY" here. [2] What does "interactive" mean in an implementation?: > The issue is that this document is called: DSCP and other packet > markings for WebRTC QoS. Then this document define something that is not > immediately mappable onto what is being defined in the other WebRTC > specifications. That is why I am raising that there need to be more > clear coupling. If that coupling is to mostly happen in another > document, can we at least then have a proposal on the table for that > change to ensure that the result is understandable. Well, this TSVWG draft is definitely not the right place for a discussion o= f when a video flow is interactive or non-interactive - I hope we can agree on that. Beyond that, as Cullen (Jennings) is both an author of this document and one of the chairs of the rtcweb WG, I'd suggest that he and/or the rtcweb WG propose an appropriate location for discussion of when a video flow is interactive or non-interactive. This TSVWG draft would then have an additional sentence added, e.g., See [TBD] for further discussion of how to determine whether a video flow is interactive vs. non-interactive. I believe that the added reference here ([TBD] above) would be normative. Cullen? Thanks, --David (as document shepherd) > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Wednesday, March 30, 2016 7:43 AM > To: Cullen Jennings > Cc: ietf@ietf.org; tsvwg-chairs@ietf.org; draft-ietf-tsvwg-rtcweb-qos@iet= f.org; > tsvwg@ietf.org > Subject: Re: [tsvwg] Last Call: (DSC= P and > other packet markings for WebRTC QoS) to Proposed Standard >=20 > Den 2016-03-23 kl. 23:46, skrev Cullen Jennings: > > > >> On Mar 23, 2016, at 3:07 AM, Magnus Westerlund > >> wrote: > >> > >> Hi, > >> > >> Below is the first round on a question, that looks like it needs to > >> be addressed, thus I bring it into a public discussion. > >> > >> Den 2016-03-22 kl. 19:48, skrev Paul E. Jones: > >>>> The other comment I have is the following: > >>>> > >>>> o Flow Type: The browser provides this input as it knows if > >>>> the flow is audio, interactive video with or without audio, > >>>> non-interactive video with or without audio, or data. > >>>> > >>>> Yes, a browser knows if a MediaStreamTrack's source is a live > >>>> source, i.e. camera or microphone or a file. Which would > >>>> indicate the difference between interactive or non. However, I > >>>> don't understand what the Flow Type description for video > >>>> contains "with or without audio" as the flow definitions in > >>>> RTCWEB transport document all indicate flows as containing a > >>>> single media type. Can you please clarify? > >>> > >>> This relates to the table that follows. The intent is that if a > >>> WebRTC application is sending audio and video (e.g., a > >>> videoconference call), then the same DSCP values might be used > >>> for both the audio and video flows. On the other hand, if only a > >>> video flow is sent alone (perhaps the audio source is an entirely > >>> different device), then the browser can still use the same packet > >>> marking. > >>> > >> > >> So, I started commenting on this because, the "Flow Types" in the > >> table are not really defined. And my interpretation was not that > >> the audio could be given the same markings as the Video. I only > >> interpreted it as being valid for the video flow. Thus, I think the > >> actual "flow type" values in Table 1 needs to be better defined. To > >> my knowledge these types are not defined in any other RTCWeb > >> document. > > > > Which codec it came from make is pretty clear if it is audio or video > > in the browser implementation. The word "flow" has many meanings in > > all the different contexts but it seems like section 4 is pretty > > clear on breaking flow down into media and data types then breaking > > media down into the various types in the table and defining them. > > > > Are you getting at the issue of it a audio stream that is with a > > synchronized video stream can use the same markings as the video > > stream ? This tries to leave the options open and let people read > > things like Section 4 of RFC 7657. >=20 > The main issue here is that to me it was not clear that "Interactive > Video with or without audio" allows for setting these DSCP values also > for the RTP stream containing audio also. This, I do see a need for > clarification on. >=20 > The Interactive vs Non-Interactive I do have an interpretation of what > it means. However, I fail to see how a WebRTC browser implementation is > going to be able to make that determination, and there are no API point > for indicating this distinction for the moment. But, I am fine to let > that through. >=20 > >> > >> I think what is needed is a definition list for what is meant. I > >> can see that pointers for example into RFC 4594 may help making > >> these definitions more compact. > >> > >> One thing that might be a bit tricky is actually the difference > >> between interactive and non-interactive (streaming) usages of > >> WebRTC RTP streams. It becomes a question if the WebRTC endpoint > >> actually accurately can classify these differences. > > > > We decided at some point that if the browser is using SRTP, it is > > assumed to be interactive and the webrtc specs point at using this. > > If it is streamed over HTTP with something like DASH then it is non > > interactive and browsers could use the non interactive markings but I > > don't think any of the streaming media docs have been updated yet to > > point that out. >=20 > I agree with that. I also think there could be a potential development > where one could use video over RTP in a PeerConnection with a tweaked > configuration, much more delay tolerant that could be used also for > non-interactive delivery. But, that is just a potential future > modification or extension. >=20 > > > >> Yes, a live media source, like an camera or microphone can on first > >> order be used for classification as interactive, while a file > >> source is non-interactive. But even the first, can in the > >> application context be non-interactive. An example would be an > >> lecturer application. Relaxing the delay from the lecturer to the > >> audience is likely fine, especially if one have a "raise hand" > >> mechanism and only explicitly invites participants to ask > >> questions. To my knowledge there are no API surface to indicate > >> these preferences on the MediaStream or MediaStreamTrack level. > >> > >> I think this document have a potential valuable difference for the > >> interactive vs non-interactive, but the rest of the current > >> solution has difficulties to utilize this difference. From my > >> perspective I am fine with retaining the difference, but the > >> definition must be clear so that implementers select the right one. > >> And likely the non-interactive will not be much utilized until > >> additional API knobs are created. > > > > Agree but I think it is the WebRTC spec that needs to be clear on > > that, not this draft. >=20 > The issue is that this document is called: DSCP and other packet > markings for WebRTC QoS. Then this document define something that is not > immediately mappable onto what is being defined in the other WebRTC > specifications. That is why I am raising that there need to be more > clear coupling. If that coupling is to mostly happen in another > document, can we at least then have a proposal on the table for that > change to ensure that the result is understandable. >=20 > cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From nobody Mon Apr 4 04:48:24 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 544BE12D58E; Mon, 4 Apr 2016 04:48:24 -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: <20160404114824.15614.298.idtracker@ietfa.amsl.com> Date: Mon, 04 Apr 2016 04:48:24 -0700 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-circuit-breaker-15.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 11:48:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group of the IETF. Title : Network Transport Circuit Breakers Author : Godred Fairhurst Filename : draft-ietf-tsvwg-circuit-breaker-15.txt Pages : 27 Date : 2016-04-04 Abstract: This document explains what is meant by the term "network transport Circuit Breaker" (CB). It describes the need for circuit breakers for network tunnels and applications when using non-congestion- controlled traffic, and explains where circuit breakers are, and are not, needed. It also defines requirements for building a circuit breaker and the expected outcomes of using a circuit breaker within the Internet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-circuit-breaker/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-circuit-breaker-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-circuit-breaker-15 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 4 04:54:41 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A61C012D5B4; Mon, 4 Apr 2016 04:54: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: <20160404115437.15658.41167.idtracker@ietfa.amsl.com> Date: Mon, 04 Apr 2016 04:54:37 -0700 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc5405bis-11.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 11:54:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group of the IETF. Title : UDP Usage Guidelines Authors : Lars Eggert Godred Fairhurst Greg Shepherd Filename : draft-ietf-tsvwg-rfc5405bis-11.txt Pages : 54 Date : 2016-04-04 Abstract: The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of ECN, DSCPs, and ports. Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP. Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control. This document obsoletes RFC5405 and adds guidelines for multicast UDP usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc5405bis-11 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 4 05:39:29 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA06812D665 for ; Mon, 4 Apr 2016 05:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.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 0T76Qe-NvVMk for ; Mon, 4 Apr 2016 05:39:25 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 A08E212D174 for ; Mon, 4 Apr 2016 05:39:20 -0700 (PDT) Received: by mail-ig0-x231.google.com with SMTP id gy3so15988971igb.0 for ; Mon, 04 Apr 2016 05:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:mime-version:thread-index:date:message-id:subject:to:cc; bh=H7tMQ+czeKH/kSW/dTQZTtDyC8kKC8LDy8gEU0YVMgM=; b=17YzoOTOe9eqJRMd+oWD5zRtJ5QVkgE1qRsWo/B7Co3PnZ2Afcb/2p5+unrSxmZXBi WLVycdg3lQ4feUWPJpU73ETg7y02j4TQV/myOg4GolwAYmbND8kegsUgS2MP5mF3g0co 2IHPRHy672I7iTVsitGVpmflQibf1P9hpq6KU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:cc; bh=H7tMQ+czeKH/kSW/dTQZTtDyC8kKC8LDy8gEU0YVMgM=; b=OVcELzy/vuYnTx/F8Xpj5MMg8Vy339a22ib975w8i1/F+Vb4Yb3ujxWONZk7NTcG4e y65STl7/9/EAZjcFh9D3HPCKJSvwSMvKwhMvGsKI2QM/7lmBxEZMPNOR02AZw4evZqg+ /v0Ct/naxhoNWc0NXh4biL3cV9dkH3N7qgPgn80za/pmIGvQEB94V0XLtbdPvOwB9ta1 r5LgZF5L64NZKHphuoS5B0gEwVDLRpciph9kQj5P4KkZstR86nOcBvjZnGJkKRqGuuuT bGXJDjUIXVPmoOKu9n4v7EcIXZyUBt1luKTllTmbQWfpG3cOPVTJqc0mjJOK6ysH5R0S 6sMw== X-Gm-Message-State: AD7BkJIbOnDi5gtCMtZkk6R9XU0AYGSgtiMMeg5s/BGInJfD1l8nreyTFtPt4PribMIo6tMJYkMhZ4Eou7XwNS+M5I0p8+0gssVh4bqgYxxw6RwwmOCDChunf9ayl9Lehw7HBE7q X-Received: by 10.50.43.194 with SMTP id y2mr10831129igl.96.1459773559730; Mon, 04 Apr 2016 05:39:19 -0700 (PDT) From: Karen Elisabeth Egede Nielsen MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdGOYVpB/N7NmGOQTDKtdmVNCq4D9Q== Date: Mon, 4 Apr 2016 14:39:18 +0200 Message-ID: <05a409ec6bf076f1904f5a6f81441d33@mail.gmail.com> To: Michael Tuexen Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] Comments to draft-ietf-tsvwg-sctp-ndata-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 12:39:28 -0000 Hi Michael, tsvwg I support the progress of this document in the IETF process with the following comments: (The comments are not new but applied to version 04 as well, e.g. , see email July 06, 2015, copied in below.). Section 1: "However, the lower 16-bit of the MID can be used as the SSN if necessary." No this is not feasible unless it is made negotiable whether 16-bit or 32-bits are used for SSN. Section 1: "Please note that the serial number arithmetic defined in [RFC1982] using SERIAL_BITS = 32 applies. Therefore the sender MUST NOT have more than 2**31 - 1 ordered messages for each outgoing stream in flight and MUST NOT have more than 2**31 - 1 unordered messages for each outgoing stream in flight." Hmm... from RFC4960 we have: "An endpoint SHOULD NOT transmit a DATA chunk with a TSN that is more than 2**31 - 1 above the beginning TSN of its current send window. Doing so will cause problems in comparing TSNs." This means that SCTP can never ever have more than 2**31 - 1 messages in flight. Perhaps the "MUST NOT" above technically is correct, but I would prefer that it is explained that by RFC4960 TSN arithmetic and the SHOULD NOT, having more than 2**31 - 1 in flight SHOULD NOT happen anyway. Section 2.3.2: "Since most schedulers require late TSN assignment, it should be noted that the implementation of [RFC6525] needs to handle this." Not only do most schedulars require late TSN assignment, but any scheduler supporting interleaving indeed does this. Perhaps this could be emphasized. The pointer to that RFC6525 have an issue is now here. This is good. Given that this is the first RFC which requires for late TSN assignment, I wonder if one could not here in this RFC say how this issue is assumed to be tackled by an RFC6525 implementation. Even more so that I think that we have general agreement on what the solution should be. I.e., delay until TSN has been assigned. BR, Karen >-----Original Message----- >From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Michael Tuexen >Sent: Monday, July 06, 2015 9:24 PM >To: Karen Elisabeth Egede Nielsen >Cc: tsvwg@ietf.org >Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-03.txt > > >> On 19 May 2015, at 10:12, Karen Elisabeth Egede Nielsen >> wrote >> >> Hi Michael, >> >> Probably you have a version 04 soon in store. Anyway I hope that the >following comments may be useful.. >> We have discussed some in person or in written before I believe. >Hi Karen, > >thank you very much for the review. Please see my comments in-line. > >Best regards >Michael >> >> 1. Section 2.1: "However, the lower >> 16-bit of the MID can be used as the SSN if necessary." >> >> This is not an option unless we make it negotiable if 16-bit or >> 32-bits are >used for SSN. >OK. Sentence removed. >> >> 2. Section 2.1: References to 32-bit arithmetic of SSN/MID and FSN. >> >> The TSN number is 32-bit only with 32-bit arithmetic. Consequently >> there can be a most 2^31-1 outstanding messages on an association period. >Whether one apply 32-bit arithmetic or not to the 32-bit of the >SSN/MIDs or FSN is not significant. >Not sure. Need to think about it. >> > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: 21. marts 2016 16:57 > To: i-d-announce@ietf.org > Cc: tsvwg@ietf.org > Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-05.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Area Working Group of the IETF. > > Title : Stream Schedulers and User Message Interleaving > for the > Stream Control Transmission Protocol > Authors : Randall R. Stewart > Michael Tuexen > Salvatore Loreto > Robin Seggelmann > Filename : draft-ietf-tsvwg-sctp-ndata-05.txt > Pages : 18 > Date : 2016-03-21 > > Abstract: > The Stream Control Transmission Protocol (SCTP) is a message oriented > transport protocol supporting arbitrary large user messages. > However, the sender can not interleave different user messages which > causes head of line blocking at the sender side. To overcome this > limitation, this document adds a new data chunk to SCTP. > > Whenever an SCTP sender is allowed to send a user data, it can > possibly choose from multiple outgoing SCTP streams. Multiple ways > for this selection, called stream schedulers, are defined. Some of > them don't require the support of user message interleaving, some do. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-ndata-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 4 17:19:57 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D87012D113 for ; Mon, 4 Apr 2016 17:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.co.uk 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 pt64dTJPDf8V for ; Mon, 4 Apr 2016 17:19:48 -0700 (PDT) Received: from nm48.bullet.mail.ne1.yahoo.com (nm48.bullet.mail.ne1.yahoo.com [98.138.120.55]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 699C412D124 for ; Mon, 4 Apr 2016 17:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1459815587; bh=LSp2ZIDzvLkOqu1CrFGcPGqwT8GS5v3drFSnngOZ+PM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=H3KkG28nJ3oFVg13jc+MwWvoMTz/ygRmZspccyRrvEHM7Mt2s9TnCw1vsFhy+cRoNEWVb7KwI3GDk6Po22/IMJ1WLIRD/5t2N/Ddv5ewLRbDyygssHRl6M5Z/BSio1M3PMDLvH4CRPBltVJgrUWmiWpBGvohSkZnjiwo4cv3mcCBKORRwtRPV5cQgVN9KgSvtOM+w5q7Yfn0H/JP4rM1vqPr4TUjJgwzHrxyNxFNs46O1Z0OhvBqKAXkHCkwGrU2/jKX66u1nU68VFYlexvuyXLn1mS2fsOPmOfDypyskbuPejGgFmpM5oMXtD5VCEqKfaNvSaRIa+SsNS+tp15y2Q== Received: from [127.0.0.1] by nm48.bullet.mail.ne1.yahoo.com with NNFMP; 05 Apr 2016 00:19:47 -0000 Received: from [98.138.226.177] by nm48.bullet.mail.ne1.yahoo.com with NNFMP; 05 Apr 2016 00:16:46 -0000 Received: from [212.82.98.58] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 05 Apr 2016 00:16:46 -0000 Received: from [212.82.98.70] by tm11.bullet.mail.ir2.yahoo.com with NNFMP; 05 Apr 2016 00:16:46 -0000 Received: from [127.0.0.1] by omp1007.mail.ir2.yahoo.com with NNFMP; 05 Apr 2016 00:16:46 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 745606.80653.bm@omp1007.mail.ir2.yahoo.com X-YMail-OSG: 5yiVQ7gVM1kmzehSjB2oJY2ny5csu508ReB4menI.tXmJV47JV4LsNiSqgRxunL ZN1n4V790rw_EvkIVmdYaYLo_FVRE5bi6Ltn9Tykh.7nA5IjcCyYzDJD5.NhPVSSVAKhwjkrlb5m zStZbxQbyVEwCmaZ2RqYztbZBw2_3iSMufLSMbsKUuqeDROqGeoF0VXHqU9PjBPZCMXXqYFye.wS aa3373R0HcwPEVFkmiOM1A_1Hjp0BCXoUN7m28LEyWqz4BkbMdUOXLQSfu0uLjWmk_m7KrCpZRHx jSe0kpIwwiaRowP5zkJYo0BNggHT.oCsdIhWvlT6vio..unQP07IrlO.61TL_DbDJXa8CYLG6Rse puKxAEyY44o8nWO577auBtdivKbq9jHxwNE1ct6ly95eeIwIkuG1ttQLCABchrthJqRO9polE461 JvFOBLEU.ll0qm4JwDffFNewWpGOPlA2w81sf65r82J8F4_OuPTJFVgaDr1xjmmgLEP3rBcYMOrl FkRZ8DEn8QqYXsPTCcis72CPauS_reR71mKzE Received: by 217.12.9.11; Tue, 05 Apr 2016 00:16:46 +0000 Date: Tue, 5 Apr 2016 00:16:30 +0000 (UTC) From: To: RFC Errata System , "touch@isi.edu" , "mallman@bbn.com" , "floyd@icir.org" , "craig@bbn.com" Message-ID: <2057219261.4590383.1459815390909.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20160403132134.0B8B9180014@rfc-editor.org> References: <20160403132134.0B8B9180014@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "mls.ietf@gmail.com" , "iesg@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [Errata Verified] RFC3390 (4583) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lloyd.wood@yahoo.co.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 00:19:51 -0000 "a TCP MAY start" a TCP what? session? flow? transaction? tunnel? DoS attack? thanks L. Lloyd Wood lloyd.wood@yahoo.co.uk http://about.me/lloydwood ----- Original Message ----- From: RFC Errata System To: touch@isi.edu; mallman@bbn.com; floyd@icir.org; craig@bbn.com Cc: mls.ietf@gmail.com; rfc-editor@rfc-editor.org; iesg@ietf.org; tsvwg@ietf.org Sent: Sunday, 3 April 2016, 23:21 Subject: [tsvwg] [Errata Verified] RFC3390 (4583) The following errata report has been verified for RFC3390, "Increasing TCP's Initial Window". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3390&eid=4583 -------------------------------------- Status: Verified Type: Technical Reported by: Joe Touch Date Reported: 2016-01-06 Verified by: Martin Stiemerling (IESG) Section: 1. Original Text ------------- This increased initial window is optional: a TCP MAY start with a larger initial window. However, we expect that most general-purpose TCP implementations would choose to use the larger initial congestion window given in equation (1) above. Corrected Text -------------- This increased initial window is optional: a TCP MAY start with a smaller initial window. However, we expect that most general-purpose TCP implementations would choose to use the larger initial congestion window given in equation (1) above. Notes ----- The MAY allows use of values smaller than this document allows, not larger. -------------------------------------- RFC3390 (draft-ietf-tsvwg-initwin-04) -------------------------------------- Title : Increasing TCP's Initial Window Publication Date : October 2002 Author(s) : M. Allman, S. Floyd, C. Partridge Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From nobody Mon Apr 4 17:26:21 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5F012D130; Mon, 4 Apr 2016 17:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 57yfA-wO1RHb; Mon, 4 Apr 2016 17:26:12 -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 754AB12D113; Mon, 4 Apr 2016 17:26:12 -0700 (PDT) Received: from [128.9.184.182] ([128.9.184.182]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u350PoDl023587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 4 Apr 2016 17:25:50 -0700 (PDT) To: lloyd.wood@yahoo.co.uk, RFC Errata System , "mallman@bbn.com" , "floyd@icir.org" , "craig@bbn.com" References: <20160403132134.0B8B9180014@rfc-editor.org> <2057219261.4590383.1459815390909.JavaMail.yahoo@mail.yahoo.com> From: Joe Touch Message-ID: <5703060D.6090901@isi.edu> Date: Mon, 4 Apr 2016 17:25:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <2057219261.4590383.1459815390909.JavaMail.yahoo@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u350PoDl023587 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "mls.ietf@gmail.com" , "tsvwg@ietf.org" , "iesg@ietf.org" , touch@isi.edu Subject: Re: [tsvwg] [Errata Verified] RFC3390 (4583) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 00:26:14 -0000 In the context of the document, it's clear that this refers to starting a connection. I don't think this is ambiguous except in taken out of context, as below. Joe On 4/4/2016 5:16 PM, lloyd.wood@yahoo.co.uk wrote: > "a TCP MAY start" > > a TCP what? session? flow? transaction? tunnel? DoS attack? > > thanks > > L. > > Lloyd Wood lloyd.wood@yahoo.co.uk http://about.me/lloydwood > > > ----- Original Message ----- > From: RFC Errata System > To: touch@isi.edu; mallman@bbn.com; floyd@icir.org; craig@bbn.com > Cc: mls.ietf@gmail.com; rfc-editor@rfc-editor.org; iesg@ietf.org; tsvwg@ietf.org > Sent: Sunday, 3 April 2016, 23:21 > Subject: [tsvwg] [Errata Verified] RFC3390 (4583) > > The following errata report has been verified for RFC3390, > "Increasing TCP's Initial Window". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3390&eid=4583 > > -------------------------------------- > Status: Verified > Type: Technical > > Reported by: Joe Touch > Date Reported: 2016-01-06 > Verified by: Martin Stiemerling (IESG) > > Section: 1. > > Original Text > ------------- > This increased initial window is optional: a TCP MAY start with a > larger initial window. However, we expect that most general-purpose > TCP implementations would choose to use the larger initial congestion > window given in equation (1) above. > > Corrected Text > -------------- > This increased initial window is optional: a TCP MAY start with a > smaller initial window. However, we expect that most general-purpose > TCP implementations would choose to use the larger initial congestion > window given in equation (1) above. > > Notes > ----- > The MAY allows use of values smaller than this document allows, not larger. > > -------------------------------------- > RFC3390 (draft-ietf-tsvwg-initwin-04) > -------------------------------------- > Title : Increasing TCP's Initial Window > Publication Date : October 2002 > Author(s) : M. Allman, S. Floyd, C. Partridge > Category : PROPOSED STANDARD > Source : Transport Area Working Group > Area : Transport > Stream : IETF > Verifying Party : IESG > From nobody Mon Apr 4 22:10:06 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7683A12D1A0 for ; Mon, 4 Apr 2016 22:10:04 -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: <20160405051004.26462.89694.idtracker@ietfa.amsl.com> Date: Mon, 04 Apr 2016 22:10:04 -0700 From: IETF Secretariat Archived-At: Subject: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 05:10:04 -0000 Changed milestone "Submit 'UDP Usage Guidelines' as a BCP RFC", resolved as "Done". URL: https://datatracker.ietf.org/wg/tsvwg/charter/ From nobody Tue Apr 5 04:39:35 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D525612D8F6 for ; Tue, 5 Apr 2016 04:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 x2GuwESQyzP1 for ; Tue, 5 Apr 2016 04:39:28 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5807212D8CE for ; Tue, 5 Apr 2016 04:39:22 -0700 (PDT) Received: from dhcp-9bda.meeting.ietf.org (dhcp-9bda.meeting.ietf.org [31.133.155.218]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 6F07C721E280E; Tue, 5 Apr 2016 13:39:18 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Tuexen In-Reply-To: <05a409ec6bf076f1904f5a6f81441d33@mail.gmail.com> Date: Tue, 5 Apr 2016 08:39:12 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <05a409ec6bf076f1904f5a6f81441d33@mail.gmail.com> To: Karen Elisabeth Egede Nielsen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Comments to draft-ietf-tsvwg-sctp-ndata-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 11:39:32 -0000 > On 04 Apr 2016, at 09:39, Karen Elisabeth Egede Nielsen = wrote: >=20 > Hi Michael, tsvwg >=20 > I support the progress of this document in the IETF process with the > following comments: > (The comments are not new but applied to version 04 as well, e.g. , = see > email July 06, 2015, copied in below.). >=20 > Section 1: >=20 > "However, the lower > 16-bit of the MID can be used as the SSN if necessary." >=20 > No this is not feasible unless it is made negotiable whether 16-bit or > 32-bits are > used for SSN. I was thinking about using it in the API. We are reporting on the = receiver side the SSN which was received. My current thinking is that we don't change that, just report the lower 16 bit of the MID. Do you agree, the this is a way to go. I agree that the above wording is bad and needs to be improved. Best regards Michael >=20 > Section 1: >=20 > "Please note that the > serial number arithmetic defined in [RFC1982] using SERIAL_BITS =3D= > 32 applies. Therefore the sender MUST NOT have more than 2**31 - > 1 ordered messages for each outgoing stream in flight and MUST = NOT > have more than 2**31 - 1 unordered messages for each outgoing > stream in flight." >=20 > Hmm... from RFC4960 we have: >=20 > "An endpoint SHOULD NOT transmit a DATA chunk with a TSN that is more > than 2**31 - 1 above the beginning TSN of its current send window. > Doing so will cause problems in comparing TSNs." >=20 > This means that SCTP can never ever have more than 2**31 - 1 messages = in > flight. > Perhaps the "MUST NOT" above technically is correct, but I would = prefer that > it is explained that > by RFC4960 TSN arithmetic and the SHOULD NOT, having more than 2**31 - = 1 in > flight SHOULD NOT happen anyway. >=20 > Section 2.3.2: >=20 > "Since most schedulers require late TSN assignment, it should be = noted > that the implementation of [RFC6525] needs to handle this." >=20 > Not only do most schedulars require late TSN assignment, but any = scheduler > supporting interleaving indeed does this. > Perhaps this could be emphasized. >=20 > The pointer to that RFC6525 have an issue is now here. This is good. = Given > that this is the first RFC which requires for late TSN assignment, > I wonder if one could not here in this RFC say how this issue is = assumed to > be tackled by an RFC6525 implementation. Even more so that I think = that we > have general agreement on what the solution should be. I.e., delay = until > TSN has been assigned. >=20 > BR, Karen >=20 >> -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Michael = Tuexen >> Sent: Monday, July 06, 2015 9:24 PM >> To: Karen Elisabeth Egede Nielsen >> Cc: tsvwg@ietf.org >> Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-03.txt >>=20 >>=20 >>> On 19 May 2015, at 10:12, Karen Elisabeth Egede Nielsen >>> wrote >>>=20 >>> Hi Michael, >>>=20 >>> Probably you have a version 04 soon in store. Anyway I hope that the >> following comments may be useful.. >>> We have discussed some in person or in written before I believe. >> Hi Karen, >>=20 >> thank you very much for the review. Please see my comments in-line. >>=20 >> Best regards >> Michael >>>=20 >>> 1. Section 2.1: "However, the lower >>> 16-bit of the MID can be used as the SSN if necessary." >>>=20 >>> This is not an option unless we make it negotiable if 16-bit or >>> 32-bits are >> used for SSN. >> OK. Sentence removed. >>>=20 >>> 2. Section 2.1: References to 32-bit arithmetic of SSN/MID and FSN. >>>=20 >>> The TSN number is 32-bit only with 32-bit arithmetic. Consequently >>> there can be a most 2^31-1 outstanding messages on an association = period. >> Whether one apply 32-bit arithmetic or not to the 32-bit of the >> SSN/MIDs or FSN is not significant. >> Not sure. Need to think about it. >>>=20 >=20 >> -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: 21. marts 2016 16:57 >> To: i-d-announce@ietf.org >> Cc: tsvwg@ietf.org >> Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-05.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Transport Area Working Group of the = IETF. >>=20 >> Title : Stream Schedulers and User Message = Interleaving >> for the >> Stream Control Transmission Protocol >> Authors : Randall R. Stewart >> Michael Tuexen >> Salvatore Loreto >> Robin Seggelmann >> Filename : draft-ietf-tsvwg-sctp-ndata-05.txt >> Pages : 18 >> Date : 2016-03-21 >>=20 >> Abstract: >> The Stream Control Transmission Protocol (SCTP) is a message = oriented >> transport protocol supporting arbitrary large user messages. >> However, the sender can not interleave different user messages = which >> causes head of line blocking at the sender side. To overcome this >> limitation, this document adds a new data chunk to SCTP. >>=20 >> Whenever an SCTP sender is allowed to send a user data, it can >> possibly choose from multiple outgoing SCTP streams. Multiple ways >> for this selection, called stream schedulers, are defined. Some of >> them don't require the support of user message interleaving, some = do. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-05 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-sctp-ndata-05 >>=20 >>=20 >> 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. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 5 04:45:14 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA13612D8FF for ; Tue, 5 Apr 2016 04:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.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 RP8F78NTy0Gh for ; Tue, 5 Apr 2016 04:45:09 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 E049F12D900 for ; Tue, 5 Apr 2016 04:45:00 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id a129so15389355ioe.0 for ; Tue, 05 Apr 2016 04:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=vvnAas94XSQwSUrn34orb3AwcWXgMyGaWFog+5o8gnk=; b=499kVKKau3qCMCcpEClmNHqb1i02mO8KQ7yUUV/6eDjUqvCa7tX/fNgXl5zMFcsUgf Reve10Kt3q4F478ymsf4HGRzFJwXkegFSrrK7461ZZlE2I5e5qTm/EqUDzlRMdGxpNE3 TFLCy8MQ1KOigaO4qK8duL84TwPv0WdbSI7tc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=vvnAas94XSQwSUrn34orb3AwcWXgMyGaWFog+5o8gnk=; b=P4jW7RdQBIzqwJGtiRWbMFeKmuh9aezRXJmksN+M4gUZ8IsnGIeSY0KIwh5PG3MBEX sLOxiuFJxshY84euKTIJu4OYUakzly+FR2UE4IRGglHj5/MX9N+3i6sqtOgP+2Y4js0O OY8wnn0PHoHxFeajh6THWwsGVyog1OQj+YaXjIE+pGujmk8NzUF/IvyPg0C8lxfnN7Ah 00z/MLwBV3SNf8J9vP3EwT3RQaoteO2lx6EQPlymKq74THy7YgTcTBlmR0bVRdYYyHBf E/VZaBs/ka/QmMvS4pQMTC/vsADVosCbiRaovKPsw4lN957GWNwASBFO4OOYpk4snMkR aiQg== X-Gm-Message-State: AD7BkJKLsx9RSq2geKzzUrIqI0IGltEjnq+wJ0Ln9qFFhJkQ6LdWP2lpYomYHFoSS1772G3NYynOEo2DHWVa3+6p/Rxgh+MFvu+7Qk0Iy9y6Y4zoqkX/SnlAzMggmm+XcYlOkZvS X-Received: by 10.107.12.224 with SMTP id 93mr13834608iom.70.1459856699962; Tue, 05 Apr 2016 04:44:59 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <05a409ec6bf076f1904f5a6f81441d33@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIlK8zkLFva7DnbjPKSwJ2xi/c/ugITMJFAnsNvOfA= Date: Tue, 5 Apr 2016 13:44:59 +0200 Message-ID: <9c5543699c5592340b18e1fbd92654c6@mail.gmail.com> To: Michael Tuexen Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Comments to draft-ietf-tsvwg-sctp-ndata-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 11:45:13 -0000 Hi Michael > > Section 1: > > > > "However, the lower > > 16-bit of the MID can be used as the SSN if necessary." > > > > No this is not feasible unless it is made negotiable whether 16-bit or > > 32-bits are used for SSN. > I was thinking about using it in the API. We are reporting on the receiver side > the SSN which was received. My current thinking is that we don't change > that, just report the lower 16 bit of the MID. Do you agree, the this is a way > to go. > [Karen Elisabeth Egede Nielsen] Yes I agree that this is viable. But as you say the wording must be substantially improved. Possibly this consideration even only belong to the API section and should not be in this section at all as this section is about the wire format. I can live with it being here if well explained. BR, Karen > I agree that the above wording is bad and needs to be improved. > > Best regards > Michael > > > > Section 1: > > > > "Please note that the > > serial number arithmetic defined in [RFC1982] using SERIAL_BITS = > > 32 applies. Therefore the sender MUST NOT have more than 2**31 - > > 1 ordered messages for each outgoing stream in flight and MUST NOT > > have more than 2**31 - 1 unordered messages for each outgoing > > stream in flight." > > > > Hmm... from RFC4960 we have: > > > > "An endpoint SHOULD NOT transmit a DATA chunk with a TSN that is more > > than 2**31 - 1 above the beginning TSN of its current send window. > > Doing so will cause problems in comparing TSNs." > > > > This means that SCTP can never ever have more than 2**31 - 1 messages > > in flight. > > Perhaps the "MUST NOT" above technically is correct, but I would > > prefer that it is explained that by RFC4960 TSN arithmetic and the > > SHOULD NOT, having more than 2**31 - 1 in flight SHOULD NOT happen > > anyway. > > > > Section 2.3.2: > > > > "Since most schedulers require late TSN assignment, it should be noted > > that the implementation of [RFC6525] needs to handle this." > > > > Not only do most schedulars require late TSN assignment, but any > > scheduler supporting interleaving indeed does this. > > Perhaps this could be emphasized. > > > > The pointer to that RFC6525 have an issue is now here. This is good. > > Given that this is the first RFC which requires for late TSN > > assignment, I wonder if one could not here in this RFC say how this > > issue is assumed to be tackled by an RFC6525 implementation. Even > > more so that I think that we have general agreement on what the > > solution should be. I.e., delay until TSN has been assigned. > > > > BR, Karen > > > >> -----Original Message----- > >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Michael > >> Tuexen > >> Sent: Monday, July 06, 2015 9:24 PM > >> To: Karen Elisabeth Egede Nielsen > >> Cc: tsvwg@ietf.org > >> Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-03.txt > >> > >> > >>> On 19 May 2015, at 10:12, Karen Elisabeth Egede Nielsen > >>> wrote > >>> > >>> Hi Michael, > >>> > >>> Probably you have a version 04 soon in store. Anyway I hope that the > >> following comments may be useful.. > >>> We have discussed some in person or in written before I believe. > >> Hi Karen, > >> > >> thank you very much for the review. Please see my comments in-line. > >> > >> Best regards > >> Michael > >>> > >>> 1. Section 2.1: "However, the lower > >>> 16-bit of the MID can be used as the SSN if necessary." > >>> > >>> This is not an option unless we make it negotiable if 16-bit or > >>> 32-bits are > >> used for SSN. > >> OK. Sentence removed. > >>> > >>> 2. Section 2.1: References to 32-bit arithmetic of SSN/MID and FSN. > >>> > >>> The TSN number is 32-bit only with 32-bit arithmetic. Consequently > >>> there can be a most 2^31-1 outstanding messages on an association > period. > >> Whether one apply 32-bit arithmetic or not to the 32-bit of the > >> SSN/MIDs or FSN is not significant. > >> Not sure. Need to think about it. > >>> > > > >> -----Original Message----- > >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of internet- > >> drafts@ietf.org > >> Sent: 21. marts 2016 16:57 > >> To: i-d-announce@ietf.org > >> Cc: tsvwg@ietf.org > >> Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-05.txt > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> This draft is a work item of the Transport Area Working Group of the IETF. > >> > >> Title : Stream Schedulers and User Message Interleaving > >> for the > >> Stream Control Transmission Protocol > >> Authors : Randall R. Stewart > >> Michael Tuexen > >> Salvatore Loreto > >> Robin Seggelmann > >> Filename : draft-ietf-tsvwg-sctp-ndata-05.txt > >> Pages : 18 > >> Date : 2016-03-21 > >> > >> Abstract: > >> The Stream Control Transmission Protocol (SCTP) is a message oriented > >> transport protocol supporting arbitrary large user messages. > >> However, the sender can not interleave different user messages which > >> causes head of line blocking at the sender side. To overcome this > >> limitation, this document adds a new data chunk to SCTP. > >> > >> Whenever an SCTP sender is allowed to send a user data, it can > >> possibly choose from multiple outgoing SCTP streams. Multiple ways > >> for this selection, called stream schedulers, are defined. Some of > >> them don't require the support of user message interleaving, some do. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ > >> > >> There's also a htmlized version available at: > >> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-05 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-ndata-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 Tue Apr 5 05:03:09 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: [tsvwg] [aqm] [tcpm] [tcpPrague] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area 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 athttp://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:04:50 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B8E12D532 for ; Tue, 5 Apr 2016 05:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 BCblgrReEzIn for ; Tue, 5 Apr 2016 05:04:47 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ADA812D5FC for ; Tue, 5 Apr 2016 05:04:41 -0700 (PDT) Received: from [IPv6:2001:67c:370:152:fdd8:6baa:31a1:42b4] (unknown [IPv6:2001:67c:370:152:fdd8:6baa:31a1:42b4]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 830E7721E280E; Tue, 5 Apr 2016 14:04:37 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Tuexen In-Reply-To: <9c5543699c5592340b18e1fbd92654c6@mail.gmail.com> Date: Tue, 5 Apr 2016 09:04:32 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4C9CB79B-5616-49C0-9873-21EE4A5DE992@fh-muenster.de> References: <05a409ec6bf076f1904f5a6f81441d33@mail.gmail.com> <9c5543699c5592340b18e1fbd92654c6@mail.gmail.com> To: Karen Elisabeth Egede Nielsen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Comments to draft-ietf-tsvwg-sctp-ndata-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 12:04:49 -0000 > On 05 Apr 2016, at 08:44, Karen Elisabeth Egede Nielsen = wrote: >=20 > Hi Michael >=20 >>> Section 1: >>>=20 >>> "However, the lower >>> 16-bit of the MID can be used as the SSN if necessary." >>>=20 >>> No this is not feasible unless it is made negotiable whether 16-bit = or >>> 32-bits are used for SSN. >> I was thinking about using it in the API. We are reporting on the > receiver side >> the SSN which was received. My current thinking is that we don't = change >> that, just report the lower 16 bit of the MID. Do you agree, the this = is > a way >> to go. >>=20 > [Karen Elisabeth Egede Nielsen] Yes I agree that this is viable. But = as > you say the wording must be substantially improved. Possibly this > consideration even only belong to the API section and should not be in > this section at all as this section is about the wire format. I can = live > with it being here if well explained. I totally agree.=20 Dealing with it in https://github.com/sctplab/sctp-idata/issues/3 Best regards Michael >=20 > BR, Karen >=20 >> I agree that the above wording is bad and needs to be improved. >>=20 >> Best regards >> Michael >>>=20 >>> Section 1: >>>=20 >>> "Please note that the >>> serial number arithmetic defined in [RFC1982] using SERIAL_BITS = =3D >>> 32 applies. Therefore the sender MUST NOT have more than 2**31 = - >>> 1 ordered messages for each outgoing stream in flight and MUST > NOT >>> have more than 2**31 - 1 unordered messages for each outgoing >>> stream in flight." >>>=20 >>> Hmm... from RFC4960 we have: >>>=20 >>> "An endpoint SHOULD NOT transmit a DATA chunk with a TSN that is = more >>> than 2**31 - 1 above the beginning TSN of its current send window. >>> Doing so will cause problems in comparing TSNs." >>>=20 >>> This means that SCTP can never ever have more than 2**31 - 1 = messages >>> in flight. >>> Perhaps the "MUST NOT" above technically is correct, but I would >>> prefer that it is explained that by RFC4960 TSN arithmetic and the >>> SHOULD NOT, having more than 2**31 - 1 in flight SHOULD NOT happen >>> anyway. >>>=20 >>> Section 2.3.2: >>>=20 >>> "Since most schedulers require late TSN assignment, it should be > noted >>> that the implementation of [RFC6525] needs to handle this." >>>=20 >>> Not only do most schedulars require late TSN assignment, but any >>> scheduler supporting interleaving indeed does this. >>> Perhaps this could be emphasized. >>>=20 >>> The pointer to that RFC6525 have an issue is now here. This is good. >>> Given that this is the first RFC which requires for late TSN >>> assignment, I wonder if one could not here in this RFC say how this >>> issue is assumed to be tackled by an RFC6525 implementation. Even >>> more so that I think that we have general agreement on what the >>> solution should be. I.e., delay until TSN has been assigned. >>>=20 >>> BR, Karen >>>=20 >>>> -----Original Message----- >>>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Michael >>>> Tuexen >>>> Sent: Monday, July 06, 2015 9:24 PM >>>> To: Karen Elisabeth Egede Nielsen >>>> Cc: tsvwg@ietf.org >>>> Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-03.txt >>>>=20 >>>>=20 >>>>> On 19 May 2015, at 10:12, Karen Elisabeth Egede Nielsen >>>>> wrote >>>>>=20 >>>>> Hi Michael, >>>>>=20 >>>>> Probably you have a version 04 soon in store. Anyway I hope that = the >>>> following comments may be useful.. >>>>> We have discussed some in person or in written before I believe. >>>> Hi Karen, >>>>=20 >>>> thank you very much for the review. Please see my comments in-line. >>>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>> 1. Section 2.1: "However, the lower >>>>> 16-bit of the MID can be used as the SSN if necessary." >>>>>=20 >>>>> This is not an option unless we make it negotiable if 16-bit or >>>>> 32-bits are >>>> used for SSN. >>>> OK. Sentence removed. >>>>>=20 >>>>> 2. Section 2.1: References to 32-bit arithmetic of SSN/MID and = FSN. >>>>>=20 >>>>> The TSN number is 32-bit only with 32-bit arithmetic. Consequently >>>>> there can be a most 2^31-1 outstanding messages on an association >> period. >>>> Whether one apply 32-bit arithmetic or not to the 32-bit of the >>>> SSN/MIDs or FSN is not significant. >>>> Not sure. Need to think about it. >>>>>=20 >>>=20 >>>> -----Original Message----- >>>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of internet- >>>> drafts@ietf.org >>>> Sent: 21. marts 2016 16:57 >>>> To: i-d-announce@ietf.org >>>> Cc: tsvwg@ietf.org >>>> Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-05.txt >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Transport Area Working Group of = the > IETF. >>>>=20 >>>> Title : Stream Schedulers and User Message > Interleaving >>>> for the >>>> Stream Control Transmission Protocol >>>> Authors : Randall R. Stewart >>>> Michael Tuexen >>>> Salvatore Loreto >>>> Robin Seggelmann >>>> Filename : draft-ietf-tsvwg-sctp-ndata-05.txt >>>> Pages : 18 >>>> Date : 2016-03-21 >>>>=20 >>>> Abstract: >>>> The Stream Control Transmission Protocol (SCTP) is a message > oriented >>>> transport protocol supporting arbitrary large user messages. >>>> However, the sender can not interleave different user messages > which >>>> causes head of line blocking at the sender side. To overcome this >>>> limitation, this document adds a new data chunk to SCTP. >>>>=20 >>>> Whenever an SCTP sender is allowed to send a user data, it can >>>> possibly choose from multiple outgoing SCTP streams. Multiple = ways >>>> for this selection, called stream schedulers, are defined. Some = of >>>> them don't require the support of user message interleaving, some > do. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ >>>>=20 >>>> There's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-05 >>>>=20 >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-sctp-ndata-05 >>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 5 09:09:45 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23FF712D721 for ; Tue, 5 Apr 2016 09:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 2RhpOku-BVPg for ; Tue, 5 Apr 2016 09:09:40 -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 06BE912D71B for ; Tue, 5 Apr 2016 09:09:40 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id EB8D51B000AD for ; Tue, 5 Apr 2016 17:21:51 +0100 (BST) Received: from 31.133.155.3 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Tue, 5 Apr 2016 17:09:39 +0100 Message-ID: <30bf02d314bc8219f737f40b2639547d.squirrel@erg.abdn.ac.uk> Date: Tue, 5 Apr 2016 17:09:39 +0100 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: [tsvwg] TSVWG this afternoon X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 16:09:43 -0000 We're looking for two people to help in tsvwg today... * A note taker (you don't need to take down all details - notes are enough). * A jabber scribe - to help remote attendees. Gorry P.S. Remote attendees may like to take the archive file from the proceedings page with all slides for today's meeting: https://www.ietf.org/proceedings/95/slides/slides-95-tsvwg-9.pdf From nobody Tue Apr 5 23:52:59 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F283B12D64A; Tue, 5 Apr 2016 23:52:55 -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: <20160406065255.31042.74068.idtracker@ietfa.amsl.com> Date: Tue, 05 Apr 2016 23:52:55 -0700 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-diffserv-intercon-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 06:52:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group of the IETF. Title : Diffserv-Interconnection classes and practice Authors : Ruediger Geib David L. Black Filename : draft-ietf-tsvwg-diffserv-intercon-05.txt Pages : 21 Date : 2016-04-05 Abstract: This document proposes a limited common set of Diffserv PHBs and codepoints (DSCPs) to be applied at (inter)connections of two separately administered and operated networks, and explains how this approach can simplify network configuration and operation. Many network providers operate MPLS using Treatment Aggregates for traffic marked with different Diffserv PHBs, and use MPLS for interconnection with other networks. This document offers a simple interconnection approach that may simplify operation of Diffserv for network interconnection among providers that use MPLS and apply the Short- Pipe tunnel mode. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-diffserv-intercon/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-diffserv-intercon-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-diffserv-intercon-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 Wed Apr 6 00:05:37 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3EF12D7E5 for ; Wed, 6 Apr 2016 00:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 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, T_RP_MATCHES_RCVD=-0.01] 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 i2qVdOYI8yZg for ; Wed, 6 Apr 2016 00:05:32 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F3812D7BF for ; Wed, 6 Apr 2016 00:05:30 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail21.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 06 Apr 2016 09:05:01 +0200 X-IronPort-AV: E=Sophos;i="5.24,447,1454972400"; d="scan'208";a="857020405" Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 06 Apr 2016 09:04:57 +0200 Received: from HE111642.emea1.cds.t-internal.com ([10.134.93.11]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 6 Apr 2016 09:04:57 +0200 From: To: Date: Wed, 6 Apr 2016 09:04:56 +0200 Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-diffserv-intercon-05.txt Thread-Index: AdGP0QwEr4UyogPbQu6JpLD+irazrwAACvfA Message-ID: <828773FE19B05B4581311493A046E85E63CD23DAED@HE111642.emea1.cds.t-internal.com> References: <20160406065255.31042.74068.idtracker@ietfa.amsl.com> In-Reply-To: <20160406065255.31042.74068.idtracker@ietfa.amsl.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-diffserv-intercon-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 07:05:35 -0000 SGkgR29ycnksDQoNCmRyYWZ0IC0wNSBwaWNrcyB1cCBjb21tZW50cyByZXN1bHRpbmcgZnJvbSBC cmlhbiBDYXJwZW50ZXJzIHJldmlldyByZWNlaXZlZCBvbiAyLiBBcHJpbCAob25lIGNsYXJpZmlj YXRpb24gYW5kIHNvbWUgZWRpdG9yaWFsIGNoYW5nZXMpLiANCg0KUmVnYXJkcywNCg0KUnVlZGln ZXINCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KVm9uOiB0c3Z3ZyBbbWFp bHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmddIEltIEF1ZnRyYWcgdm9uIGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZw0KR2VzZW5kZXQ6IE1pdHR3b2NoLCA2LiBBcHJpbCAyMDE2IDA4OjUzDQpBbjog aS1kLWFubm91bmNlQGlldGYub3JnDQpDYzogdHN2d2dAaWV0Zi5vcmcNCkJldHJlZmY6IFt0c3Z3 Z10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10c3Z3Zy1kaWZmc2Vydi1pbnRlcmNvbi0wNS50eHQN Cg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJ bnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9m IHRoZSBUcmFuc3BvcnQgQXJlYSBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KDQogICAgICAg IFRpdGxlICAgICAgICAgICA6IERpZmZzZXJ2LUludGVyY29ubmVjdGlvbiBjbGFzc2VzIGFuZCBw cmFjdGljZQ0KICAgICAgICBBdXRob3JzICAgICAgICAgOiBSdWVkaWdlciBHZWliDQogICAgICAg ICAgICAgICAgICAgICAgICAgIERhdmlkIEwuIEJsYWNrDQoJRmlsZW5hbWUgICAgICAgIDogZHJh ZnQtaWV0Zi10c3Z3Zy1kaWZmc2Vydi1pbnRlcmNvbi0wNS50eHQNCglQYWdlcyAgICAgICAgICAg OiAyMQ0KCURhdGUgICAgICAgICAgICA6IDIwMTYtMDQtMDUNCg0KQWJzdHJhY3Q6DQogICBUaGlz IGRvY3VtZW50IHByb3Bvc2VzIGEgbGltaXRlZCBjb21tb24gc2V0IG9mIERpZmZzZXJ2IFBIQnMg YW5kDQogICBjb2RlcG9pbnRzIChEU0NQcykgdG8gYmUgYXBwbGllZCBhdCAoaW50ZXIpY29ubmVj dGlvbnMgb2YgdHdvDQogICBzZXBhcmF0ZWx5IGFkbWluaXN0ZXJlZCBhbmQgb3BlcmF0ZWQgbmV0 d29ya3MsIGFuZCBleHBsYWlucyBob3cgdGhpcw0KICAgYXBwcm9hY2ggY2FuIHNpbXBsaWZ5IG5l dHdvcmsgY29uZmlndXJhdGlvbiBhbmQgb3BlcmF0aW9uLiAgTWFueQ0KICAgbmV0d29yayBwcm92 aWRlcnMgb3BlcmF0ZSBNUExTIHVzaW5nIFRyZWF0bWVudCBBZ2dyZWdhdGVzIGZvciB0cmFmZmlj DQogICBtYXJrZWQgd2l0aCBkaWZmZXJlbnQgRGlmZnNlcnYgUEhCcywgYW5kIHVzZSBNUExTIGZv ciBpbnRlcmNvbm5lY3Rpb24NCiAgIHdpdGggb3RoZXIgbmV0d29ya3MuICBUaGlzIGRvY3VtZW50 IG9mZmVycyBhIHNpbXBsZSBpbnRlcmNvbm5lY3Rpb24NCiAgIGFwcHJvYWNoIHRoYXQgbWF5IHNp bXBsaWZ5IG9wZXJhdGlvbiBvZiBEaWZmc2VydiBmb3IgbmV0d29yaw0KICAgaW50ZXJjb25uZWN0 aW9uIGFtb25nIHByb3ZpZGVycyB0aGF0IHVzZSBNUExTIGFuZCBhcHBseSB0aGUgU2hvcnQtDQog ICBQaXBlIHR1bm5lbCBtb2RlLg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdl IGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi10c3Z3Zy1kaWZmc2Vydi1pbnRlcmNvbi8NCg0KVGhlcmUncyBhbHNvIGEgaHRtbGl6 ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi10c3Z3Zy1kaWZmc2Vydi1pbnRlcmNvbi0wNQ0KDQpBIGRpZmYgZnJvbSB0aGUgcHJl dmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaWV0Zi10c3Z3Zy1kaWZmc2Vydi1pbnRlcmNvbi0wNQ0KDQoNClBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2 YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy8NCg0K From nobody Wed Apr 6 04:19:18 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5957512D7AA for ; Wed, 6 Apr 2016 04:19:16 -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 75qNBhFnYkLQ for ; Wed, 6 Apr 2016 04:19:14 -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 4A91812D767 for ; Wed, 6 Apr 2016 04:19:14 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B8CF718000C; Wed, 6 Apr 2016 04:18:21 -0700 (PDT) To: randall@lakerest.net, spencerdawkins.ietf@gmail.com, mls.ietf@gmail.com, gorry@erg.abdn.ac.uk, david.black@emc.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160406111821.B8CF718000C@rfc-editor.org> Date: Wed, 6 Apr 2016 04:18:21 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, tsvwg@ietf.org Subject: [tsvwg] [Technical Errata Reported] RFC4960 (4656) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 11:19:16 -0000 The following errata report has been submitted for RFC4960, "Stream Control Transmission Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4960&eid=4656 -------------------------------------- Type: Technical Reported by: Lionel Morand Section: GLOBAL Original Text ------------- 6.2. Acknowledgement on Reception of DATA Chunks The SCTP endpoint MUST always acknowledge the reception of each valid DATA chunk when the DATA chunk received is inside its receive window. When the receiver's advertised window is 0, the receiver MUST drop any new incoming DATA chunk with a TSN larger than the largest TSN received so far. If the new incoming DATA chunk holds a TSN value less than the largest TSN received so far, then the receiver SHOULD drop the largest TSN held for reordering and accept the new incoming DATA chunk. In either case, if such a DATA chunk is dropped, the receiver MUST immediately send back a SACK with the current receive window showing only DATA chunks received and accepted so far. The dropped DATA chunk(s) MUST NOT be included in the SACK, as they were not accepted. The receiver MUST also have an algorithm for advertising its receive window to avoid receiver silly window syndrome (SWS), as described in [RFC0813]. The algorithm can be similar to the one described in Section 4.2.3.3 of [RFC1122]. The guidelines on delayed acknowledgement algorithm specified in Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an acknowledgement SHOULD be generated for at least every second packet (not every second DATA chunk) received, and SHOULD be generated within 200 ms of the arrival of any unacknowledged DATA chunk. In some situations, it may be beneficial for an SCTP transmitter to be more conservative than the algorithms detailed in this document allow. However, an SCTP transmitter MUST NOT be more aggressive than the following algorithms allow. An SCTP receiver MUST NOT generate more than one SACK for every incoming packet, other than to update the offered window as the receiving application consumes new data. IMPLEMENTATION NOTE: The maximum delay for generating an acknowledgement may be configured by the SCTP administrator, either statically or dynamically, in order to meet the specific timing requirement of the protocol being carried. An implementation MUST NOT allow the maximum delay to be configured to be more than 500 ms. In other words, an implementation MAY lower this value below 500 ms but MUST NOT raise it above 500 ms. [ remaining of the section unchanged ] *********************************************************************** 15. Suggested SCTP Protocol Parameter Values The following protocol parameters are RECOMMENDED: RTO.Initial - 3 seconds RTO.Min - 1 second RTO.Max - 60 seconds Max.Burst - 4 RTO.Alpha - 1/8 RTO.Beta - 1/4 Valid.Cookie.Life - 60 seconds Association.Max.Retrans - 10 attempts Path.Max.Retrans - 5 attempts (per destination address) Max.Init.Retransmits - 8 attempts HB.interval - 30 seconds HB.Max.Burst - 1 IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to customize some of these protocol parameters (see Section 10). Note: RTO.Min SHOULD be set as recommended above. Corrected Text -------------- 6.2. Acknowledgement on Reception of DATA Chunks The SCTP endpoint MUST always acknowledge the reception of each valid DATA chunk when the DATA chunk received is inside its receive window. When the receiver's advertised window is 0, the receiver MUST drop any new incoming DATA chunk with a TSN larger than the largest TSN received so far. If the new incoming DATA chunk holds a TSN value less than the largest TSN received so far, then the receiver SHOULD drop the largest TSN held for reordering and accept the new incoming DATA chunk. In either case, if such a DATA chunk is dropped, the receiver MUST immediately send back a SACK with the current receive window showing only DATA chunks received and accepted so far. The dropped DATA chunk(s) MUST NOT be included in the SACK, as they were not accepted. The receiver MUST also have an algorithm for advertising its receive window to avoid receiver silly window syndrome (SWS), as described in [RFC0813]. The algorithm can be similar to the one described in Section 4.2.3.3 of [RFC1122]. The guidelines on delayed acknowledgement algorithm specified in Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an acknowledgement SHOULD be generated for at least every second packet (not every second DATA chunk) received, and SHOULD be generated within 200 ms of the arrival of any unacknowledged DATA chunk. In some situations, it may be beneficial for an SCTP transmitter to be more conservative than the algorithms detailed in this document allow. However, an SCTP transmitter MUST NOT be more aggressive than the following algorithms allow. An SCTP receiver MUST NOT generate more than one SACK for every incoming packet, other than to update the offered window as the receiving application consumes new data. IMPLEMENTATION NOTE: The maximum delay for generating an acknowledgement may be configured by the SCTP administrator, either statically or dynamically, in order to meet the specific timing requirement of the protocol being carried. An implementation MUST NOT allow the maximum delay (protocol parameter 'SACK.Delay') to be configured to be more than 500 ms. In other words, an implementation MAY lower the value of 'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms. [ remaining of the section unchanged ] *********************************************************************** 15. Suggested SCTP Protocol Parameter Values The following protocol parameters are RECOMMENDED: RTO.Initial - 3 seconds RTO.Min - 1 second RTO.Max - 60 seconds Max.Burst - 4 RTO.Alpha - 1/8 RTO.Beta - 1/4 Valid.Cookie.Life - 60 seconds Association.Max.Retrans - 10 attempts Path.Max.Retrans - 5 attempts (per destination address) Max.Init.Retransmits - 8 attempts HB.interval - 30 seconds HB.Max.Burst - 1 SACK.Delay - 200 milliseconds IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to customize some of these protocol parameters (see Section 10). Note: RTO.Min SHOULD be set as recommended above. Notes ----- In section 6.2, the name 'SACK.Delay' is given to the protocol parameter that indicate themaximum delay for generating a SACK. In section 15, the list of SCTP protocol parameters and associated recommended value is not complete. The maximum delay for generating an acknowledgement ('SACK.Delay') is missing from this list. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4960 (draft-ietf-tsvwg-2960bis-05) -------------------------------------- Title : Stream Control Transmission Protocol Publication Date : September 2007 Author(s) : R. Stewart, Ed. Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From nobody Wed Apr 6 06:00:45 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D3712D1A2 for ; Wed, 6 Apr 2016 06:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 JwYk-XjLTahM for ; Wed, 6 Apr 2016 06:00:36 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5044812D1A8 for ; Wed, 6 Apr 2016 06:00:36 -0700 (PDT) Received: from [IPv6:2001:67c:370:136:79db:39c7:b66e:54e0] (unknown [IPv6:2001:67c:370:136:79db:39c7:b66e:54e0]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id C107871939081; Wed, 6 Apr 2016 15:00:30 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Tuexen In-Reply-To: <20160406111821.B8CF718000C@rfc-editor.org> Date: Wed, 6 Apr 2016 10:00:27 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <527C8FB5-16A5-46DE-8C5C-EE3E382F32BC@lurchi.franken.de> References: <20160406111821.B8CF718000C@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Gorry Fairhurst , tsvwg@ietf.org, mls.ietf@gmail.com, randall@lakerest.net Subject: Re: [tsvwg] [Technical Errata Reported] RFC4960 (4656) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 13:00:44 -0000 > On 06 Apr 2016, at 08:18, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC4960, > "Stream Control Transmission Protocol". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4960&eid=3D4656 >=20 > -------------------------------------- > Type: Technical > Reported by: Lionel Morand >=20 > Section: GLOBAL >=20 > Original Text > ------------- > 6.2. Acknowledgement on Reception of DATA Chunks >=20 > The SCTP endpoint MUST always acknowledge the reception of each = valid > DATA chunk when the DATA chunk received is inside its receive = window. >=20 > When the receiver's advertised window is 0, the receiver MUST drop > any new incoming DATA chunk with a TSN larger than the largest TSN > received so far. If the new incoming DATA chunk holds a TSN value > less than the largest TSN received so far, then the receiver SHOULD > drop the largest TSN held for reordering and accept the new incoming > DATA chunk. In either case, if such a DATA chunk is dropped, the > receiver MUST immediately send back a SACK with the current receive > window showing only DATA chunks received and accepted so far. The > dropped DATA chunk(s) MUST NOT be included in the SACK, as they were > not accepted. The receiver MUST also have an algorithm for > advertising its receive window to avoid receiver silly window > syndrome (SWS), as described in [RFC0813]. The algorithm can be > similar to the one described in Section 4.2.3.3 of [RFC1122]. >=20 > The guidelines on delayed acknowledgement algorithm specified in > Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an > acknowledgement SHOULD be generated for at least every second packet > (not every second DATA chunk) received, and SHOULD be generated > within 200 ms of the arrival of any unacknowledged DATA chunk. In > some situations, it may be beneficial for an SCTP transmitter to be > more conservative than the algorithms detailed in this document > allow. However, an SCTP transmitter MUST NOT be more aggressive = than > the following algorithms allow. >=20 > An SCTP receiver MUST NOT generate more than one SACK for every > incoming packet, other than to update the offered window as the > receiving application consumes new data. >=20 > IMPLEMENTATION NOTE: The maximum delay for generating an > acknowledgement may be configured by the SCTP administrator, either > statically or dynamically, in order to meet the specific timing > requirement of the protocol being carried. >=20 > An implementation MUST NOT allow the maximum delay to be configured > to be more than 500 ms. In other words, an implementation MAY lower > this value below 500 ms but MUST NOT raise it above 500 ms. >=20 > [ remaining of the section unchanged ] >=20 > = *********************************************************************** > 15. Suggested SCTP Protocol Parameter Values >=20 > The following protocol parameters are RECOMMENDED: >=20 > RTO.Initial - 3 seconds > RTO.Min - 1 second > RTO.Max - 60 seconds > Max.Burst - 4 > RTO.Alpha - 1/8 > RTO.Beta - 1/4 > Valid.Cookie.Life - 60 seconds > Association.Max.Retrans - 10 attempts > Path.Max.Retrans - 5 attempts (per destination address) > Max.Init.Retransmits - 8 attempts > HB.interval - 30 seconds > HB.Max.Burst - 1 >=20 > IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to > customize some of these protocol parameters (see Section 10). >=20 > Note: RTO.Min SHOULD be set as recommended above. >=20 > Corrected Text > -------------- > 6.2. Acknowledgement on Reception of DATA Chunks >=20 > The SCTP endpoint MUST always acknowledge the reception of each = valid > DATA chunk when the DATA chunk received is inside its receive = window. >=20 > When the receiver's advertised window is 0, the receiver MUST drop > any new incoming DATA chunk with a TSN larger than the largest TSN > received so far. If the new incoming DATA chunk holds a TSN value > less than the largest TSN received so far, then the receiver SHOULD > drop the largest TSN held for reordering and accept the new incoming > DATA chunk. In either case, if such a DATA chunk is dropped, the > receiver MUST immediately send back a SACK with the current receive > window showing only DATA chunks received and accepted so far. The > dropped DATA chunk(s) MUST NOT be included in the SACK, as they were > not accepted. The receiver MUST also have an algorithm for > advertising its receive window to avoid receiver silly window > syndrome (SWS), as described in [RFC0813]. The algorithm can be > similar to the one described in Section 4.2.3.3 of [RFC1122]. >=20 > The guidelines on delayed acknowledgement algorithm specified in > Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an > acknowledgement SHOULD be generated for at least every second packet > (not every second DATA chunk) received, and SHOULD be generated > within 200 ms of the arrival of any unacknowledged DATA chunk. In > some situations, it may be beneficial for an SCTP transmitter to be > more conservative than the algorithms detailed in this document > allow. However, an SCTP transmitter MUST NOT be more aggressive = than > the following algorithms allow. >=20 > An SCTP receiver MUST NOT generate more than one SACK for every > incoming packet, other than to update the offered window as the > receiving application consumes new data. >=20 > IMPLEMENTATION NOTE: The maximum delay for generating an > acknowledgement may be configured by the SCTP administrator, either > statically or dynamically, in order to meet the specific timing > requirement of the protocol being carried. >=20 > An implementation MUST NOT allow the maximum delay (protocol=20 > parameter 'SACK.Delay') to be configured to be more than 500 ms. > In other words, an implementation MAY lower the value of=20 > 'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms. >=20 > [ remaining of the section unchanged ] >=20 > = *********************************************************************** > 15. Suggested SCTP Protocol Parameter Values >=20 > The following protocol parameters are RECOMMENDED: >=20 > RTO.Initial - 3 seconds > RTO.Min - 1 second > RTO.Max - 60 seconds > Max.Burst - 4 > RTO.Alpha - 1/8 > RTO.Beta - 1/4 > Valid.Cookie.Life - 60 seconds > Association.Max.Retrans - 10 attempts > Path.Max.Retrans - 5 attempts (per destination address) > Max.Init.Retransmits - 8 attempts > HB.interval - 30 seconds > HB.Max.Burst - 1 > SACK.Delay - 200 milliseconds >=20 > IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to > customize some of these protocol parameters (see Section 10). >=20 > Note: RTO.Min SHOULD be set as recommended above. >=20 > Notes > ----- > In section 6.2, the name 'SACK.Delay' is given to the protocol = parameter that indicate themaximum delay for generating a SACK. >=20 > In section 15, the list of SCTP protocol parameters and associated = recommended value is not complete. The maximum delay for generating an = acknowledgement ('SACK.Delay') is missing from this list. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC4960 (draft-ietf-tsvwg-2960bis-05) > -------------------------------------- > Title : Stream Control Transmission Protocol > Publication Date : September 2007 > Author(s) : R. Stewart, Ed. > Category : PROPOSED STANDARD > Source : Transport Area Working Group > Area : Transport > Stream : IETF > Verifying Party : IESG >=20 This looks good to me. This SACK.delay parameter should have been listed = in the table. Best regards Michael From nobody Wed Apr 6 06:11:37 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2BA12D4FD for ; Wed, 6 Apr 2016 06:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.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 ndio59T8TFKY for ; Wed, 6 Apr 2016 06:11:33 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 B2E9912D50E for ; Wed, 6 Apr 2016 06:10:56 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id c20so33332595pfc.1 for ; Wed, 06 Apr 2016 06:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=pSGhRtafbGdX6wD5kYdKY47/3yevqY3rmwqOijMANuQ=; b=EeBYBOIpGgxMi4DnJTl4FIJ1WY2wh0OYWeF6+wznWegEaQU5JUfdjQuYrIL0irbb5I br/T8flxkmaP8UQy58J9TeWYbkxtEvlM5EmKgXwM3CRuPacUPptP3LLiobBzCjNFYgW+ /DYGJTdD2wGJitA8qnq9MuzGhQCLZHJ27aoEU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=pSGhRtafbGdX6wD5kYdKY47/3yevqY3rmwqOijMANuQ=; b=UfuJgyZVGmvK24q/JPUyuyXSNfgnMCiYtp4beZ1NBPPPyJJkPEy1EoAE+sJAxArKgV gFuOJuWVfDiKdF9k6XTFs5JK4+G3ozyozr7ExHQVJI+1lrteZnHshS2n8FYNFEzV4XCQ q2QsjPko1ApZVj3C6gQGMeyHh/EeJSX26SniCZgDYiCgKKwTGd1h5yrR3iNBPji/0qCq sacsYQQKATWwuZVoM1yMz3v35sJt3ovAPJ25a5RBWvLz4vp4VQIz2JcwJhE0TiZ6UuS4 r2D6vzBD/ONWwuOyxNRzMRfqJ1ZkRbnvi4ncIY1aQKSipvFncbYTvSz4IunGxTlSyH64 8GVw== X-Gm-Message-State: AD7BkJIZG0fEl1jHuZLXMunhi9EO1ysHhY0FAlPavwASxR9ouWGcTr9jBJkYGNZ4n0Pvmmdl X-Received: by 10.98.32.136 with SMTP id m8mr38327728pfj.11.1459948256040; Wed, 06 Apr 2016 06:10:56 -0700 (PDT) Received: from [192.168.70.10] ([69.53.245.107]) by smtp.gmail.com with ESMTPSA id ul7sm5076915pac.41.2016.04.06.06.10.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 06:10:53 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E515D383-90E9-4A75-89BF-C5378AAF077A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Randall Stewart In-Reply-To: <527C8FB5-16A5-46DE-8C5C-EE3E382F32BC@lurchi.franken.de> Date: Wed, 6 Apr 2016 10:10:40 -0300 Message-Id: References: <20160406111821.B8CF718000C@rfc-editor.org> <527C8FB5-16A5-46DE-8C5C-EE3E382F32BC@lurchi.franken.de> To: =?iso-8859-1?Q?Michael_T=FCxen?= X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Gorry Fairhurst , mls.ietf@gmail.com, tsvwg@ietf.org, Randall Ray Stewart , RFC Errata System Subject: Re: [tsvwg] [Technical Errata Reported] RFC4960 (4656) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 13:11:36 -0000 --Apple-Mail=_E515D383-90E9-4A75-89BF-C5378AAF077A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I agree this should have been listed in the table.. not sure we need the word changes (see sack table) that have been added here=85 But we *should* have put the sack-delay 200ms in the table.. R On Apr 6, 2016, at 10:00 AM, Michael Tuexen = wrote: >=20 >> On 06 Apr 2016, at 08:18, RFC Errata System = wrote: >>=20 >> The following errata report has been submitted for RFC4960, >> "Stream Control Transmission Protocol". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D4960&eid=3D4656 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Lionel Morand >>=20 >> Section: GLOBAL >>=20 >> Original Text >> ------------- >> 6.2. Acknowledgement on Reception of DATA Chunks >>=20 >> The SCTP endpoint MUST always acknowledge the reception of each = valid >> DATA chunk when the DATA chunk received is inside its receive = window. >>=20 >> When the receiver's advertised window is 0, the receiver MUST drop >> any new incoming DATA chunk with a TSN larger than the largest TSN >> received so far. If the new incoming DATA chunk holds a TSN value >> less than the largest TSN received so far, then the receiver SHOULD >> drop the largest TSN held for reordering and accept the new incoming >> DATA chunk. In either case, if such a DATA chunk is dropped, the >> receiver MUST immediately send back a SACK with the current receive >> window showing only DATA chunks received and accepted so far. The >> dropped DATA chunk(s) MUST NOT be included in the SACK, as they were >> not accepted. The receiver MUST also have an algorithm for >> advertising its receive window to avoid receiver silly window >> syndrome (SWS), as described in [RFC0813]. The algorithm can be >> similar to the one described in Section 4.2.3.3 of [RFC1122]. >>=20 >> The guidelines on delayed acknowledgement algorithm specified in >> Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an >> acknowledgement SHOULD be generated for at least every second packet >> (not every second DATA chunk) received, and SHOULD be generated >> within 200 ms of the arrival of any unacknowledged DATA chunk. In >> some situations, it may be beneficial for an SCTP transmitter to be >> more conservative than the algorithms detailed in this document >> allow. However, an SCTP transmitter MUST NOT be more aggressive = than >> the following algorithms allow. >>=20 >> An SCTP receiver MUST NOT generate more than one SACK for every >> incoming packet, other than to update the offered window as the >> receiving application consumes new data. >>=20 >> IMPLEMENTATION NOTE: The maximum delay for generating an >> acknowledgement may be configured by the SCTP administrator, either >> statically or dynamically, in order to meet the specific timing >> requirement of the protocol being carried. >>=20 >> An implementation MUST NOT allow the maximum delay to be configured >> to be more than 500 ms. In other words, an implementation MAY lower >> this value below 500 ms but MUST NOT raise it above 500 ms. >>=20 >> [ remaining of the section unchanged ] >>=20 >> = *********************************************************************** >> 15. Suggested SCTP Protocol Parameter Values >>=20 >> The following protocol parameters are RECOMMENDED: >>=20 >> RTO.Initial - 3 seconds >> RTO.Min - 1 second >> RTO.Max - 60 seconds >> Max.Burst - 4 >> RTO.Alpha - 1/8 >> RTO.Beta - 1/4 >> Valid.Cookie.Life - 60 seconds >> Association.Max.Retrans - 10 attempts >> Path.Max.Retrans - 5 attempts (per destination address) >> Max.Init.Retransmits - 8 attempts >> HB.interval - 30 seconds >> HB.Max.Burst - 1 >>=20 >> IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to >> customize some of these protocol parameters (see Section 10). >>=20 >> Note: RTO.Min SHOULD be set as recommended above. >>=20 >> Corrected Text >> -------------- >> 6.2. Acknowledgement on Reception of DATA Chunks >>=20 >> The SCTP endpoint MUST always acknowledge the reception of each = valid >> DATA chunk when the DATA chunk received is inside its receive = window. >>=20 >> When the receiver's advertised window is 0, the receiver MUST drop >> any new incoming DATA chunk with a TSN larger than the largest TSN >> received so far. If the new incoming DATA chunk holds a TSN value >> less than the largest TSN received so far, then the receiver SHOULD >> drop the largest TSN held for reordering and accept the new incoming >> DATA chunk. In either case, if such a DATA chunk is dropped, the >> receiver MUST immediately send back a SACK with the current receive >> window showing only DATA chunks received and accepted so far. The >> dropped DATA chunk(s) MUST NOT be included in the SACK, as they were >> not accepted. The receiver MUST also have an algorithm for >> advertising its receive window to avoid receiver silly window >> syndrome (SWS), as described in [RFC0813]. The algorithm can be >> similar to the one described in Section 4.2.3.3 of [RFC1122]. >>=20 >> The guidelines on delayed acknowledgement algorithm specified in >> Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an >> acknowledgement SHOULD be generated for at least every second packet >> (not every second DATA chunk) received, and SHOULD be generated >> within 200 ms of the arrival of any unacknowledged DATA chunk. In >> some situations, it may be beneficial for an SCTP transmitter to be >> more conservative than the algorithms detailed in this document >> allow. However, an SCTP transmitter MUST NOT be more aggressive = than >> the following algorithms allow. >>=20 >> An SCTP receiver MUST NOT generate more than one SACK for every >> incoming packet, other than to update the offered window as the >> receiving application consumes new data. >>=20 >> IMPLEMENTATION NOTE: The maximum delay for generating an >> acknowledgement may be configured by the SCTP administrator, either >> statically or dynamically, in order to meet the specific timing >> requirement of the protocol being carried. >>=20 >> An implementation MUST NOT allow the maximum delay (protocol=20 >> parameter 'SACK.Delay') to be configured to be more than 500 ms. >> In other words, an implementation MAY lower the value of=20 >> 'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms. >>=20 >> [ remaining of the section unchanged ] >>=20 >> = *********************************************************************** >> 15. Suggested SCTP Protocol Parameter Values >>=20 >> The following protocol parameters are RECOMMENDED: >>=20 >> RTO.Initial - 3 seconds >> RTO.Min - 1 second >> RTO.Max - 60 seconds >> Max.Burst - 4 >> RTO.Alpha - 1/8 >> RTO.Beta - 1/4 >> Valid.Cookie.Life - 60 seconds >> Association.Max.Retrans - 10 attempts >> Path.Max.Retrans - 5 attempts (per destination address) >> Max.Init.Retransmits - 8 attempts >> HB.interval - 30 seconds >> HB.Max.Burst - 1 >> SACK.Delay - 200 milliseconds >>=20 >> IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to >> customize some of these protocol parameters (see Section 10). >>=20 >> Note: RTO.Min SHOULD be set as recommended above. >>=20 >> Notes >> ----- >> In section 6.2, the name 'SACK.Delay' is given to the protocol = parameter that indicate themaximum delay for generating a SACK. >>=20 >> In section 15, the list of SCTP protocol parameters and associated = recommended value is not complete. The maximum delay for generating an = acknowledgement ('SACK.Delay') is missing from this list. >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary.=20 >>=20 >> -------------------------------------- >> RFC4960 (draft-ietf-tsvwg-2960bis-05) >> -------------------------------------- >> Title : Stream Control Transmission Protocol >> Publication Date : September 2007 >> Author(s) : R. Stewart, Ed. >> Category : PROPOSED STANDARD >> Source : Transport Area Working Group >> Area : Transport >> Stream : IETF >> Verifying Party : IESG >>=20 > This looks good to me. This SACK.delay parameter should have been = listed in the table. >=20 > Best regards > Michael >=20 -------- Randall Stewart rrs@netflix.com 803-317-4952 --Apple-Mail=_E515D383-90E9-4A75-89BF-C5378AAF077A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = agree this should have been listed in the table.. not sure we = need
the word changes (see sack table) that have been added = here=85

But we *should* have put the sack-delay = 200ms in the table..

R
On Apr 6, = 2016, at 10:00 AM, Michael Tuexen <Michael.Tuexen@lurchi.fra= nken.de> wrote:


On 06 Apr 2016, at 08:18, = RFC Errata System <rfc-editor@rfc-editor.org>= ; wrote:

The following errata report has been submitted for = RFC4960,
"Stream Control Transmission = Protocol".

--------------------------------------
You may = review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D4960&eid=3D4656=

--------------------------------------
Type: = Technical
Reported by: Lionel Morand = <lionel.morand@orange.com>

Section: GLOBAL

Original = Text
-------------
6.2.  Acknowledgement on Reception of DATA = Chunks

 The SCTP endpoint MUST always acknowledge the = reception of each valid
 DATA chunk when the DATA chunk = received is inside its receive window.

 When the receiver's = advertised window is 0, the receiver MUST drop
 any new = incoming DATA chunk with a TSN larger than the largest TSN
=  received so far.  If the new incoming DATA chunk holds a TSN = value
 less than the largest TSN received so far, then the = receiver SHOULD
 drop the largest TSN held for reordering and = accept the new incoming
 DATA chunk.  In either case, if = such a DATA chunk is dropped, the
 receiver MUST immediately = send back a SACK with the current receive
 window showing only = DATA chunks received and accepted so far.  The
 dropped = DATA chunk(s) MUST NOT be included in the SACK, as they were
=  not accepted.  The receiver MUST also have an algorithm = for
 advertising its receive window to avoid receiver silly = window
 syndrome (SWS), as described in [RFC0813].  The = algorithm can be
 similar to the one described in Section = 4.2.3.3 of [RFC1122].

 The guidelines on delayed = acknowledgement algorithm specified in
 Section 4.2 of = [RFC2581] SHOULD be followed.  Specifically, an
=  acknowledgement SHOULD be generated for at least every second = packet
 (not every second DATA chunk) received, and SHOULD be = generated
 within 200 ms of the arrival of any unacknowledged = DATA chunk.  In
 some situations, it may be beneficial for = an SCTP transmitter to be
 more conservative than the = algorithms detailed in this document
 allow.  However, an = SCTP transmitter MUST NOT be more aggressive than
 the = following algorithms allow.

 An SCTP receiver MUST NOT = generate more than one SACK for every
 incoming packet, other = than to update the offered window as the
 receiving application = consumes new data.

 IMPLEMENTATION NOTE: The maximum delay = for generating an
 acknowledgement may be configured by the = SCTP administrator, either
 statically or dynamically, in order = to meet the specific timing
 requirement of the protocol being = carried.

 An implementation MUST NOT allow the maximum = delay to be configured
 to be more than 500 ms.  In other = words, an implementation MAY lower
 this value below 500 ms but = MUST NOT raise it above 500 ms.

[ remaining of the section = unchanged = ]

*****************************************************************= ******
15.  Suggested SCTP Protocol Parameter Values

=  The following protocol parameters are RECOMMENDED:

=     RTO.Initial - 3 seconds
=     RTO.Min - 1 second
=     RTO.Max - 60 seconds
=     Max.Burst - 4
=     RTO.Alpha - 1/8
=     RTO.Beta - 1/4
=     Valid.Cookie.Life - 60 seconds
=     Association.Max.Retrans - 10 attempts
=     Path.Max.Retrans - 5 attempts (per destination = address)
    Max.Init.Retransmits - 8 = attempts
    HB.interval - 30 seconds
=     HB.Max.Burst - 1

 IMPLEMENTATION = NOTE: The SCTP implementation may allow ULP to
 customize some = of these protocol parameters (see Section 10).

 Note: = RTO.Min SHOULD be set as recommended above.

Corrected = Text
--------------
6.2.  Acknowledgement on Reception of = DATA Chunks

 The SCTP endpoint MUST always acknowledge the = reception of each valid
 DATA chunk when the DATA chunk = received is inside its receive window.

 When the receiver's = advertised window is 0, the receiver MUST drop
 any new = incoming DATA chunk with a TSN larger than the largest TSN
=  received so far.  If the new incoming DATA chunk holds a TSN = value
 less than the largest TSN received so far, then the = receiver SHOULD
 drop the largest TSN held for reordering and = accept the new incoming
 DATA chunk.  In either case, if = such a DATA chunk is dropped, the
 receiver MUST immediately = send back a SACK with the current receive
 window showing only = DATA chunks received and accepted so far.  The
 dropped = DATA chunk(s) MUST NOT be included in the SACK, as they were
=  not accepted.  The receiver MUST also have an algorithm = for
 advertising its receive window to avoid receiver silly = window
 syndrome (SWS), as described in [RFC0813].  The = algorithm can be
 similar to the one described in Section = 4.2.3.3 of [RFC1122].

 The guidelines on delayed = acknowledgement algorithm specified in
 Section 4.2 of = [RFC2581] SHOULD be followed.  Specifically, an
=  acknowledgement SHOULD be generated for at least every second = packet
 (not every second DATA chunk) received, and SHOULD be = generated
 within 200 ms of the arrival of any unacknowledged = DATA chunk.  In
 some situations, it may be beneficial for = an SCTP transmitter to be
 more conservative than the = algorithms detailed in this document
 allow.  However, an = SCTP transmitter MUST NOT be more aggressive than
 the = following algorithms allow.

 An SCTP receiver MUST NOT = generate more than one SACK for every
 incoming packet, other = than to update the offered window as the
 receiving application = consumes new data.

 IMPLEMENTATION NOTE: The maximum delay = for generating an
 acknowledgement may be configured by the = SCTP administrator, either
 statically or dynamically, in order = to meet the specific timing
 requirement of the protocol being = carried.

 An implementation MUST NOT allow the maximum = delay (protocol
 parameter 'SACK.Delay') to be configured to = be more than 500 ms.
 In other words, an implementation MAY = lower the value of
 'SACK.Delay' below 500 ms but MUST NOT = raise it above 500 ms.

[ remaining of the section unchanged = ]

*****************************************************************= ******
15.  Suggested SCTP Protocol Parameter Values

=  The following protocol parameters are RECOMMENDED:

=     RTO.Initial - 3 seconds
=     RTO.Min - 1 second
=     RTO.Max - 60 seconds
=     Max.Burst - 4
=     RTO.Alpha - 1/8
=     RTO.Beta - 1/4
=     Valid.Cookie.Life - 60 seconds
=     Association.Max.Retrans - 10 attempts
=     Path.Max.Retrans - 5 attempts (per destination = address)
    Max.Init.Retransmits - 8 = attempts
    HB.interval - 30 seconds
=     HB.Max.Burst - 1
=     SACK.Delay - 200 milliseconds

=  IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to
=  customize some of these protocol parameters (see Section = 10).

 Note: RTO.Min SHOULD be set as recommended = above.

Notes
-----
In section 6.2, the name 'SACK.Delay' is = given to the protocol parameter that indicate themaximum delay for = generating a SACK.

In section 15, the list of SCTP protocol = parameters and associated recommended value is not complete. The maximum = delay for generating an acknowledgement ('SACK.Delay') is missing from = this list.

Instructions:
-------------
This erratum is = currently posted as "Reported". If necessary, please
use "Reply All" = to discuss whether it should be verified or
rejected. When a decision = is reached, the verifying party (IESG)
can log in to change the = status and edit the report, if necessary. =

--------------------------------------
RFC4960 = (draft-ietf-tsvwg-2960bis-05)
--------------------------------------Title =             &n= bsp; : Stream Control Transmission Protocol
Publication Date =    : September 2007
Author(s) =           : R. = Stewart, Ed.
Category =            : = PROPOSED STANDARD
Source =             &n= bsp;: Transport Area Working Group
Area =             &n= bsp;  : Transport
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG

This looks good to me. This SACK.delay = parameter should have been listed in the table.

Best = regards
Michael


--------
Randall Stewart
803-317-4952=





= --Apple-Mail=_E515D383-90E9-4A75-89BF-C5378AAF077A-- From nobody Wed Apr 6 08:06:31 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E6412D856 for ; Wed, 6 Apr 2016 08:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 zoVGXr3-BiLA for ; Wed, 6 Apr 2016 08:06:21 -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 7292112D542 for ; Wed, 6 Apr 2016 08:02:40 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 096681B001C8; Wed, 6 Apr 2016 16:14:45 +0100 (BST) Received: from 31.133.155.3 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Wed, 6 Apr 2016 16:02:39 +0100 Message-ID: <36f0fb63761750423cdb26990379e109.squirrel@erg.abdn.ac.uk> In-Reply-To: References: <20160406111821.B8CF718000C@rfc-editor.org> <527C8FB5-16A5-46DE-8C5C-EE3E382F32BC@lurchi.franken.de> Date: Wed, 6 Apr 2016 16:02:39 +0100 From: gorry@erg.abdn.ac.uk To: "Randall Stewart" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: Gorry Fairhurst , tsvwg@ietf.org, mls.ietf@gmail.com, Randall Ray Stewart , =?iso-8859-1?Q?=22Michael_T=FCxen=22?= , RFC Errata System Subject: Re: [tsvwg] [Technical Errata Reported] RFC4960 (4656) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 15:06:30 -0000 It seems like some sort of Errata may be useful to advise people of this issue. However, there's probably more text here than I'd have expected in an Errata. I suspect the original intention was that "delay" in the original text was to refer to 'SACK.Delay', as below: "An implementation MUST NOT allow the maximum delay (protocol parameter 'SACK.Delay') to be configured to be more than 500 ms. In other words, an implementation MAY lower the value of 'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms." Does more need to be noted as text changes in the Errata? (Also noting the table addition). Gorry > > > I agree this should have been listed in the table.. not sure we need > the word changes (see sack table) that have been added here > > But we *should* have put the sack-delay 200ms in the table.. > > R > On Apr 6, 2016, at 10:00 AM, Michael Tuexen > wrote: > >> >>> On 06 Apr 2016, at 08:18, RFC Errata System >>> wrote: >>> >>> The following errata report has been submitted for RFC4960, >>> "Stream Control Transmission Protocol". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=4960&eid=4656 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Lionel Morand >>> >>> Section: GLOBAL >>> >>> Original Text >>> ------------- >>> 6.2. Acknowledgement on Reception of DATA Chunks >>> >>> The SCTP endpoint MUST always acknowledge the reception of each valid >>> DATA chunk when the DATA chunk received is inside its receive window. >>> >>> When the receiver's advertised window is 0, the receiver MUST drop >>> any new incoming DATA chunk with a TSN larger than the largest TSN >>> received so far. If the new incoming DATA chunk holds a TSN value >>> less than the largest TSN received so far, then the receiver SHOULD >>> drop the largest TSN held for reordering and accept the new incoming >>> DATA chunk. In either case, if such a DATA chunk is dropped, the >>> receiver MUST immediately send back a SACK with the current receive >>> window showing only DATA chunks received and accepted so far. The >>> dropped DATA chunk(s) MUST NOT be included in the SACK, as they were >>> not accepted. The receiver MUST also have an algorithm for >>> advertising its receive window to avoid receiver silly window >>> syndrome (SWS), as described in [RFC0813]. The algorithm can be >>> similar to the one described in Section 4.2.3.3 of [RFC1122]. >>> >>> The guidelines on delayed acknowledgement algorithm specified in >>> Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an >>> acknowledgement SHOULD be generated for at least every second packet >>> (not every second DATA chunk) received, and SHOULD be generated >>> within 200 ms of the arrival of any unacknowledged DATA chunk. In >>> some situations, it may be beneficial for an SCTP transmitter to be >>> more conservative than the algorithms detailed in this document >>> allow. However, an SCTP transmitter MUST NOT be more aggressive than >>> the following algorithms allow. >>> >>> An SCTP receiver MUST NOT generate more than one SACK for every >>> incoming packet, other than to update the offered window as the >>> receiving application consumes new data. >>> >>> IMPLEMENTATION NOTE: The maximum delay for generating an >>> acknowledgement may be configured by the SCTP administrator, either >>> statically or dynamically, in order to meet the specific timing >>> requirement of the protocol being carried. >>> >>> An implementation MUST NOT allow the maximum delay to be configured >>> to be more than 500 ms. In other words, an implementation MAY lower >>> this value below 500 ms but MUST NOT raise it above 500 ms. >>> >>> [ remaining of the section unchanged ] >>> >>> *********************************************************************** >>> 15. Suggested SCTP Protocol Parameter Values >>> >>> The following protocol parameters are RECOMMENDED: >>> >>> RTO.Initial - 3 seconds >>> RTO.Min - 1 second >>> RTO.Max - 60 seconds >>> Max.Burst - 4 >>> RTO.Alpha - 1/8 >>> RTO.Beta - 1/4 >>> Valid.Cookie.Life - 60 seconds >>> Association.Max.Retrans - 10 attempts >>> Path.Max.Retrans - 5 attempts (per destination address) >>> Max.Init.Retransmits - 8 attempts >>> HB.interval - 30 seconds >>> HB.Max.Burst - 1 >>> >>> IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to >>> customize some of these protocol parameters (see Section 10). >>> >>> Note: RTO.Min SHOULD be set as recommended above. >>> >>> Corrected Text >>> -------------- >>> 6.2. Acknowledgement on Reception of DATA Chunks >>> >>> The SCTP endpoint MUST always acknowledge the reception of each valid >>> DATA chunk when the DATA chunk received is inside its receive window. >>> >>> When the receiver's advertised window is 0, the receiver MUST drop >>> any new incoming DATA chunk with a TSN larger than the largest TSN >>> received so far. If the new incoming DATA chunk holds a TSN value >>> less than the largest TSN received so far, then the receiver SHOULD >>> drop the largest TSN held for reordering and accept the new incoming >>> DATA chunk. In either case, if such a DATA chunk is dropped, the >>> receiver MUST immediately send back a SACK with the current receive >>> window showing only DATA chunks received and accepted so far. The >>> dropped DATA chunk(s) MUST NOT be included in the SACK, as they were >>> not accepted. The receiver MUST also have an algorithm for >>> advertising its receive window to avoid receiver silly window >>> syndrome (SWS), as described in [RFC0813]. The algorithm can be >>> similar to the one described in Section 4.2.3.3 of [RFC1122]. >>> >>> The guidelines on delayed acknowledgement algorithm specified in >>> Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an >>> acknowledgement SHOULD be generated for at least every second packet >>> (not every second DATA chunk) received, and SHOULD be generated >>> within 200 ms of the arrival of any unacknowledged DATA chunk. In >>> some situations, it may be beneficial for an SCTP transmitter to be >>> more conservative than the algorithms detailed in this document >>> allow. However, an SCTP transmitter MUST NOT be more aggressive than >>> the following algorithms allow. >>> >>> An SCTP receiver MUST NOT generate more than one SACK for every >>> incoming packet, other than to update the offered window as the >>> receiving application consumes new data. >>> >>> IMPLEMENTATION NOTE: The maximum delay for generating an >>> acknowledgement may be configured by the SCTP administrator, either >>> statically or dynamically, in order to meet the specific timing >>> requirement of the protocol being carried. >>> >>> An implementation MUST NOT allow the maximum delay (protocol >>> parameter 'SACK.Delay') to be configured to be more than 500 ms. >>> In other words, an implementation MAY lower the value of >>> 'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms. >>> >>> [ remaining of the section unchanged ] >>> >>> *********************************************************************** >>> 15. Suggested SCTP Protocol Parameter Values >>> >>> The following protocol parameters are RECOMMENDED: >>> >>> RTO.Initial - 3 seconds >>> RTO.Min - 1 second >>> RTO.Max - 60 seconds >>> Max.Burst - 4 >>> RTO.Alpha - 1/8 >>> RTO.Beta - 1/4 >>> Valid.Cookie.Life - 60 seconds >>> Association.Max.Retrans - 10 attempts >>> Path.Max.Retrans - 5 attempts (per destination address) >>> Max.Init.Retransmits - 8 attempts >>> HB.interval - 30 seconds >>> HB.Max.Burst - 1 >>> SACK.Delay - 200 milliseconds >>> >>> IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to >>> customize some of these protocol parameters (see Section 10). >>> >>> Note: RTO.Min SHOULD be set as recommended above. >>> >>> Notes >>> ----- >>> In section 6.2, the name 'SACK.Delay' is given to the protocol >>> parameter that indicate themaximum delay for generating a SACK. >>> >>> In section 15, the list of SCTP protocol parameters and associated >>> recommended value is not complete. The maximum delay for generating an >>> acknowledgement ('SACK.Delay') is missing from this list. >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC4960 (draft-ietf-tsvwg-2960bis-05) >>> -------------------------------------- >>> Title : Stream Control Transmission Protocol >>> Publication Date : September 2007 >>> Author(s) : R. Stewart, Ed. >>> Category : PROPOSED STANDARD >>> Source : Transport Area Working Group >>> Area : Transport >>> Stream : IETF >>> Verifying Party : IESG >>> >> This looks good to me. This SACK.delay parameter should have been listed >> in the table. >> >> Best regards >> Michael >> > > -------- > Randall Stewart > rrs@netflix.com > 803-317-4952 > > > > > > From nobody Wed Apr 6 08:06:34 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7427912D85F for ; Wed, 6 Apr 2016 08:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 qxMJZbm2Pc7d for ; Wed, 6 Apr 2016 08:06:26 -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 0F89812D6D7 for ; Wed, 6 Apr 2016 08:02:47 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 42C311B001CD; Wed, 6 Apr 2016 16:14:53 +0100 (BST) Received: from 31.133.155.3 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Wed, 6 Apr 2016 16:02:46 +0100 Message-ID: <0396d9f4a09005fafbaee8c876ca8c5c.squirrel@erg.abdn.ac.uk> In-Reply-To: References: <20160406111821.B8CF718000C@rfc-editor.org> <527C8FB5-16A5-46DE-8C5C-EE3E382F32BC@lurchi.franken.de> Date: Wed, 6 Apr 2016 16:02:46 +0100 From: gorry@erg.abdn.ac.uk To: "Randall Stewart" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: Gorry Fairhurst , tsvwg@ietf.org, mls.ietf@gmail.com, Randall Ray Stewart , =?iso-8859-1?Q?=22Michael_T=FCxen=22?= , RFC Errata System Subject: Re: [tsvwg] [Technical Errata Reported] RFC4960 (4656) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 15:06:30 -0000 It seems like some sort of Errata may be useful to advise people of this issue. However, there's probably more text here than I'd have expected in an Errata. I suspect the original intention was that "delay" in the original text was to refer to 'SACK.Delay', as below: "An implementation MUST NOT allow the maximum delay (protocol parameter 'SACK.Delay') to be configured to be more than 500 ms. In other words, an implementation MAY lower the value of 'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms." Does more need to be noted as text changes in the Errata? (Also noting the table addition). Gorry > > > I agree this should have been listed in the table.. not sure we need > the word changes (see sack table) that have been added here > > But we *should* have put the sack-delay 200ms in the table.. > > R > On Apr 6, 2016, at 10:00 AM, Michael Tuexen > wrote: > >> >>> On 06 Apr 2016, at 08:18, RFC Errata System >>> wrote: >>> >>> The following errata report has been submitted for RFC4960, >>> "Stream Control Transmission Protocol". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=4960&eid=4656 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Lionel Morand >>> >>> Section: GLOBAL >>> >>> Original Text >>> ------------- >>> 6.2. Acknowledgement on Reception of DATA Chunks >>> >>> The SCTP endpoint MUST always acknowledge the reception of each valid >>> DATA chunk when the DATA chunk received is inside its receive window. >>> >>> When the receiver's advertised window is 0, the receiver MUST drop >>> any new incoming DATA chunk with a TSN larger than the largest TSN >>> received so far. If the new incoming DATA chunk holds a TSN value >>> less than the largest TSN received so far, then the receiver SHOULD >>> drop the largest TSN held for reordering and accept the new incoming >>> DATA chunk. In either case, if such a DATA chunk is dropped, the >>> receiver MUST immediately send back a SACK with the current receive >>> window showing only DATA chunks received and accepted so far. The >>> dropped DATA chunk(s) MUST NOT be included in the SACK, as they were >>> not accepted. The receiver MUST also have an algorithm for >>> advertising its receive window to avoid receiver silly window >>> syndrome (SWS), as described in [RFC0813]. The algorithm can be >>> similar to the one described in Section 4.2.3.3 of [RFC1122]. >>> >>> The guidelines on delayed acknowledgement algorithm specified in >>> Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an >>> acknowledgement SHOULD be generated for at least every second packet >>> (not every second DATA chunk) received, and SHOULD be generated >>> within 200 ms of the arrival of any unacknowledged DATA chunk. In >>> some situations, it may be beneficial for an SCTP transmitter to be >>> more conservative than the algorithms detailed in this document >>> allow. However, an SCTP transmitter MUST NOT be more aggressive than >>> the following algorithms allow. >>> >>> An SCTP receiver MUST NOT generate more than one SACK for every >>> incoming packet, other than to update the offered window as the >>> receiving application consumes new data. >>> >>> IMPLEMENTATION NOTE: The maximum delay for generating an >>> acknowledgement may be configured by the SCTP administrator, either >>> statically or dynamically, in order to meet the specific timing >>> requirement of the protocol being carried. >>> >>> An implementation MUST NOT allow the maximum delay to be configured >>> to be more than 500 ms. In other words, an implementation MAY lower >>> this value below 500 ms but MUST NOT raise it above 500 ms. >>> >>> [ remaining of the section unchanged ] >>> >>> *********************************************************************** >>> 15. Suggested SCTP Protocol Parameter Values >>> >>> The following protocol parameters are RECOMMENDED: >>> >>> RTO.Initial - 3 seconds >>> RTO.Min - 1 second >>> RTO.Max - 60 seconds >>> Max.Burst - 4 >>> RTO.Alpha - 1/8 >>> RTO.Beta - 1/4 >>> Valid.Cookie.Life - 60 seconds >>> Association.Max.Retrans - 10 attempts >>> Path.Max.Retrans - 5 attempts (per destination address) >>> Max.Init.Retransmits - 8 attempts >>> HB.interval - 30 seconds >>> HB.Max.Burst - 1 >>> >>> IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to >>> customize some of these protocol parameters (see Section 10). >>> >>> Note: RTO.Min SHOULD be set as recommended above. >>> >>> Corrected Text >>> -------------- >>> 6.2. Acknowledgement on Reception of DATA Chunks >>> >>> The SCTP endpoint MUST always acknowledge the reception of each valid >>> DATA chunk when the DATA chunk received is inside its receive window. >>> >>> When the receiver's advertised window is 0, the receiver MUST drop >>> any new incoming DATA chunk with a TSN larger than the largest TSN >>> received so far. If the new incoming DATA chunk holds a TSN value >>> less than the largest TSN received so far, then the receiver SHOULD >>> drop the largest TSN held for reordering and accept the new incoming >>> DATA chunk. In either case, if such a DATA chunk is dropped, the >>> receiver MUST immediately send back a SACK with the current receive >>> window showing only DATA chunks received and accepted so far. The >>> dropped DATA chunk(s) MUST NOT be included in the SACK, as they were >>> not accepted. The receiver MUST also have an algorithm for >>> advertising its receive window to avoid receiver silly window >>> syndrome (SWS), as described in [RFC0813]. The algorithm can be >>> similar to the one described in Section 4.2.3.3 of [RFC1122]. >>> >>> The guidelines on delayed acknowledgement algorithm specified in >>> Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an >>> acknowledgement SHOULD be generated for at least every second packet >>> (not every second DATA chunk) received, and SHOULD be generated >>> within 200 ms of the arrival of any unacknowledged DATA chunk. In >>> some situations, it may be beneficial for an SCTP transmitter to be >>> more conservative than the algorithms detailed in this document >>> allow. However, an SCTP transmitter MUST NOT be more aggressive than >>> the following algorithms allow. >>> >>> An SCTP receiver MUST NOT generate more than one SACK for every >>> incoming packet, other than to update the offered window as the >>> receiving application consumes new data. >>> >>> IMPLEMENTATION NOTE: The maximum delay for generating an >>> acknowledgement may be configured by the SCTP administrator, either >>> statically or dynamically, in order to meet the specific timing >>> requirement of the protocol being carried. >>> >>> An implementation MUST NOT allow the maximum delay (protocol >>> parameter 'SACK.Delay') to be configured to be more than 500 ms. >>> In other words, an implementation MAY lower the value of >>> 'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms. >>> >>> [ remaining of the section unchanged ] >>> >>> *********************************************************************** >>> 15. Suggested SCTP Protocol Parameter Values >>> >>> The following protocol parameters are RECOMMENDED: >>> >>> RTO.Initial - 3 seconds >>> RTO.Min - 1 second >>> RTO.Max - 60 seconds >>> Max.Burst - 4 >>> RTO.Alpha - 1/8 >>> RTO.Beta - 1/4 >>> Valid.Cookie.Life - 60 seconds >>> Association.Max.Retrans - 10 attempts >>> Path.Max.Retrans - 5 attempts (per destination address) >>> Max.Init.Retransmits - 8 attempts >>> HB.interval - 30 seconds >>> HB.Max.Burst - 1 >>> SACK.Delay - 200 milliseconds >>> >>> IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to >>> customize some of these protocol parameters (see Section 10). >>> >>> Note: RTO.Min SHOULD be set as recommended above. >>> >>> Notes >>> ----- >>> In section 6.2, the name 'SACK.Delay' is given to the protocol >>> parameter that indicate themaximum delay for generating a SACK. >>> >>> In section 15, the list of SCTP protocol parameters and associated >>> recommended value is not complete. The maximum delay for generating an >>> acknowledgement ('SACK.Delay') is missing from this list. >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC4960 (draft-ietf-tsvwg-2960bis-05) >>> -------------------------------------- >>> Title : Stream Control Transmission Protocol >>> Publication Date : September 2007 >>> Author(s) : R. Stewart, Ed. >>> Category : PROPOSED STANDARD >>> Source : Transport Area Working Group >>> Area : Transport >>> Stream : IETF >>> Verifying Party : IESG >>> >> This looks good to me. This SACK.delay parameter should have been listed >> in the table. >> >> Best regards >> Michael >> > > -------- > Randall Stewart > rrs@netflix.com > 803-317-4952 > > > > > > From nobody Wed Apr 6 08:55:44 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770FB12D1A9 for ; Wed, 6 Apr 2016 08:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 EfvMU66B2KTA for ; Wed, 6 Apr 2016 08:55:33 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A42312D19E for ; Wed, 6 Apr 2016 08:55:33 -0700 (PDT) Received: from dhcp-89ec.meeting.ietf.org (unknown [31.133.139.236]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 43169721E280E; Wed, 6 Apr 2016 17:55:27 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen X-Priority: 3 (Normal) In-Reply-To: <0396d9f4a09005fafbaee8c876ca8c5c.squirrel@erg.abdn.ac.uk> Date: Wed, 6 Apr 2016 12:55:24 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <75455A46-31E7-4081-A155-1264119527C5@lurchi.franken.de> References: <20160406111821.B8CF718000C@rfc-editor.org> <527C8FB5-16A5-46DE-8C5C-EE3E382F32BC@lurchi.franken.de> <0396d9f4a09005fafbaee8c876ca8c5c.squirrel@erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.3124) Archived-At: Cc: mls.ietf@gmail.com, RFC Errata System , Randall Ray Stewart , tsvwg@ietf.org Subject: Re: [tsvwg] [Technical Errata Reported] RFC4960 (4656) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 15:55:41 -0000 > On 06 Apr 2016, at 12:02, gorry@erg.abdn.ac.uk wrote: >=20 > It seems like some sort of Errata may be useful to advise people of = this > issue. >=20 > However, there's probably more text here than I'd have expected in an = Errata. >=20 > I suspect the original intention was that "delay" in the original = text was > to refer to 'SACK.Delay', as below: >=20 > "An implementation MUST NOT allow the maximum delay (protocol > parameter 'SACK.Delay') to be configured to be more than 500 ms. > In other words, an implementation MAY lower the value of > 'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms." >=20 > Does more need to be noted as text changes in the Errata? (Also noting = the > table addition). I don't think so. Best regards Michael >=20 > Gorry >>=20 >>=20 >> I agree this should have been listed in the table.. not sure we need >> the word changes (see sack table) that have been added here >=20 >>=20 >> But we *should* have put the sack-delay 200ms in the table.. >>=20 >> R >> On Apr 6, 2016, at 10:00 AM, Michael Tuexen >> wrote: >>=20 >>>=20 >>>> On 06 Apr 2016, at 08:18, RFC Errata System = >>>> wrote: >>>>=20 >>>> The following errata report has been submitted for RFC4960, >>>> "Stream Control Transmission Protocol". >>>>=20 >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=3D4960&eid=3D4656 >>>>=20 >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Lionel Morand >>>>=20 >>>> Section: GLOBAL >>>>=20 >>>> Original Text >>>> ------------- >>>> 6.2. Acknowledgement on Reception of DATA Chunks >>>>=20 >>>> The SCTP endpoint MUST always acknowledge the reception of each = valid >>>> DATA chunk when the DATA chunk received is inside its receive = window. >>>>=20 >>>> When the receiver's advertised window is 0, the receiver MUST drop >>>> any new incoming DATA chunk with a TSN larger than the largest TSN >>>> received so far. If the new incoming DATA chunk holds a TSN value >>>> less than the largest TSN received so far, then the receiver SHOULD >>>> drop the largest TSN held for reordering and accept the new = incoming >>>> DATA chunk. In either case, if such a DATA chunk is dropped, the >>>> receiver MUST immediately send back a SACK with the current receive >>>> window showing only DATA chunks received and accepted so far. The >>>> dropped DATA chunk(s) MUST NOT be included in the SACK, as they = were >>>> not accepted. The receiver MUST also have an algorithm for >>>> advertising its receive window to avoid receiver silly window >>>> syndrome (SWS), as described in [RFC0813]. The algorithm can be >>>> similar to the one described in Section 4.2.3.3 of [RFC1122]. >>>>=20 >>>> The guidelines on delayed acknowledgement algorithm specified in >>>> Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an >>>> acknowledgement SHOULD be generated for at least every second = packet >>>> (not every second DATA chunk) received, and SHOULD be generated >>>> within 200 ms of the arrival of any unacknowledged DATA chunk. In >>>> some situations, it may be beneficial for an SCTP transmitter to be >>>> more conservative than the algorithms detailed in this document >>>> allow. However, an SCTP transmitter MUST NOT be more aggressive = than >>>> the following algorithms allow. >>>>=20 >>>> An SCTP receiver MUST NOT generate more than one SACK for every >>>> incoming packet, other than to update the offered window as the >>>> receiving application consumes new data. >>>>=20 >>>> IMPLEMENTATION NOTE: The maximum delay for generating an >>>> acknowledgement may be configured by the SCTP administrator, either >>>> statically or dynamically, in order to meet the specific timing >>>> requirement of the protocol being carried. >>>>=20 >>>> An implementation MUST NOT allow the maximum delay to be configured >>>> to be more than 500 ms. In other words, an implementation MAY = lower >>>> this value below 500 ms but MUST NOT raise it above 500 ms. >>>>=20 >>>> [ remaining of the section unchanged ] >>>>=20 >>>> = *********************************************************************** >>>> 15. Suggested SCTP Protocol Parameter Values >>>>=20 >>>> The following protocol parameters are RECOMMENDED: >>>>=20 >>>> RTO.Initial - 3 seconds >>>> RTO.Min - 1 second >>>> RTO.Max - 60 seconds >>>> Max.Burst - 4 >>>> RTO.Alpha - 1/8 >>>> RTO.Beta - 1/4 >>>> Valid.Cookie.Life - 60 seconds >>>> Association.Max.Retrans - 10 attempts >>>> Path.Max.Retrans - 5 attempts (per destination address) >>>> Max.Init.Retransmits - 8 attempts >>>> HB.interval - 30 seconds >>>> HB.Max.Burst - 1 >>>>=20 >>>> IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to >>>> customize some of these protocol parameters (see Section 10). >>>>=20 >>>> Note: RTO.Min SHOULD be set as recommended above. >>>>=20 >>>> Corrected Text >>>> -------------- >>>> 6.2. Acknowledgement on Reception of DATA Chunks >>>>=20 >>>> The SCTP endpoint MUST always acknowledge the reception of each = valid >>>> DATA chunk when the DATA chunk received is inside its receive = window. >>>>=20 >>>> When the receiver's advertised window is 0, the receiver MUST drop >>>> any new incoming DATA chunk with a TSN larger than the largest TSN >>>> received so far. If the new incoming DATA chunk holds a TSN value >>>> less than the largest TSN received so far, then the receiver SHOULD >>>> drop the largest TSN held for reordering and accept the new = incoming >>>> DATA chunk. In either case, if such a DATA chunk is dropped, the >>>> receiver MUST immediately send back a SACK with the current receive >>>> window showing only DATA chunks received and accepted so far. The >>>> dropped DATA chunk(s) MUST NOT be included in the SACK, as they = were >>>> not accepted. The receiver MUST also have an algorithm for >>>> advertising its receive window to avoid receiver silly window >>>> syndrome (SWS), as described in [RFC0813]. The algorithm can be >>>> similar to the one described in Section 4.2.3.3 of [RFC1122]. >>>>=20 >>>> The guidelines on delayed acknowledgement algorithm specified in >>>> Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an >>>> acknowledgement SHOULD be generated for at least every second = packet >>>> (not every second DATA chunk) received, and SHOULD be generated >>>> within 200 ms of the arrival of any unacknowledged DATA chunk. In >>>> some situations, it may be beneficial for an SCTP transmitter to be >>>> more conservative than the algorithms detailed in this document >>>> allow. However, an SCTP transmitter MUST NOT be more aggressive = than >>>> the following algorithms allow. >>>>=20 >>>> An SCTP receiver MUST NOT generate more than one SACK for every >>>> incoming packet, other than to update the offered window as the >>>> receiving application consumes new data. >>>>=20 >>>> IMPLEMENTATION NOTE: The maximum delay for generating an >>>> acknowledgement may be configured by the SCTP administrator, either >>>> statically or dynamically, in order to meet the specific timing >>>> requirement of the protocol being carried. >>>>=20 >>>> An implementation MUST NOT allow the maximum delay (protocol >>>> parameter 'SACK.Delay') to be configured to be more than 500 ms. >>>> In other words, an implementation MAY lower the value of >>>> 'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms. >>>>=20 >>>> [ remaining of the section unchanged ] >>>>=20 >>>> = *********************************************************************** >>>> 15. Suggested SCTP Protocol Parameter Values >>>>=20 >>>> The following protocol parameters are RECOMMENDED: >>>>=20 >>>> RTO.Initial - 3 seconds >>>> RTO.Min - 1 second >>>> RTO.Max - 60 seconds >>>> Max.Burst - 4 >>>> RTO.Alpha - 1/8 >>>> RTO.Beta - 1/4 >>>> Valid.Cookie.Life - 60 seconds >>>> Association.Max.Retrans - 10 attempts >>>> Path.Max.Retrans - 5 attempts (per destination address) >>>> Max.Init.Retransmits - 8 attempts >>>> HB.interval - 30 seconds >>>> HB.Max.Burst - 1 >>>> SACK.Delay - 200 milliseconds >>>>=20 >>>> IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to >>>> customize some of these protocol parameters (see Section 10). >>>>=20 >>>> Note: RTO.Min SHOULD be set as recommended above. >>>>=20 >>>> Notes >>>> ----- >>>> In section 6.2, the name 'SACK.Delay' is given to the protocol >>>> parameter that indicate themaximum delay for generating a SACK. >>>>=20 >>>> In section 15, the list of SCTP protocol parameters and associated >>>> recommended value is not complete. The maximum delay for generating = an >>>> acknowledgement ('SACK.Delay') is missing from this list. >>>>=20 >>>> Instructions: >>>> ------------- >>>> This erratum is currently posted as "Reported". If necessary, = please >>>> use "Reply All" to discuss whether it should be verified or >>>> rejected. When a decision is reached, the verifying party (IESG) >>>> can log in to change the status and edit the report, if necessary. >>>>=20 >>>> -------------------------------------- >>>> RFC4960 (draft-ietf-tsvwg-2960bis-05) >>>> -------------------------------------- >>>> Title : Stream Control Transmission Protocol >>>> Publication Date : September 2007 >>>> Author(s) : R. Stewart, Ed. >>>> Category : PROPOSED STANDARD >>>> Source : Transport Area Working Group >>>> Area : Transport >>>> Stream : IETF >>>> Verifying Party : IESG >>>>=20 >>> This looks good to me. This SACK.delay parameter should have been = listed >>> in the table. >>>=20 >>> Best regards >>> Michael >>>=20 >>=20 >> -------- >> Randall Stewart >> rrs@netflix.com >> 803-317-4952 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 From nobody Wed Apr 6 10:23:04 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFF312D6D3 for ; Wed, 6 Apr 2016 10:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 6YN9rJeC2JSZ for ; Wed, 6 Apr 2016 10:23:01 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7C8812D6CB for ; Wed, 6 Apr 2016 10:22:58 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 37DF7403E6; Wed, 6 Apr 2016 19:22:57 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.83]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id EF3D91A0057; Wed, 6 Apr 2016 19:22:56 +0200 (CEST) Received: from OPEXCNORM4D.corporate.adroot.infra.ftgroup ([fe80::604f:15da:866b:fd8b]) by OPEXCNORMAF.corporate.adroot.infra.ftgroup ([fe80::e1dd:62fe:d378:e3f8%21]) with mapi id 14.03.0279.002; Wed, 6 Apr 2016 19:22:56 +0200 From: To: Michael Tuexen , Gorry Fairhurst Thread-Topic: [tsvwg] [Technical Errata Reported] RFC4960 (4656) Thread-Index: AQHRj/Yp6yDRRhqrKEaVgky0ckM4dJ98xyGAgAAC2gCAAB9SAIAADrUAgAA5f7A= Date: Wed, 6 Apr 2016 17:22:55 +0000 Message-ID: <10367_1459963377_570545F0_10367_19607_1_6B7134B31289DC4FAF731D844122B36E01E2E734@OPEXCNORM4D.corporate.adroot.infra.ftgroup> References: <20160406111821.B8CF718000C@rfc-editor.org> <527C8FB5-16A5-46DE-8C5C-EE3E382F32BC@lurchi.franken.de> <0396d9f4a09005fafbaee8c876ca8c5c.squirrel@erg.abdn.ac.uk> <75455A46-31E7-4081-A155-1264119527C5@lurchi.franken.de> In-Reply-To: <75455A46-31E7-4081-A155-1264119527C5@lurchi.franken.de> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mls.ietf@gmail.com" , "tsvwg@ietf.org" , Randall Ray Stewart , RFC Errata System Subject: Re: [tsvwg] [Technical Errata Reported] RFC4960 (4656) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:23:03 -0000 Hi Gorry, the first change is just to introduce the name of the protocol parameter. = Otherwise not possible to just list 'SACK.Delay' in the table. Except that, I don't think that any other additional changes is required. Regards, Lionel > -----Message d'origine----- > De=A0: tsvwg [mailto:tsvwg-bounces@ietf.org] De la part de Michael Tuexen > Envoy=E9=A0: mercredi 6 avril 2016 17:55 > =C0=A0: Gorry Fairhurst > Cc=A0: mls.ietf@gmail.com; RFC Errata System; Randall Ray Stewart; > tsvwg@ietf.org > Objet=A0: Re: [tsvwg] [Technical Errata Reported] RFC4960 (4656) >=20 > > On 06 Apr 2016, at 12:02, gorry@erg.abdn.ac.uk wrote: > > > > It seems like some sort of Errata may be useful to advise people of > > this issue. > > > > However, there's probably more text here than I'd have expected in an > Errata. > > > > I suspect the original intention was that "delay" in the original > > text was to refer to 'SACK.Delay', as below: > > > > "An implementation MUST NOT allow the maximum delay (protocol > > parameter 'SACK.Delay') to be configured to be more than 500 ms. > > In other words, an implementation MAY lower the value of > > 'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms." > > > > Does more need to be noted as text changes in the Errata? (Also noting > > the table addition). > I don't think so. >=20 > Best regards > Michael > > > > Gorry > >> > >> > >> I agree this should have been listed in the table.. not sure we need > >> the word changes (see sack table) that have been added here > > > >> > >> But we *should* have put the sack-delay 200ms in the table.. > >> > >> R > >> On Apr 6, 2016, at 10:00 AM, Michael Tuexen > >> wrote: > >> > >>> > >>>> On 06 Apr 2016, at 08:18, RFC Errata System > >>>> > >>>> wrote: > >>>> > >>>> The following errata report has been submitted for RFC4960, "Stream > >>>> Control Transmission Protocol". > >>>> > >>>> -------------------------------------- > >>>> You may review the report below and at: > >>>> http://www.rfc-editor.org/errata_search.php?rfc=3D4960&eid=3D4656 > >>>> > >>>> -------------------------------------- > >>>> Type: Technical > >>>> Reported by: Lionel Morand > >>>> > >>>> Section: GLOBAL > >>>> > >>>> Original Text > >>>> ------------- > >>>> 6.2. Acknowledgement on Reception of DATA Chunks > >>>> > >>>> The SCTP endpoint MUST always acknowledge the reception of each > >>>> valid DATA chunk when the DATA chunk received is inside its receive > window. > >>>> > >>>> When the receiver's advertised window is 0, the receiver MUST drop > >>>> any new incoming DATA chunk with a TSN larger than the largest TSN > >>>> received so far. If the new incoming DATA chunk holds a TSN value > >>>> less than the largest TSN received so far, then the receiver SHOULD > >>>> drop the largest TSN held for reordering and accept the new > >>>> incoming DATA chunk. In either case, if such a DATA chunk is > >>>> dropped, the receiver MUST immediately send back a SACK with the > >>>> current receive window showing only DATA chunks received and > >>>> accepted so far. The dropped DATA chunk(s) MUST NOT be included in > >>>> the SACK, as they were not accepted. The receiver MUST also have > >>>> an algorithm for advertising its receive window to avoid receiver > >>>> silly window syndrome (SWS), as described in [RFC0813]. The > >>>> algorithm can be similar to the one described in Section 4.2.3.3 of > [RFC1122]. > >>>> > >>>> The guidelines on delayed acknowledgement algorithm specified in > >>>> Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an > >>>> acknowledgement SHOULD be generated for at least every second > >>>> packet (not every second DATA chunk) received, and SHOULD be > >>>> generated within 200 ms of the arrival of any unacknowledged DATA > >>>> chunk. In some situations, it may be beneficial for an SCTP > >>>> transmitter to be more conservative than the algorithms detailed in > >>>> this document allow. However, an SCTP transmitter MUST NOT be > more > >>>> aggressive than the following algorithms allow. > >>>> > >>>> An SCTP receiver MUST NOT generate more than one SACK for every > >>>> incoming packet, other than to update the offered window as the > >>>> receiving application consumes new data. > >>>> > >>>> IMPLEMENTATION NOTE: The maximum delay for generating an > >>>> acknowledgement may be configured by the SCTP administrator, either > >>>> statically or dynamically, in order to meet the specific timing > >>>> requirement of the protocol being carried. > >>>> > >>>> An implementation MUST NOT allow the maximum delay to be > configured > >>>> to be more than 500 ms. In other words, an implementation MAY > >>>> lower this value below 500 ms but MUST NOT raise it above 500 ms. > >>>> > >>>> [ remaining of the section unchanged ] > >>>> > >>>> > ********************************************************** > ********* > >>>> **** 15. Suggested SCTP Protocol Parameter Values > >>>> > >>>> The following protocol parameters are RECOMMENDED: > >>>> > >>>> RTO.Initial - 3 seconds > >>>> RTO.Min - 1 second > >>>> RTO.Max - 60 seconds > >>>> Max.Burst - 4 > >>>> RTO.Alpha - 1/8 > >>>> RTO.Beta - 1/4 > >>>> Valid.Cookie.Life - 60 seconds > >>>> Association.Max.Retrans - 10 attempts > >>>> Path.Max.Retrans - 5 attempts (per destination address) > >>>> Max.Init.Retransmits - 8 attempts > >>>> HB.interval - 30 seconds > >>>> HB.Max.Burst - 1 > >>>> > >>>> IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to > >>>> customize some of these protocol parameters (see Section 10). > >>>> > >>>> Note: RTO.Min SHOULD be set as recommended above. > >>>> > >>>> Corrected Text > >>>> -------------- > >>>> 6.2. Acknowledgement on Reception of DATA Chunks > >>>> > >>>> The SCTP endpoint MUST always acknowledge the reception of each > >>>> valid DATA chunk when the DATA chunk received is inside its receive > window. > >>>> > >>>> When the receiver's advertised window is 0, the receiver MUST drop > >>>> any new incoming DATA chunk with a TSN larger than the largest TSN > >>>> received so far. If the new incoming DATA chunk holds a TSN value > >>>> less than the largest TSN received so far, then the receiver SHOULD > >>>> drop the largest TSN held for reordering and accept the new > >>>> incoming DATA chunk. In either case, if such a DATA chunk is > >>>> dropped, the receiver MUST immediately send back a SACK with the > >>>> current receive window showing only DATA chunks received and > >>>> accepted so far. The dropped DATA chunk(s) MUST NOT be included in > >>>> the SACK, as they were not accepted. The receiver MUST also have > >>>> an algorithm for advertising its receive window to avoid receiver > >>>> silly window syndrome (SWS), as described in [RFC0813]. The > >>>> algorithm can be similar to the one described in Section 4.2.3.3 of > [RFC1122]. > >>>> > >>>> The guidelines on delayed acknowledgement algorithm specified in > >>>> Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an > >>>> acknowledgement SHOULD be generated for at least every second > >>>> packet (not every second DATA chunk) received, and SHOULD be > >>>> generated within 200 ms of the arrival of any unacknowledged DATA > >>>> chunk. In some situations, it may be beneficial for an SCTP > >>>> transmitter to be more conservative than the algorithms detailed in > >>>> this document allow. However, an SCTP transmitter MUST NOT be > more > >>>> aggressive than the following algorithms allow. > >>>> > >>>> An SCTP receiver MUST NOT generate more than one SACK for every > >>>> incoming packet, other than to update the offered window as the > >>>> receiving application consumes new data. > >>>> > >>>> IMPLEMENTATION NOTE: The maximum delay for generating an > >>>> acknowledgement may be configured by the SCTP administrator, either > >>>> statically or dynamically, in order to meet the specific timing > >>>> requirement of the protocol being carried. > >>>> > >>>> An implementation MUST NOT allow the maximum delay (protocol > >>>> parameter 'SACK.Delay') to be configured to be more than 500 ms. > >>>> In other words, an implementation MAY lower the value of > >>>> 'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms. > >>>> > >>>> [ remaining of the section unchanged ] > >>>> > >>>> > ********************************************************** > ********* > >>>> **** 15. Suggested SCTP Protocol Parameter Values > >>>> > >>>> The following protocol parameters are RECOMMENDED: > >>>> > >>>> RTO.Initial - 3 seconds > >>>> RTO.Min - 1 second > >>>> RTO.Max - 60 seconds > >>>> Max.Burst - 4 > >>>> RTO.Alpha - 1/8 > >>>> RTO.Beta - 1/4 > >>>> Valid.Cookie.Life - 60 seconds > >>>> Association.Max.Retrans - 10 attempts > >>>> Path.Max.Retrans - 5 attempts (per destination address) > >>>> Max.Init.Retransmits - 8 attempts > >>>> HB.interval - 30 seconds > >>>> HB.Max.Burst - 1 > >>>> SACK.Delay - 200 milliseconds > >>>> > >>>> IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to > >>>> customize some of these protocol parameters (see Section 10). > >>>> > >>>> Note: RTO.Min SHOULD be set as recommended above. > >>>> > >>>> Notes > >>>> ----- > >>>> In section 6.2, the name 'SACK.Delay' is given to the protocol > >>>> parameter that indicate themaximum delay for generating a SACK. > >>>> > >>>> In section 15, the list of SCTP protocol parameters and associated > >>>> recommended value is not complete. The maximum delay for > generating > >>>> an acknowledgement ('SACK.Delay') is missing from this list. > >>>> > >>>> Instructions: > >>>> ------------- > >>>> This erratum is currently posted as "Reported". If necessary, > >>>> please use "Reply All" to discuss whether it should be verified or > >>>> rejected. When a decision is reached, the verifying party (IESG) > >>>> can log in to change the status and edit the report, if necessary. > >>>> > >>>> -------------------------------------- > >>>> RFC4960 (draft-ietf-tsvwg-2960bis-05) > >>>> -------------------------------------- > >>>> Title : Stream Control Transmission Protocol > >>>> Publication Date : September 2007 > >>>> Author(s) : R. Stewart, Ed. > >>>> Category : PROPOSED STANDARD > >>>> Source : Transport Area Working Group > >>>> Area : Transport > >>>> Stream : IETF > >>>> Verifying Party : IESG > >>>> > >>> This looks good to me. This SACK.delay parameter should have been > >>> listed in the table. > >>> > >>> Best regards > >>> Michael > >>> > >> > >> -------- > >> Randall Stewart > >> rrs@netflix.com > >> 803-317-4952 > >> > >> > >> > >> > >> > >> > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Apr 6 10:33:27 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB7112D6E4 for ; Wed, 6 Apr 2016 10:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 wH6L-8UjKOLp for ; Wed, 6 Apr 2016 10:33:16 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B173F12D6D9 for ; Wed, 6 Apr 2016 10:33:15 -0700 (PDT) Received: from [IPv6:2001:67c:370:152:49e3:1990:8bdf:afc3] (unknown [IPv6:2001:67c:370:152:49e3:1990:8bdf:afc3]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 053FC721E280E; Wed, 6 Apr 2016 19:33:09 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Tuexen In-Reply-To: <10367_1459963377_570545F0_10367_19607_1_6B7134B31289DC4FAF731D844122B36E01E2E734@OPEXCNORM4D.corporate.adroot.infra.ftgroup> Date: Wed, 6 Apr 2016 14:33:06 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160406111821.B8CF718000C@rfc-editor.org> <527C8FB5-16A5-46DE-8C5C-EE3E382F32BC@lurchi.franken.de> <0396d9f4a09005fafbaee8c876ca8c5c.squirrel@erg.abdn.ac.uk> <75455A46-31E7-4081-A155-1264119527C5@lurchi.franken.de> <10367_1459963377_570545F0_10367_19607_1_6B7134B31289DC4FAF731D844122B36E01E2E734@OPEXCNORM4D.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Gorry Fairhurst , "mls.ietf@gmail.com" , "tsvwg@ietf.org" , Randall Ray Stewart , RFC Errata System Subject: Re: [tsvwg] [Technical Errata Reported] RFC4960 (4656) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:33:27 -0000 > On 06 Apr 2016, at 14:22, = wrote: >=20 > Hi Gorry, >=20 > the first change is just to introduce the name of the protocol = parameter. Otherwise not possible to just list 'SACK.Delay' in the = table. ... I think it is citing a long block of text where only a single = sentence is changed. But that is hard to catch. Possibly only showing the paragraph which has the small text change = would have been easier to read. Not sure if an Errata can be edited... Best regards Michael > Except that, I don't think that any other additional changes is = required. >=20 > Regards, >=20 > Lionel >=20 >> -----Message d'origine----- >> De : tsvwg [mailto:tsvwg-bounces@ietf.org] De la part de Michael = Tuexen >> Envoy=E9 : mercredi 6 avril 2016 17:55 >> =C0 : Gorry Fairhurst >> Cc : mls.ietf@gmail.com; RFC Errata System; Randall Ray Stewart; >> tsvwg@ietf.org >> Objet : Re: [tsvwg] [Technical Errata Reported] RFC4960 (4656) >>=20 >>> On 06 Apr 2016, at 12:02, gorry@erg.abdn.ac.uk wrote: >>>=20 >>> It seems like some sort of Errata may be useful to advise people of >>> this issue. >>>=20 >>> However, there's probably more text here than I'd have expected in = an >> Errata. >>>=20 >>> I suspect the original intention was that "delay" in the original >>> text was to refer to 'SACK.Delay', as below: >>>=20 >>> "An implementation MUST NOT allow the maximum delay (protocol >>> parameter 'SACK.Delay') to be configured to be more than 500 ms. >>> In other words, an implementation MAY lower the value of >>> 'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms." >>>=20 >>> Does more need to be noted as text changes in the Errata? (Also = noting >>> the table addition). >> I don't think so. >>=20 >> Best regards >> Michael >>>=20 >>> Gorry >>>>=20 >>>>=20 >>>> I agree this should have been listed in the table.. not sure we = need >>>> the word changes (see sack table) that have been added here >>>=20 >>>>=20 >>>> But we *should* have put the sack-delay 200ms in the table.. >>>>=20 >>>> R >>>> On Apr 6, 2016, at 10:00 AM, Michael Tuexen >>>> wrote: >>>>=20 >>>>>=20 >>>>>> On 06 Apr 2016, at 08:18, RFC Errata System >>>>>> >>>>>> wrote: >>>>>>=20 >>>>>> The following errata report has been submitted for RFC4960, = "Stream >>>>>> Control Transmission Protocol". >>>>>>=20 >>>>>> -------------------------------------- >>>>>> You may review the report below and at: >>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D4960&eid=3D4656 >>>>>>=20 >>>>>> -------------------------------------- >>>>>> Type: Technical >>>>>> Reported by: Lionel Morand >>>>>>=20 >>>>>> Section: GLOBAL >>>>>>=20 >>>>>> Original Text >>>>>> ------------- >>>>>> 6.2. Acknowledgement on Reception of DATA Chunks >>>>>>=20 >>>>>> The SCTP endpoint MUST always acknowledge the reception of each >>>>>> valid DATA chunk when the DATA chunk received is inside its = receive >> window. >>>>>>=20 >>>>>> When the receiver's advertised window is 0, the receiver MUST = drop >>>>>> any new incoming DATA chunk with a TSN larger than the largest = TSN >>>>>> received so far. If the new incoming DATA chunk holds a TSN = value >>>>>> less than the largest TSN received so far, then the receiver = SHOULD >>>>>> drop the largest TSN held for reordering and accept the new >>>>>> incoming DATA chunk. In either case, if such a DATA chunk is >>>>>> dropped, the receiver MUST immediately send back a SACK with the >>>>>> current receive window showing only DATA chunks received and >>>>>> accepted so far. The dropped DATA chunk(s) MUST NOT be included = in >>>>>> the SACK, as they were not accepted. The receiver MUST also have >>>>>> an algorithm for advertising its receive window to avoid receiver >>>>>> silly window syndrome (SWS), as described in [RFC0813]. The >>>>>> algorithm can be similar to the one described in Section 4.2.3.3 = of >> [RFC1122]. >>>>>>=20 >>>>>> The guidelines on delayed acknowledgement algorithm specified in >>>>>> Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an >>>>>> acknowledgement SHOULD be generated for at least every second >>>>>> packet (not every second DATA chunk) received, and SHOULD be >>>>>> generated within 200 ms of the arrival of any unacknowledged DATA >>>>>> chunk. In some situations, it may be beneficial for an SCTP >>>>>> transmitter to be more conservative than the algorithms detailed = in >>>>>> this document allow. However, an SCTP transmitter MUST NOT be >> more >>>>>> aggressive than the following algorithms allow. >>>>>>=20 >>>>>> An SCTP receiver MUST NOT generate more than one SACK for every >>>>>> incoming packet, other than to update the offered window as the >>>>>> receiving application consumes new data. >>>>>>=20 >>>>>> IMPLEMENTATION NOTE: The maximum delay for generating an >>>>>> acknowledgement may be configured by the SCTP administrator, = either >>>>>> statically or dynamically, in order to meet the specific timing >>>>>> requirement of the protocol being carried. >>>>>>=20 >>>>>> An implementation MUST NOT allow the maximum delay to be >> configured >>>>>> to be more than 500 ms. In other words, an implementation MAY >>>>>> lower this value below 500 ms but MUST NOT raise it above 500 ms. >>>>>>=20 >>>>>> [ remaining of the section unchanged ] >>>>>>=20 >>>>>>=20 >> ********************************************************** >> ********* >>>>>> **** 15. Suggested SCTP Protocol Parameter Values >>>>>>=20 >>>>>> The following protocol parameters are RECOMMENDED: >>>>>>=20 >>>>>> RTO.Initial - 3 seconds >>>>>> RTO.Min - 1 second >>>>>> RTO.Max - 60 seconds >>>>>> Max.Burst - 4 >>>>>> RTO.Alpha - 1/8 >>>>>> RTO.Beta - 1/4 >>>>>> Valid.Cookie.Life - 60 seconds >>>>>> Association.Max.Retrans - 10 attempts >>>>>> Path.Max.Retrans - 5 attempts (per destination address) >>>>>> Max.Init.Retransmits - 8 attempts >>>>>> HB.interval - 30 seconds >>>>>> HB.Max.Burst - 1 >>>>>>=20 >>>>>> IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to >>>>>> customize some of these protocol parameters (see Section 10). >>>>>>=20 >>>>>> Note: RTO.Min SHOULD be set as recommended above. >>>>>>=20 >>>>>> Corrected Text >>>>>> -------------- >>>>>> 6.2. Acknowledgement on Reception of DATA Chunks >>>>>>=20 >>>>>> The SCTP endpoint MUST always acknowledge the reception of each >>>>>> valid DATA chunk when the DATA chunk received is inside its = receive >> window. >>>>>>=20 >>>>>> When the receiver's advertised window is 0, the receiver MUST = drop >>>>>> any new incoming DATA chunk with a TSN larger than the largest = TSN >>>>>> received so far. If the new incoming DATA chunk holds a TSN = value >>>>>> less than the largest TSN received so far, then the receiver = SHOULD >>>>>> drop the largest TSN held for reordering and accept the new >>>>>> incoming DATA chunk. In either case, if such a DATA chunk is >>>>>> dropped, the receiver MUST immediately send back a SACK with the >>>>>> current receive window showing only DATA chunks received and >>>>>> accepted so far. The dropped DATA chunk(s) MUST NOT be included = in >>>>>> the SACK, as they were not accepted. The receiver MUST also have >>>>>> an algorithm for advertising its receive window to avoid receiver >>>>>> silly window syndrome (SWS), as described in [RFC0813]. The >>>>>> algorithm can be similar to the one described in Section 4.2.3.3 = of >> [RFC1122]. >>>>>>=20 >>>>>> The guidelines on delayed acknowledgement algorithm specified in >>>>>> Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an >>>>>> acknowledgement SHOULD be generated for at least every second >>>>>> packet (not every second DATA chunk) received, and SHOULD be >>>>>> generated within 200 ms of the arrival of any unacknowledged DATA >>>>>> chunk. In some situations, it may be beneficial for an SCTP >>>>>> transmitter to be more conservative than the algorithms detailed = in >>>>>> this document allow. However, an SCTP transmitter MUST NOT be >> more >>>>>> aggressive than the following algorithms allow. >>>>>>=20 >>>>>> An SCTP receiver MUST NOT generate more than one SACK for every >>>>>> incoming packet, other than to update the offered window as the >>>>>> receiving application consumes new data. >>>>>>=20 >>>>>> IMPLEMENTATION NOTE: The maximum delay for generating an >>>>>> acknowledgement may be configured by the SCTP administrator, = either >>>>>> statically or dynamically, in order to meet the specific timing >>>>>> requirement of the protocol being carried. >>>>>>=20 >>>>>> An implementation MUST NOT allow the maximum delay (protocol >>>>>> parameter 'SACK.Delay') to be configured to be more than 500 ms. >>>>>> In other words, an implementation MAY lower the value of >>>>>> 'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms. >>>>>>=20 >>>>>> [ remaining of the section unchanged ] >>>>>>=20 >>>>>>=20 >> ********************************************************** >> ********* >>>>>> **** 15. Suggested SCTP Protocol Parameter Values >>>>>>=20 >>>>>> The following protocol parameters are RECOMMENDED: >>>>>>=20 >>>>>> RTO.Initial - 3 seconds >>>>>> RTO.Min - 1 second >>>>>> RTO.Max - 60 seconds >>>>>> Max.Burst - 4 >>>>>> RTO.Alpha - 1/8 >>>>>> RTO.Beta - 1/4 >>>>>> Valid.Cookie.Life - 60 seconds >>>>>> Association.Max.Retrans - 10 attempts >>>>>> Path.Max.Retrans - 5 attempts (per destination address) >>>>>> Max.Init.Retransmits - 8 attempts >>>>>> HB.interval - 30 seconds >>>>>> HB.Max.Burst - 1 >>>>>> SACK.Delay - 200 milliseconds >>>>>>=20 >>>>>> IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to >>>>>> customize some of these protocol parameters (see Section 10). >>>>>>=20 >>>>>> Note: RTO.Min SHOULD be set as recommended above. >>>>>>=20 >>>>>> Notes >>>>>> ----- >>>>>> In section 6.2, the name 'SACK.Delay' is given to the protocol >>>>>> parameter that indicate themaximum delay for generating a SACK. >>>>>>=20 >>>>>> In section 15, the list of SCTP protocol parameters and = associated >>>>>> recommended value is not complete. The maximum delay for >> generating >>>>>> an acknowledgement ('SACK.Delay') is missing from this list. >>>>>>=20 >>>>>> Instructions: >>>>>> ------------- >>>>>> This erratum is currently posted as "Reported". If necessary, >>>>>> please use "Reply All" to discuss whether it should be verified = or >>>>>> rejected. When a decision is reached, the verifying party (IESG) >>>>>> can log in to change the status and edit the report, if = necessary. >>>>>>=20 >>>>>> -------------------------------------- >>>>>> RFC4960 (draft-ietf-tsvwg-2960bis-05) >>>>>> -------------------------------------- >>>>>> Title : Stream Control Transmission Protocol >>>>>> Publication Date : September 2007 >>>>>> Author(s) : R. Stewart, Ed. >>>>>> Category : PROPOSED STANDARD >>>>>> Source : Transport Area Working Group >>>>>> Area : Transport >>>>>> Stream : IETF >>>>>> Verifying Party : IESG >>>>>>=20 >>>>> This looks good to me. This SACK.delay parameter should have been >>>>> listed in the table. >>>>>=20 >>>>> Best regards >>>>> Michael >>>>>=20 >>>>=20 >>>> -------- >>>> Randall Stewart >>>> rrs@netflix.com >>>> 803-317-4952 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 From nobody Wed Apr 6 10:34:52 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E903712D6DC for ; Wed, 6 Apr 2016 10:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 f69oOwHcXk-s for ; Wed, 6 Apr 2016 10:34:42 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id B48F212D6EA for ; Wed, 6 Apr 2016 10:34:26 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id D4D131B001C8 for ; Wed, 6 Apr 2016 18:46:38 +0100 (BST) Received: from 31.133.155.3 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Wed, 6 Apr 2016 18:34:26 +0100 Message-ID: <6071f3219132d739701804efda25b820.squirrel@erg.abdn.ac.uk> Date: Wed, 6 Apr 2016 18:34:26 +0100 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: [tsvwg] TSVWG Agenda today X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:34:50 -0000 The updated agenda is below (from the proceedings page). We'll need a note taker and person in the jabber room for the meeting. Volunteers are most welcome! Gorry ---- 16:20-17:20 Wednesday Afternoon session II 7. Agenda Recap (5 minutes) WG Chairs: Gorry Fairhurst and David Black (remote) assisted by Martin Stiemerling Note Taker 1: ?? Note Taker 2: ?? 8. WG Transport Encaps Drafts 8.1 Bob Briscoe - Guidelines for adding Congestion Notification to Protocols that Encapsulate IP (10 minutes) draft-ietf-tsvwg-ecn-encap-guidelines 9. Individual Drafts 9.1 Tim Szigeti - Mapping to 802.11 (15 minutes) draft-szigeti-tsvwg-ieee-802-11 [Please read and comment on ID - WG Adoption requested] 9.2 Bob Briscoe - Identifying Modified ECN Semantics for Ultra-Low Queuing Delay (10 minutes) draft-briscoe-tsvwg-ecn-l4s-id-00 9.3. Naeem Khademi - TCP Alternative Backoff with ECN (ABE) (10 minutes) draft-khademi-alternativebackoff-ecn Slides are here: https://www.ietf.org/proceedings/95/slides/slides-95-tsvwg-15.pdf From nobody Wed Apr 6 10:41:43 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F1112D6FB for ; Wed, 6 Apr 2016 10:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 H0Vr8te5ERlj for ; Wed, 6 Apr 2016 10:41:32 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8D3612D6E4 for ; Wed, 6 Apr 2016 10:41:28 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 8AB8B1803E0; Wed, 6 Apr 2016 19:41:27 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.52]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 57B191A0057; Wed, 6 Apr 2016 19:41:27 +0200 (CEST) Received: from OPEXCNORM4D.corporate.adroot.infra.ftgroup ([fe80::604f:15da:866b:fd8b]) by OPEXCNORM54.corporate.adroot.infra.ftgroup ([fe80::d4c1:bb8:4040:a2bb%21]) with mapi id 14.03.0279.002; Wed, 6 Apr 2016 19:41:27 +0200 From: To: Michael Tuexen Thread-Topic: [tsvwg] [Technical Errata Reported] RFC4960 (4656) Thread-Index: AQHRj/Yp6yDRRhqrKEaVgky0ckM4dJ98xyGAgAAC2gCAAB9SAIAADrUAgAA5f7D//+HNAIAAI9EQ Date: Wed, 6 Apr 2016 17:41:26 +0000 Message-ID: <4567_1459964487_57054A47_4567_404_1_6B7134B31289DC4FAF731D844122B36E01E2E78F@OPEXCNORM4D.corporate.adroot.infra.ftgroup> References: <20160406111821.B8CF718000C@rfc-editor.org> <527C8FB5-16A5-46DE-8C5C-EE3E382F32BC@lurchi.franken.de> <0396d9f4a09005fafbaee8c876ca8c5c.squirrel@erg.abdn.ac.uk> <75455A46-31E7-4081-A155-1264119527C5@lurchi.franken.de> <10367_1459963377_570545F0_10367_19607_1_6B7134B31289DC4FAF731D844122B36E01E2E734@OPEXCNORM4D.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Gorry Fairhurst , "mls.ietf@gmail.com" , "tsvwg@ietf.org" , Randall Ray Stewart , RFC Errata System Subject: Re: [tsvwg] [Technical Errata Reported] RFC4960 (4656) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:41:41 -0000 Understood! If the report can be edited, a copy/paste of only the modified paragraph co= uld be enough. Policies vary depending on the WG. Lionel > -----Message d'origine----- > De=A0: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] > Envoy=E9=A0: mercredi 6 avril 2016 19:33 > =C0=A0: MORAND Lionel IMT/OLN > Cc=A0: Gorry Fairhurst; mls.ietf@gmail.com; tsvwg@ietf.org; Randall Ray > Stewart; RFC Errata System > Objet=A0: Re: [tsvwg] [Technical Errata Reported] RFC4960 (4656) >=20 > > On 06 Apr 2016, at 14:22, > wrote: > > > > Hi Gorry, > > > > the first change is just to introduce the name of the protocol paramet= er. > Otherwise not possible to just list 'SACK.Delay' in the table. > ... I think it is citing a long block of text where only a single sentenc= e is > changed. > But that is hard to catch. >=20 > Possibly only showing the paragraph which has the small text change would > have been easier to read. Not sure if an Errata can be edited... >=20 > Best regards > Michael > > Except that, I don't think that any other additional changes is require= d. > > > > Regards, > > > > Lionel > > > >> -----Message d'origine----- > >> De : tsvwg [mailto:tsvwg-bounces@ietf.org] De la part de Michael > >> Tuexen Envoy=E9 : mercredi 6 avril 2016 17:55 =C0 : Gorry Fairhurst Cc= : > >> mls.ietf@gmail.com; RFC Errata System; Randall Ray Stewart; > >> tsvwg@ietf.org Objet : Re: [tsvwg] [Technical Errata Reported] > >> RFC4960 (4656) > >> > >>> On 06 Apr 2016, at 12:02, gorry@erg.abdn.ac.uk wrote: > >>> > >>> It seems like some sort of Errata may be useful to advise people of > >>> this issue. > >>> > >>> However, there's probably more text here than I'd have expected in > >>> an > >> Errata. > >>> > >>> I suspect the original intention was that "delay" in the original > >>> text was to refer to 'SACK.Delay', as below: > >>> > >>> "An implementation MUST NOT allow the maximum delay (protocol > >>> parameter 'SACK.Delay') to be configured to be more than 500 ms. > >>> In other words, an implementation MAY lower the value of > >>> 'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms." > >>> > >>> Does more need to be noted as text changes in the Errata? (Also > >>> noting the table addition). > >> I don't think so. > >> > >> Best regards > >> Michael > >>> > >>> Gorry > >>>> > >>>> > >>>> I agree this should have been listed in the table.. not sure we > >>>> need the word changes (see sack table) that have been added here > >>> > >>>> > >>>> But we *should* have put the sack-delay 200ms in the table.. > >>>> > >>>> R > >>>> On Apr 6, 2016, at 10:00 AM, Michael Tuexen > >>>> wrote: > >>>> > >>>>> > >>>>>> On 06 Apr 2016, at 08:18, RFC Errata System > >>>>>> > >>>>>> wrote: > >>>>>> > >>>>>> The following errata report has been submitted for RFC4960, > >>>>>> "Stream Control Transmission Protocol". > >>>>>> > >>>>>> -------------------------------------- > >>>>>> You may review the report below and at: > >>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D4960&eid=3D4656 > >>>>>> > >>>>>> -------------------------------------- > >>>>>> Type: Technical > >>>>>> Reported by: Lionel Morand > >>>>>> > >>>>>> Section: GLOBAL > >>>>>> > >>>>>> Original Text > >>>>>> ------------- > >>>>>> 6.2. Acknowledgement on Reception of DATA Chunks > >>>>>> > >>>>>> The SCTP endpoint MUST always acknowledge the reception of each > >>>>>> valid DATA chunk when the DATA chunk received is inside its > >>>>>> receive > >> window. > >>>>>> > >>>>>> When the receiver's advertised window is 0, the receiver MUST > >>>>>> drop any new incoming DATA chunk with a TSN larger than the > >>>>>> largest TSN received so far. If the new incoming DATA chunk > >>>>>> holds a TSN value less than the largest TSN received so far, then > >>>>>> the receiver SHOULD drop the largest TSN held for reordering and > >>>>>> accept the new incoming DATA chunk. In either case, if such a > >>>>>> DATA chunk is dropped, the receiver MUST immediately send back a > >>>>>> SACK with the current receive window showing only DATA chunks > >>>>>> received and accepted so far. The dropped DATA chunk(s) MUST > NOT > >>>>>> be included in the SACK, as they were not accepted. The receiver > >>>>>> MUST also have an algorithm for advertising its receive window to > >>>>>> avoid receiver silly window syndrome (SWS), as described in > >>>>>> [RFC0813]. The algorithm can be similar to the one described in > >>>>>> Section 4.2.3.3 of > >> [RFC1122]. > >>>>>> > >>>>>> The guidelines on delayed acknowledgement algorithm specified in > >>>>>> Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an > >>>>>> acknowledgement SHOULD be generated for at least every second > >>>>>> packet (not every second DATA chunk) received, and SHOULD be > >>>>>> generated within 200 ms of the arrival of any unacknowledged DATA > >>>>>> chunk. In some situations, it may be beneficial for an SCTP > >>>>>> transmitter to be more conservative than the algorithms detailed > >>>>>> in this document allow. However, an SCTP transmitter MUST NOT be > >> more > >>>>>> aggressive than the following algorithms allow. > >>>>>> > >>>>>> An SCTP receiver MUST NOT generate more than one SACK for > every > >>>>>> incoming packet, other than to update the offered window as the > >>>>>> receiving application consumes new data. > >>>>>> > >>>>>> IMPLEMENTATION NOTE: The maximum delay for generating an > >>>>>> acknowledgement may be configured by the SCTP administrator, > >>>>>> either statically or dynamically, in order to meet the specific > >>>>>> timing requirement of the protocol being carried. > >>>>>> > >>>>>> An implementation MUST NOT allow the maximum delay to be > >> configured > >>>>>> to be more than 500 ms. In other words, an implementation MAY > >>>>>> lower this value below 500 ms but MUST NOT raise it above 500 ms. > >>>>>> > >>>>>> [ remaining of the section unchanged ] > >>>>>> > >>>>>> > >> > ********************************************************** > >> ********* > >>>>>> **** 15. Suggested SCTP Protocol Parameter Values > >>>>>> > >>>>>> The following protocol parameters are RECOMMENDED: > >>>>>> > >>>>>> RTO.Initial - 3 seconds > >>>>>> RTO.Min - 1 second > >>>>>> RTO.Max - 60 seconds > >>>>>> Max.Burst - 4 > >>>>>> RTO.Alpha - 1/8 > >>>>>> RTO.Beta - 1/4 > >>>>>> Valid.Cookie.Life - 60 seconds > >>>>>> Association.Max.Retrans - 10 attempts > >>>>>> Path.Max.Retrans - 5 attempts (per destination address) > >>>>>> Max.Init.Retransmits - 8 attempts > >>>>>> HB.interval - 30 seconds > >>>>>> HB.Max.Burst - 1 > >>>>>> > >>>>>> IMPLEMENTATION NOTE: The SCTP implementation may allow ULP > to > >>>>>> customize some of these protocol parameters (see Section 10). > >>>>>> > >>>>>> Note: RTO.Min SHOULD be set as recommended above. > >>>>>> > >>>>>> Corrected Text > >>>>>> -------------- > >>>>>> 6.2. Acknowledgement on Reception of DATA Chunks > >>>>>> > >>>>>> The SCTP endpoint MUST always acknowledge the reception of each > >>>>>> valid DATA chunk when the DATA chunk received is inside its > >>>>>> receive > >> window. > >>>>>> > >>>>>> When the receiver's advertised window is 0, the receiver MUST > >>>>>> drop any new incoming DATA chunk with a TSN larger than the > >>>>>> largest TSN received so far. If the new incoming DATA chunk > >>>>>> holds a TSN value less than the largest TSN received so far, then > >>>>>> the receiver SHOULD drop the largest TSN held for reordering and > >>>>>> accept the new incoming DATA chunk. In either case, if such a > >>>>>> DATA chunk is dropped, the receiver MUST immediately send back a > >>>>>> SACK with the current receive window showing only DATA chunks > >>>>>> received and accepted so far. The dropped DATA chunk(s) MUST > NOT > >>>>>> be included in the SACK, as they were not accepted. The receiver > >>>>>> MUST also have an algorithm for advertising its receive window to > >>>>>> avoid receiver silly window syndrome (SWS), as described in > >>>>>> [RFC0813]. The algorithm can be similar to the one described in > >>>>>> Section 4.2.3.3 of > >> [RFC1122]. > >>>>>> > >>>>>> The guidelines on delayed acknowledgement algorithm specified in > >>>>>> Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an > >>>>>> acknowledgement SHOULD be generated for at least every second > >>>>>> packet (not every second DATA chunk) received, and SHOULD be > >>>>>> generated within 200 ms of the arrival of any unacknowledged DATA > >>>>>> chunk. In some situations, it may be beneficial for an SCTP > >>>>>> transmitter to be more conservative than the algorithms detailed > >>>>>> in this document allow. However, an SCTP transmitter MUST NOT be > >> more > >>>>>> aggressive than the following algorithms allow. > >>>>>> > >>>>>> An SCTP receiver MUST NOT generate more than one SACK for > every > >>>>>> incoming packet, other than to update the offered window as the > >>>>>> receiving application consumes new data. > >>>>>> > >>>>>> IMPLEMENTATION NOTE: The maximum delay for generating an > >>>>>> acknowledgement may be configured by the SCTP administrator, > >>>>>> either statically or dynamically, in order to meet the specific > >>>>>> timing requirement of the protocol being carried. > >>>>>> > >>>>>> An implementation MUST NOT allow the maximum delay (protocol > >>>>>> parameter 'SACK.Delay') to be configured to be more than 500 ms. > >>>>>> In other words, an implementation MAY lower the value of > >>>>>> 'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms. > >>>>>> > >>>>>> [ remaining of the section unchanged ] > >>>>>> > >>>>>> > >> > ********************************************************** > >> ********* > >>>>>> **** 15. Suggested SCTP Protocol Parameter Values > >>>>>> > >>>>>> The following protocol parameters are RECOMMENDED: > >>>>>> > >>>>>> RTO.Initial - 3 seconds > >>>>>> RTO.Min - 1 second > >>>>>> RTO.Max - 60 seconds > >>>>>> Max.Burst - 4 > >>>>>> RTO.Alpha - 1/8 > >>>>>> RTO.Beta - 1/4 > >>>>>> Valid.Cookie.Life - 60 seconds > >>>>>> Association.Max.Retrans - 10 attempts > >>>>>> Path.Max.Retrans - 5 attempts (per destination address) > >>>>>> Max.Init.Retransmits - 8 attempts > >>>>>> HB.interval - 30 seconds > >>>>>> HB.Max.Burst - 1 > >>>>>> SACK.Delay - 200 milliseconds > >>>>>> > >>>>>> IMPLEMENTATION NOTE: The SCTP implementation may allow ULP > to > >>>>>> customize some of these protocol parameters (see Section 10). > >>>>>> > >>>>>> Note: RTO.Min SHOULD be set as recommended above. > >>>>>> > >>>>>> Notes > >>>>>> ----- > >>>>>> In section 6.2, the name 'SACK.Delay' is given to the protocol > >>>>>> parameter that indicate themaximum delay for generating a SACK. > >>>>>> > >>>>>> In section 15, the list of SCTP protocol parameters and > >>>>>> associated recommended value is not complete. The maximum > delay > >>>>>> for > >> generating > >>>>>> an acknowledgement ('SACK.Delay') is missing from this list. > >>>>>> > >>>>>> Instructions: > >>>>>> ------------- > >>>>>> This erratum is currently posted as "Reported". If necessary, > >>>>>> please use "Reply All" to discuss whether it should be verified > >>>>>> or rejected. When a decision is reached, the verifying party > >>>>>> (IESG) can log in to change the status and edit the report, if > necessary. > >>>>>> > >>>>>> -------------------------------------- > >>>>>> RFC4960 (draft-ietf-tsvwg-2960bis-05) > >>>>>> -------------------------------------- > >>>>>> Title : Stream Control Transmission Protocol > >>>>>> Publication Date : September 2007 > >>>>>> Author(s) : R. Stewart, Ed. > >>>>>> Category : PROPOSED STANDARD > >>>>>> Source : Transport Area Working Group > >>>>>> Area : Transport > >>>>>> Stream : IETF > >>>>>> Verifying Party : IESG > >>>>>> > >>>>> This looks good to me. This SACK.delay parameter should have been > >>>>> listed in the table. > >>>>> > >>>>> Best regards > >>>>> Michael > >>>>> > >>>> > >>>> -------- > >>>> Randall Stewart > >>>> rrs@netflix.com > >>>> 803-317-4952 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > > > > > > > __________________________________________________________ > ____________ > > ___________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu= e les > pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and = delete > this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have b= een > modified, changed or falsified. > > Thank you. > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Apr 6 10:53:43 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8142A12D18B for ; Wed, 6 Apr 2016 10:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 OLGcCzS6-6os for ; Wed, 6 Apr 2016 10:53:38 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id A61A612D6E8 for ; Wed, 6 Apr 2016 10:53:36 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id D81DE1B001C8; Wed, 6 Apr 2016 19:05:42 +0100 (BST) Received: from 31.133.155.3 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Wed, 6 Apr 2016 18:53:36 +0100 Message-ID: In-Reply-To: References: <20160406111821.B8CF718000C@rfc-editor.org> <527C8FB5-16A5-46DE-8C5C-EE3E382F32BC@lurchi.franken.de> <0396d9f4a09005fafbaee8c876ca8c5c.squirrel@erg.abdn.ac.uk> <75455A46-31E7-4081-A155-1264119527C5@lurchi.franken.de> <10367_1459963377_570545F0_10367_19607_1_6B7134B31289DC4FAF731D844122B36E01E2E734@OPEXCNORM4D.corporate.adroot.infra.ftgroup> Date: Wed, 6 Apr 2016 18:53:36 +0100 From: gorry@erg.abdn.ac.uk To: "Michael Tuexen" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: Gorry Fairhurst , "tsvwg@ietf.org" , "mls.ietf@gmail.com" , Randall Ray Stewart , RFC Errata System Subject: Re: [tsvwg] [Technical Errata Reported] RFC4960 (4656) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:53:41 -0000 I suggest we try to make a shorter text, can we manage to construct a new text in the following format: OLD: ...XXX NEW: ...XXX - It should then be possible to update the present Errata request in the system. (Or at least for someone with the correct permissions to do this). Gorry >> On 06 Apr 2016, at 14:22, >> wrote: >> >> Hi Gorry, >> >> the first change is just to introduce the name of the protocol >> parameter. Otherwise not possible to just list 'SACK.Delay' in the >> table. > ... I think it is citing a long block of text where only a single sentence > is changed. > But that is hard to catch. > > Possibly only showing the paragraph which has the small text change would > have > been easier to read. Not sure if an Errata can be edited... > > Best regards > Michael >> Except that, I don't think that any other additional changes is >> required. >> >> Regards, >> >> Lionel >> >>> -----Message d'origine----- >>> De : tsvwg [mailto:tsvwg-bounces@ietf.org] De la part de Michael Tuexen >>> Envoy : mercredi 6 avril 2016 17:55 >>> : Gorry Fairhurst >>> Cc : mls.ietf@gmail.com; RFC Errata System; Randall Ray Stewart; >>> tsvwg@ietf.org >>> Objet : Re: [tsvwg] [Technical Errata Reported] RFC4960 (4656) >>> >>>> On 06 Apr 2016, at 12:02, gorry@erg.abdn.ac.uk wrote: >>>> >>>> It seems like some sort of Errata may be useful to advise people of >>>> this issue. >>>> >>>> However, there's probably more text here than I'd have expected in an >>> Errata. >>>> >>>> I suspect the original intention was that "delay" in the original >>>> text was to refer to 'SACK.Delay', as below: >>>> >>>> "An implementation MUST NOT allow the maximum delay (protocol >>>> parameter 'SACK.Delay') to be configured to be more than 500 ms. >>>> In other words, an implementation MAY lower the value of >>>> 'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms." >>>> >>>> Does more need to be noted as text changes in the Errata? (Also noting >>>> the table addition). >>> I don't think so. >>> >>> Best regards >>> Michael >>>> >>>> Gorry >>>>> >>>>> >>>>> I agree this should have been listed in the table.. not sure we need >>>>> the word changes (see sack table) that have been added here >>>> >>>>> >>>>> But we *should* have put the sack-delay 200ms in the table.. >>>>> >>>>> R >>>>> On Apr 6, 2016, at 10:00 AM, Michael Tuexen >>>>> wrote: >>>>> >>>>>> >>>>>>> On 06 Apr 2016, at 08:18, RFC Errata System >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> The following errata report has been submitted for RFC4960, "Stream >>>>>>> Control Transmission Protocol". >>>>>>> >>>>>>> -------------------------------------- >>>>>>> You may review the report below and at: >>>>>>> http://www.rfc-editor.org/errata_search.php?rfc=4960&eid=4656 >>>>>>> >>>>>>> -------------------------------------- >>>>>>> Type: Technical >>>>>>> Reported by: Lionel Morand >>>>>>> >>>>>>> Section: GLOBAL >>>>>>> >>>>>>> Original Text >>>>>>> ------------- >>>>>>> 6.2. Acknowledgement on Reception of DATA Chunks >>>>>>> >>>>>>> The SCTP endpoint MUST always acknowledge the reception of each >>>>>>> valid DATA chunk when the DATA chunk received is inside its receive >>> window. >>>>>>> >>>>>>> When the receiver's advertised window is 0, the receiver MUST drop >>>>>>> any new incoming DATA chunk with a TSN larger than the largest TSN >>>>>>> received so far. If the new incoming DATA chunk holds a TSN value >>>>>>> less than the largest TSN received so far, then the receiver SHOULD >>>>>>> drop the largest TSN held for reordering and accept the new >>>>>>> incoming DATA chunk. In either case, if such a DATA chunk is >>>>>>> dropped, the receiver MUST immediately send back a SACK with the >>>>>>> current receive window showing only DATA chunks received and >>>>>>> accepted so far. The dropped DATA chunk(s) MUST NOT be included in >>>>>>> the SACK, as they were not accepted. The receiver MUST also have >>>>>>> an algorithm for advertising its receive window to avoid receiver >>>>>>> silly window syndrome (SWS), as described in [RFC0813]. The >>>>>>> algorithm can be similar to the one described in Section 4.2.3.3 of >>> [RFC1122]. >>>>>>> >>>>>>> The guidelines on delayed acknowledgement algorithm specified in >>>>>>> Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an >>>>>>> acknowledgement SHOULD be generated for at least every second >>>>>>> packet (not every second DATA chunk) received, and SHOULD be >>>>>>> generated within 200 ms of the arrival of any unacknowledged DATA >>>>>>> chunk. In some situations, it may be beneficial for an SCTP >>>>>>> transmitter to be more conservative than the algorithms detailed in >>>>>>> this document allow. However, an SCTP transmitter MUST NOT be >>> more >>>>>>> aggressive than the following algorithms allow. >>>>>>> >>>>>>> An SCTP receiver MUST NOT generate more than one SACK for every >>>>>>> incoming packet, other than to update the offered window as the >>>>>>> receiving application consumes new data. >>>>>>> >>>>>>> IMPLEMENTATION NOTE: The maximum delay for generating an >>>>>>> acknowledgement may be configured by the SCTP administrator, either >>>>>>> statically or dynamically, in order to meet the specific timing >>>>>>> requirement of the protocol being carried. >>>>>>> >>>>>>> An implementation MUST NOT allow the maximum delay to be >>> configured >>>>>>> to be more than 500 ms. In other words, an implementation MAY >>>>>>> lower this value below 500 ms but MUST NOT raise it above 500 ms. >>>>>>> >>>>>>> [ remaining of the section unchanged ] >>>>>>> >>>>>>> >>> ********************************************************** >>> ********* >>>>>>> **** 15. Suggested SCTP Protocol Parameter Values >>>>>>> >>>>>>> The following protocol parameters are RECOMMENDED: >>>>>>> >>>>>>> RTO.Initial - 3 seconds >>>>>>> RTO.Min - 1 second >>>>>>> RTO.Max - 60 seconds >>>>>>> Max.Burst - 4 >>>>>>> RTO.Alpha - 1/8 >>>>>>> RTO.Beta - 1/4 >>>>>>> Valid.Cookie.Life - 60 seconds >>>>>>> Association.Max.Retrans - 10 attempts >>>>>>> Path.Max.Retrans - 5 attempts (per destination address) >>>>>>> Max.Init.Retransmits - 8 attempts >>>>>>> HB.interval - 30 seconds >>>>>>> HB.Max.Burst - 1 >>>>>>> >>>>>>> IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to >>>>>>> customize some of these protocol parameters (see Section 10). >>>>>>> >>>>>>> Note: RTO.Min SHOULD be set as recommended above. >>>>>>> >>>>>>> Corrected Text >>>>>>> -------------- >>>>>>> 6.2. Acknowledgement on Reception of DATA Chunks >>>>>>> >>>>>>> The SCTP endpoint MUST always acknowledge the reception of each >>>>>>> valid DATA chunk when the DATA chunk received is inside its receive >>> window. >>>>>>> >>>>>>> When the receiver's advertised window is 0, the receiver MUST drop >>>>>>> any new incoming DATA chunk with a TSN larger than the largest TSN >>>>>>> received so far. If the new incoming DATA chunk holds a TSN value >>>>>>> less than the largest TSN received so far, then the receiver SHOULD >>>>>>> drop the largest TSN held for reordering and accept the new >>>>>>> incoming DATA chunk. In either case, if such a DATA chunk is >>>>>>> dropped, the receiver MUST immediately send back a SACK with the >>>>>>> current receive window showing only DATA chunks received and >>>>>>> accepted so far. The dropped DATA chunk(s) MUST NOT be included in >>>>>>> the SACK, as they were not accepted. The receiver MUST also have >>>>>>> an algorithm for advertising its receive window to avoid receiver >>>>>>> silly window syndrome (SWS), as described in [RFC0813]. The >>>>>>> algorithm can be similar to the one described in Section 4.2.3.3 of >>> [RFC1122]. >>>>>>> >>>>>>> The guidelines on delayed acknowledgement algorithm specified in >>>>>>> Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an >>>>>>> acknowledgement SHOULD be generated for at least every second >>>>>>> packet (not every second DATA chunk) received, and SHOULD be >>>>>>> generated within 200 ms of the arrival of any unacknowledged DATA >>>>>>> chunk. In some situations, it may be beneficial for an SCTP >>>>>>> transmitter to be more conservative than the algorithms detailed in >>>>>>> this document allow. However, an SCTP transmitter MUST NOT be >>> more >>>>>>> aggressive than the following algorithms allow. >>>>>>> >>>>>>> An SCTP receiver MUST NOT generate more than one SACK for every >>>>>>> incoming packet, other than to update the offered window as the >>>>>>> receiving application consumes new data. >>>>>>> >>>>>>> IMPLEMENTATION NOTE: The maximum delay for generating an >>>>>>> acknowledgement may be configured by the SCTP administrator, either >>>>>>> statically or dynamically, in order to meet the specific timing >>>>>>> requirement of the protocol being carried. >>>>>>> >>>>>>> An implementation MUST NOT allow the maximum delay (protocol >>>>>>> parameter 'SACK.Delay') to be configured to be more than 500 ms. >>>>>>> In other words, an implementation MAY lower the value of >>>>>>> 'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms. >>>>>>> >>>>>>> [ remaining of the section unchanged ] >>>>>>> >>>>>>> >>> ********************************************************** >>> ********* >>>>>>> **** 15. Suggested SCTP Protocol Parameter Values >>>>>>> >>>>>>> The following protocol parameters are RECOMMENDED: >>>>>>> >>>>>>> RTO.Initial - 3 seconds >>>>>>> RTO.Min - 1 second >>>>>>> RTO.Max - 60 seconds >>>>>>> Max.Burst - 4 >>>>>>> RTO.Alpha - 1/8 >>>>>>> RTO.Beta - 1/4 >>>>>>> Valid.Cookie.Life - 60 seconds >>>>>>> Association.Max.Retrans - 10 attempts >>>>>>> Path.Max.Retrans - 5 attempts (per destination address) >>>>>>> Max.Init.Retransmits - 8 attempts >>>>>>> HB.interval - 30 seconds >>>>>>> HB.Max.Burst - 1 >>>>>>> SACK.Delay - 200 milliseconds >>>>>>> >>>>>>> IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to >>>>>>> customize some of these protocol parameters (see Section 10). >>>>>>> >>>>>>> Note: RTO.Min SHOULD be set as recommended above. >>>>>>> >>>>>>> Notes >>>>>>> ----- >>>>>>> In section 6.2, the name 'SACK.Delay' is given to the protocol >>>>>>> parameter that indicate themaximum delay for generating a SACK. >>>>>>> >>>>>>> In section 15, the list of SCTP protocol parameters and associated >>>>>>> recommended value is not complete. The maximum delay for >>> generating >>>>>>> an acknowledgement ('SACK.Delay') is missing from this list. >>>>>>> >>>>>>> Instructions: >>>>>>> ------------- >>>>>>> This erratum is currently posted as "Reported". If necessary, >>>>>>> please use "Reply All" to discuss whether it should be verified or >>>>>>> rejected. When a decision is reached, the verifying party (IESG) >>>>>>> can log in to change the status and edit the report, if necessary. >>>>>>> >>>>>>> -------------------------------------- >>>>>>> RFC4960 (draft-ietf-tsvwg-2960bis-05) >>>>>>> -------------------------------------- >>>>>>> Title : Stream Control Transmission Protocol >>>>>>> Publication Date : September 2007 >>>>>>> Author(s) : R. Stewart, Ed. >>>>>>> Category : PROPOSED STANDARD >>>>>>> Source : Transport Area Working Group >>>>>>> Area : Transport >>>>>>> Stream : IETF >>>>>>> Verifying Party : IESG >>>>>>> >>>>>> This looks good to me. This SACK.delay parameter should have been >>>>>> listed in the table. >>>>>> >>>>>> Best regards >>>>>> Michael >>>>>> >>>>> >>>>> -------- >>>>> Randall Stewart >>>>> rrs@netflix.com >>>>> 803-317-4952 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >> >> >> _________________________________________________________________________________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme >> ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> Thank you. >> > From nobody Wed Apr 6 11:12:15 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD96112D0E7 for ; Wed, 6 Apr 2016 11:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 x3yFTCkZ3p_4 for ; Wed, 6 Apr 2016 11:12:06 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8F8C12D0E1 for ; Wed, 6 Apr 2016 11:12:05 -0700 (PDT) Received: from [IPv6:2001:67c:370:152:49e3:1990:8bdf:afc3] (unknown [IPv6:2001:67c:370:152:49e3:1990:8bdf:afc3]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 2553F721E280E; Wed, 6 Apr 2016 20:11:59 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 6 Apr 2016 15:11:55 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160406111821.B8CF718000C@rfc-editor.org> <527C8FB5-16A5-46DE-8C5C-EE3E382F32BC@lurchi.franken.de> <0396d9f4a09005fafbaee8c876ca8c5c.squirrel@erg.abdn.ac.uk> <75455A46-31E7-4081-A155-1264119527C5@lurchi.franken.de> <10367_1459963377_570545F0_10367_19607_1_6B7134B31289DC4FAF731D844122B36E01E2E734@OPEXCNORM4D.corporate.adroot.infra.ftgroup> To: Gorry Fairhurst X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "mls.ietf@gmail.com" , RFC Errata System , "tsvwg@ietf.org" , Randall Ray Stewart Subject: Re: [tsvwg] [Technical Errata Reported] RFC4960 (4656) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:12:14 -0000 > On 06 Apr 2016, at 14:53, gorry@erg.abdn.ac.uk wrote: >=20 >=20 > I suggest we try to make a shorter text, can we manage to construct a = new > text in the following format: >=20 > OLD: > ...XXX >=20 > NEW: > ...XXX >=20 > - It should then be possible to update the present Errata request in = the > system. (Or at least for someone with the correct permissions to do = this). What about: OLD: An implementation MUST NOT allow the maximum delay to be configured to be more than 500 ms. In other words, an implementation MAY lower this value below 500 ms but MUST NOT raise it above 500 ms. NEW: An implementation MUST NOT allow the maximum delay (protocol=20 parameter 'SACK.Delay') to be configured to be more than 500 ms. In other words, an implementation MAY lower the value of=20 'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms. OLD: The following protocol parameters are RECOMMENDED: RTO.Initial - 3 seconds RTO.Min - 1 second RTO.Max - 60 seconds Max.Burst - 4 RTO.Alpha - 1/8 RTO.Beta - 1/4 Valid.Cookie.Life - 60 seconds Association.Max.Retrans - 10 attempts Path.Max.Retrans - 5 attempts (per destination address) Max.Init.Retransmits - 8 attempts HB.interval - 30 seconds HB.Max.Burst - 1 NEW: The following protocol parameters are RECOMMENDED: RTO.Initial - 3 seconds RTO.Min - 1 second RTO.Max - 60 seconds Max.Burst - 4 RTO.Alpha - 1/8 RTO.Beta - 1/4 Valid.Cookie.Life - 60 seconds Association.Max.Retrans - 10 attempts Path.Max.Retrans - 5 attempts (per destination address) Max.Init.Retransmits - 8 attempts HB.interval - 30 seconds HB.Max.Burst - 1 SACK.Delay - 200 milliseconds Best regards Michael >=20 > Gorry >=20 >=20 >>> On 06 Apr 2016, at 14:22, >>> wrote: >>>=20 >>> Hi Gorry, >>>=20 >>> the first change is just to introduce the name of the protocol >>> parameter. Otherwise not possible to just list 'SACK.Delay' in the >>> table. >> ... I think it is citing a long block of text where only a single = sentence >> is changed. >> But that is hard to catch. >>=20 >> Possibly only showing the paragraph which has the small text change = would >> have >> been easier to read. Not sure if an Errata can be edited... >>=20 >> Best regards >> Michael >>> Except that, I don't think that any other additional changes is >>> required. >>>=20 >>> Regards, >>>=20 >>> Lionel >>>=20 >>>> -----Message d'origine----- >>>> De : tsvwg [mailto:tsvwg-bounces@ietf.org] De la part de Michael = Tuexen >>>> Envoy=E9 : mercredi 6 avril 2016 17:55 >>>> =C0 : Gorry Fairhurst >>>> Cc : mls.ietf@gmail.com; RFC Errata System; Randall Ray Stewart; >>>> tsvwg@ietf.org >>>> Objet : Re: [tsvwg] [Technical Errata Reported] RFC4960 (4656) >>>>=20 >>>>> On 06 Apr 2016, at 12:02, gorry@erg.abdn.ac.uk wrote: >>>>>=20 >>>>> It seems like some sort of Errata may be useful to advise people = of >>>>> this issue. >>>>>=20 >>>>> However, there's probably more text here than I'd have expected in = an >>>> Errata. >>>>>=20 >>>>> I suspect the original intention was that "delay" in the original >>>>> text was to refer to 'SACK.Delay', as below: >>>>>=20 >>>>> "An implementation MUST NOT allow the maximum delay (protocol >>>>> parameter 'SACK.Delay') to be configured to be more than 500 ms. >>>>> In other words, an implementation MAY lower the value of >>>>> 'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms." >>>>>=20 >>>>> Does more need to be noted as text changes in the Errata? (Also = noting >>>>> the table addition). >>>> I don't think so. >>>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>> Gorry >>>>>>=20 >>>>>>=20 >>>>>> I agree this should have been listed in the table.. not sure we = need >>>>>> the word changes (see sack table) that have been added here >>>>>=20 >>>>>>=20 >>>>>> But we *should* have put the sack-delay 200ms in the table.. >>>>>>=20 >>>>>> R >>>>>> On Apr 6, 2016, at 10:00 AM, Michael Tuexen >>>>>> wrote: >>>>>>=20 >>>>>>>=20 >>>>>>>> On 06 Apr 2016, at 08:18, RFC Errata System >>>>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>> The following errata report has been submitted for RFC4960, = "Stream >>>>>>>> Control Transmission Protocol". >>>>>>>>=20 >>>>>>>> -------------------------------------- >>>>>>>> You may review the report below and at: >>>>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D4960&eid=3D4656= >>>>>>>>=20 >>>>>>>> -------------------------------------- >>>>>>>> Type: Technical >>>>>>>> Reported by: Lionel Morand >>>>>>>>=20 >>>>>>>> Section: GLOBAL >>>>>>>>=20 >>>>>>>> Original Text >>>>>>>> ------------- >>>>>>>> 6.2. Acknowledgement on Reception of DATA Chunks >>>>>>>>=20 >>>>>>>> The SCTP endpoint MUST always acknowledge the reception of each >>>>>>>> valid DATA chunk when the DATA chunk received is inside its = receive >>>> window. >>>>>>>>=20 >>>>>>>> When the receiver's advertised window is 0, the receiver MUST = drop >>>>>>>> any new incoming DATA chunk with a TSN larger than the largest = TSN >>>>>>>> received so far. If the new incoming DATA chunk holds a TSN = value >>>>>>>> less than the largest TSN received so far, then the receiver = SHOULD >>>>>>>> drop the largest TSN held for reordering and accept the new >>>>>>>> incoming DATA chunk. In either case, if such a DATA chunk is >>>>>>>> dropped, the receiver MUST immediately send back a SACK with = the >>>>>>>> current receive window showing only DATA chunks received and >>>>>>>> accepted so far. The dropped DATA chunk(s) MUST NOT be = included in >>>>>>>> the SACK, as they were not accepted. The receiver MUST also = have >>>>>>>> an algorithm for advertising its receive window to avoid = receiver >>>>>>>> silly window syndrome (SWS), as described in [RFC0813]. The >>>>>>>> algorithm can be similar to the one described in Section = 4.2.3.3 of >>>> [RFC1122]. >>>>>>>>=20 >>>>>>>> The guidelines on delayed acknowledgement algorithm specified = in >>>>>>>> Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an >>>>>>>> acknowledgement SHOULD be generated for at least every second >>>>>>>> packet (not every second DATA chunk) received, and SHOULD be >>>>>>>> generated within 200 ms of the arrival of any unacknowledged = DATA >>>>>>>> chunk. In some situations, it may be beneficial for an SCTP >>>>>>>> transmitter to be more conservative than the algorithms = detailed in >>>>>>>> this document allow. However, an SCTP transmitter MUST NOT be >>>> more >>>>>>>> aggressive than the following algorithms allow. >>>>>>>>=20 >>>>>>>> An SCTP receiver MUST NOT generate more than one SACK for every >>>>>>>> incoming packet, other than to update the offered window as the >>>>>>>> receiving application consumes new data. >>>>>>>>=20 >>>>>>>> IMPLEMENTATION NOTE: The maximum delay for generating an >>>>>>>> acknowledgement may be configured by the SCTP administrator, = either >>>>>>>> statically or dynamically, in order to meet the specific timing >>>>>>>> requirement of the protocol being carried. >>>>>>>>=20 >>>>>>>> An implementation MUST NOT allow the maximum delay to be >>>> configured >>>>>>>> to be more than 500 ms. In other words, an implementation MAY >>>>>>>> lower this value below 500 ms but MUST NOT raise it above 500 = ms. >>>>>>>>=20 >>>>>>>> [ remaining of the section unchanged ] >>>>>>>>=20 >>>>>>>>=20 >>>> ********************************************************** >>>> ********* >>>>>>>> **** 15. Suggested SCTP Protocol Parameter Values >>>>>>>>=20 >>>>>>>> The following protocol parameters are RECOMMENDED: >>>>>>>>=20 >>>>>>>> RTO.Initial - 3 seconds >>>>>>>> RTO.Min - 1 second >>>>>>>> RTO.Max - 60 seconds >>>>>>>> Max.Burst - 4 >>>>>>>> RTO.Alpha - 1/8 >>>>>>>> RTO.Beta - 1/4 >>>>>>>> Valid.Cookie.Life - 60 seconds >>>>>>>> Association.Max.Retrans - 10 attempts >>>>>>>> Path.Max.Retrans - 5 attempts (per destination address) >>>>>>>> Max.Init.Retransmits - 8 attempts >>>>>>>> HB.interval - 30 seconds >>>>>>>> HB.Max.Burst - 1 >>>>>>>>=20 >>>>>>>> IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to >>>>>>>> customize some of these protocol parameters (see Section 10). >>>>>>>>=20 >>>>>>>> Note: RTO.Min SHOULD be set as recommended above. >>>>>>>>=20 >>>>>>>> Corrected Text >>>>>>>> -------------- >>>>>>>> 6.2. Acknowledgement on Reception of DATA Chunks >>>>>>>>=20 >>>>>>>> The SCTP endpoint MUST always acknowledge the reception of each >>>>>>>> valid DATA chunk when the DATA chunk received is inside its = receive >>>> window. >>>>>>>>=20 >>>>>>>> When the receiver's advertised window is 0, the receiver MUST = drop >>>>>>>> any new incoming DATA chunk with a TSN larger than the largest = TSN >>>>>>>> received so far. If the new incoming DATA chunk holds a TSN = value >>>>>>>> less than the largest TSN received so far, then the receiver = SHOULD >>>>>>>> drop the largest TSN held for reordering and accept the new >>>>>>>> incoming DATA chunk. In either case, if such a DATA chunk is >>>>>>>> dropped, the receiver MUST immediately send back a SACK with = the >>>>>>>> current receive window showing only DATA chunks received and >>>>>>>> accepted so far. The dropped DATA chunk(s) MUST NOT be = included in >>>>>>>> the SACK, as they were not accepted. The receiver MUST also = have >>>>>>>> an algorithm for advertising its receive window to avoid = receiver >>>>>>>> silly window syndrome (SWS), as described in [RFC0813]. The >>>>>>>> algorithm can be similar to the one described in Section = 4.2.3.3 of >>>> [RFC1122]. >>>>>>>>=20 >>>>>>>> The guidelines on delayed acknowledgement algorithm specified = in >>>>>>>> Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an >>>>>>>> acknowledgement SHOULD be generated for at least every second >>>>>>>> packet (not every second DATA chunk) received, and SHOULD be >>>>>>>> generated within 200 ms of the arrival of any unacknowledged = DATA >>>>>>>> chunk. In some situations, it may be beneficial for an SCTP >>>>>>>> transmitter to be more conservative than the algorithms = detailed in >>>>>>>> this document allow. However, an SCTP transmitter MUST NOT be >>>> more >>>>>>>> aggressive than the following algorithms allow. >>>>>>>>=20 >>>>>>>> An SCTP receiver MUST NOT generate more than one SACK for every >>>>>>>> incoming packet, other than to update the offered window as the >>>>>>>> receiving application consumes new data. >>>>>>>>=20 >>>>>>>> IMPLEMENTATION NOTE: The maximum delay for generating an >>>>>>>> acknowledgement may be configured by the SCTP administrator, = either >>>>>>>> statically or dynamically, in order to meet the specific timing >>>>>>>> requirement of the protocol being carried. >>>>>>>>=20 >>>>>>>> An implementation MUST NOT allow the maximum delay (protocol >>>>>>>> parameter 'SACK.Delay') to be configured to be more than 500 = ms. >>>>>>>> In other words, an implementation MAY lower the value of >>>>>>>> 'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms. >>>>>>>>=20 >>>>>>>> [ remaining of the section unchanged ] >>>>>>>>=20 >>>>>>>>=20 >>>> ********************************************************** >>>> ********* >>>>>>>> **** 15. Suggested SCTP Protocol Parameter Values >>>>>>>>=20 >>>>>>>> The following protocol parameters are RECOMMENDED: >>>>>>>>=20 >>>>>>>> RTO.Initial - 3 seconds >>>>>>>> RTO.Min - 1 second >>>>>>>> RTO.Max - 60 seconds >>>>>>>> Max.Burst - 4 >>>>>>>> RTO.Alpha - 1/8 >>>>>>>> RTO.Beta - 1/4 >>>>>>>> Valid.Cookie.Life - 60 seconds >>>>>>>> Association.Max.Retrans - 10 attempts >>>>>>>> Path.Max.Retrans - 5 attempts (per destination address) >>>>>>>> Max.Init.Retransmits - 8 attempts >>>>>>>> HB.interval - 30 seconds >>>>>>>> HB.Max.Burst - 1 >>>>>>>> SACK.Delay - 200 milliseconds >>>>>>>>=20 >>>>>>>> IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to >>>>>>>> customize some of these protocol parameters (see Section 10). >>>>>>>>=20 >>>>>>>> Note: RTO.Min SHOULD be set as recommended above. >>>>>>>>=20 >>>>>>>> Notes >>>>>>>> ----- >>>>>>>> In section 6.2, the name 'SACK.Delay' is given to the protocol >>>>>>>> parameter that indicate themaximum delay for generating a SACK. >>>>>>>>=20 >>>>>>>> In section 15, the list of SCTP protocol parameters and = associated >>>>>>>> recommended value is not complete. The maximum delay for >>>> generating >>>>>>>> an acknowledgement ('SACK.Delay') is missing from this list. >>>>>>>>=20 >>>>>>>> Instructions: >>>>>>>> ------------- >>>>>>>> This erratum is currently posted as "Reported". If necessary, >>>>>>>> please use "Reply All" to discuss whether it should be verified = or >>>>>>>> rejected. When a decision is reached, the verifying party = (IESG) >>>>>>>> can log in to change the status and edit the report, if = necessary. >>>>>>>>=20 >>>>>>>> -------------------------------------- >>>>>>>> RFC4960 (draft-ietf-tsvwg-2960bis-05) >>>>>>>> -------------------------------------- >>>>>>>> Title : Stream Control Transmission Protocol >>>>>>>> Publication Date : September 2007 >>>>>>>> Author(s) : R. Stewart, Ed. >>>>>>>> Category : PROPOSED STANDARD >>>>>>>> Source : Transport Area Working Group >>>>>>>> Area : Transport >>>>>>>> Stream : IETF >>>>>>>> Verifying Party : IESG >>>>>>>>=20 >>>>>>> This looks good to me. This SACK.delay parameter should have = been >>>>>>> listed in the table. >>>>>>>=20 >>>>>>> Best regards >>>>>>> Michael >>>>>>>=20 >>>>>>=20 >>>>>> -------- >>>>>> Randall Stewart >>>>>> rrs@netflix.com >>>>>> 803-317-4952 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>=20 >>>=20 >>> = __________________________________________________________________________= _______________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez >>> recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages >>> electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, = deforme >>> ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or = privileged >>> information that may be protected by law; >>> they should not be distributed, used or copied without = authorisation. >>> If you have received this email in error, please notify the sender = and >>> delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that = have >>> been modified, changed or falsified. >>> Thank you. >>>=20 >>=20 >=20 From nobody Wed Apr 6 16:44:28 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: [tsvwg] [aqm] [tcpm] [tcpPrague] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area 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 athttp://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 03:45:09 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: [tsvwg] [aqm] [tcpm] [tcpPrague] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area 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 athttp://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 04:13:58 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Cc: tcpm IETF list , tsvwg IETF list , "tsv-ads@ietf.org" , TCP Prague List , AQM IETF list Subject: Re: [tsvwg] [aqm] [tcpm] [tcpPrague] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area 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 05:03:38 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: [tsvwg] [aqm] [tcpm] [tcpPrague] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area 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 Fri Apr 8 06:19:48 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C835312D874 for ; Fri, 8 Apr 2016 06:19:46 -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 seHgBaQff5X6 for ; Fri, 8 Apr 2016 06:19:34 -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 42ED212D830 for ; Fri, 8 Apr 2016 06:19:34 -0700 (PDT) Received: from dhcp-b315.meeting.ietf.org ([31.133.179.21]:46732) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1aoWJv-00039T-H1; Fri, 08 Apr 2016 14:19:32 +0100 To: Ingemar Johansson S , "carlberg@g11.org.uk" , tsvwg IETF list References: <81564C0D7D4D2A4B9A86C8C7404A13DA43DC2347@ESESSMB205.ericsson.se> From: Bob Briscoe Message-ID: <5707AFE0.5080200@bobbriscoe.net> Date: Fri, 8 Apr 2016 14:19:28 +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: <81564C0D7D4D2A4B9A86C8C7404A13DA43DC2347@ESESSMB205.ericsson.se> Content-Type: multipart/alternative; boundary="------------040702060103040106070908" 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: Subject: Re: [tsvwg] 3GPP references to ECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 13:19:47 -0000 This is a multi-part message in MIME format. --------------040702060103040106070908 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Ingemar, Cc'ing the list as agreed... On 08/04/16 08:29, Ingemar Johansson S wrote: > > Hi > > A few comments inline below > > Will listen in on the TSVWG session ASAP. > > /Ingemar > > *From:*ken carlberg [mailto:carlberg@g11.org.uk] > *Sent:* den 7 april 2016 21:06 > *To:* Bob Briscoe > *Cc:* Ingemar Johansson S > *Subject:* 3GPP references to ECN > > Bob > > I very much liked your 3GPP references slide in the TSVWG > presentation. The one thing, though, that reminded me of a concern I > had with 3GPP’s support for ECN centers in an obscure sentence in > TS.29.162, end of Section 10.2.13.2 Incoming SDP offer with ECN, which > states: > > "The TrGW*_should_ *not send RTCP XR ECN summary reports.” > > This departs from RFC-6679, and I think the motivation stems from a > concern by IMS vendors that the rate of feedback would be excessive. > I agree that the RFC will clearly add more control traffic, but I’m > not in agreement that it is excessive. > > [IJ] I don’t have the full understanding of what happens in 3GPP, I > recall that there was a lot of discussion of the amount of overhead > that RTCP gives. But I never had any real influence in this area. > [BB] I can add Ken's point to the liaison, but if the 3GPP worded it the way it did in full knowledge of what was in the IETF RFC, and you tried to influence it at the time, but failed, that's a different problem from misunderstanding or lack of clarity between SDOs. We'll see what others think. > I bring this up in your references slide, you state that the L4-7 is > “fully compatible with EC-in-RTP”, which it is not. > > Also, my understanding is that the objective of some vendors/carriers > was to rely on a step-like function in having the codec (eg, AMR-WB) > reduce its load on receipt of ECN-CE instead of relying on a more > elaborate congestion control algorithm. I’m cc’ing Ingemar for a > sanity check (on what I wrote, versus my current state of mind :-) > > [IJ] Yes, I am partly guilty to this. I guess it is good enough for > bitrates below ~30kbps. But I am quite confident today that it won’t > work well at video bitrates or higher audio bitrates, that is why I > try to pitch the SCReAM algorithm. > [BB] So, are you confirming definitely that the intent was for on-off marking at the eNodeB (even tho it doesn't go as far as saying that, it sounds as if that was in the mind of the writer)? Have you seen the problem John K has pointed out (in our slides) where the marking might either come from an AQM in a non-3GPP network or on-off marking in the 3GPP network. So all codecs have to interpret both a low level of random marking (as in AQM) and toggling between a constant 100% level of marking and 0%, even tho they both occur under the same conditions and they don't know where the marking is coming from. Now that we have pointed this discrepancy out, do you think it's best that 3GPP adds some text to these specs to refer to (say) the recent IETF AQM Recommendations for the marking behaviour [RFC7567]. Does that create an incremental deployment problem in 3GPP? Cheers Bob > > cheers, > > -ken > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------040702060103040106070908 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Ingemar,

Cc'ing the list as agreed...

On 08/04/16 08:29, Ingemar Johansson S wrote:

Hi

 

A few comments inline below

Will listen in on the TSVWG session ASAP.

 

/Ingemar

 

From: ken carlberg [mailto:carlberg@g11.org.uk]
Sent: den 7 april 2016 21:06
To: Bob Briscoe
Cc: Ingemar Johansson S
Subject: 3GPP references to ECN

 

Bob

 

I very much liked your 3GPP references slide in the TSVWG presentation.  The one thing, though, that reminded me of a concern I had with 3GPP’s support for ECN centers in an obscure sentence in TS.29.162, end of Section 10.2.13.2 Incoming SDP offer with ECN, which states:

 

          "The TrGW should not send RTCP XR ECN summary reports.”

 

This departs from RFC-6679, and I think the motivation stems from a concern by IMS vendors that the rate of feedback would be excessive.  I agree that the RFC will clearly add more control traffic, but I’m not in agreement that it is excessive.  

[IJ] I don’t have the full understanding of what happens in 3GPP, I recall that there was a lot of discussion of the amount of overhead that RTCP gives. But I never had any real influence in this area.

[BB] I can add Ken's point to the liaison, but if the 3GPP worded it the way it did in full knowledge of what was in the IETF RFC, and you tried to influence it at the time, but failed, that's a different problem from misunderstanding or lack of clarity between SDOs. We'll see what others think.

 

 

I bring this up in your references slide, you state that the L4-7 is “fully compatible with EC-in-RTP”, which it is not.  

 

Also, my understanding is that the objective of some vendors/carriers was to rely on a step-like function in having the codec (eg, AMR-WB) reduce its load on receipt of ECN-CE instead of relying on a more elaborate congestion control algorithm.  I’m cc’ing Ingemar for a sanity check (on what I wrote, versus my current state of mind :-)

[IJ] Yes, I am partly guilty to this. I guess it is good enough for bitrates below ~30kbps. But I am quite confident today that it won’t work well at video bitrates or higher audio bitrates, that is why I try to pitch the SCReAM algorithm.

[BB] So, are you confirming definitely that the intent was for on-off marking at the eNodeB (even tho it doesn't go as far as saying that, it sounds as if that was in the mind of the writer)?

Have you seen the problem John K has pointed out (in our slides) where the marking might either come from an AQM in a non-3GPP network or on-off marking in the 3GPP network. So all codecs have to interpret both a low level of random marking (as in AQM) and toggling between a constant 100% level of marking and 0%, even tho they both occur under the same conditions and they don't know where the marking is coming from.

Now that we have pointed this discrepancy out, do you think it's best that 3GPP adds some text to these specs to refer to (say) the recent IETF AQM Recommendations for the marking behaviour [RFC7567]. Does that create an incremental deployment problem in 3GPP?

Cheers



Bob

 

cheers,

 

-ken

 


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------040702060103040106070908-- From nobody Fri Apr 8 09:32:29 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B229112D57E; Fri, 8 Apr 2016 09:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 BHSwtb2IME0f; Fri, 8 Apr 2016 09:32: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 6A5B312D09A; Fri, 8 Apr 2016 09:32:22 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 64C3FC9BB8505; Fri, 8 Apr 2016 16:32:17 +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 u38GWKKC005124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2016 16:32:20 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 u38GWJX8026320 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Apr 2016 18:32:20 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.230]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 8 Apr 2016 18:32:20 +0200 From: "De Schepper, Koen (Nokia - BE)" To: EXT Bob Briscoe , Ingemar Johansson S , "carlberg@g11.org.uk" , tsvwg IETF list Thread-Topic: [tsvwg] 3GPP references to ECN Thread-Index: AQHRkZlXc7cNpfmAP0Sg2JDG75BydJ+AQeaw Date: Fri, 8 Apr 2016 16:32:19 +0000 Message-ID: References: <81564C0D7D4D2A4B9A86C8C7404A13DA43DC2347@ESESSMB205.ericsson.se> <5707AFE0.5080200@bobbriscoe.net> In-Reply-To: <5707AFE0.5080200@bobbriscoe.net> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_BF6B00CC65FD2D45A326E74492B2C19FB764EC19FR711WXCHMBA05z_" MIME-Version: 1.0 Archived-At: Cc: "tcpprague@ietf.org" Subject: Re: [tsvwg] 3GPP references to ECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 16:32:25 -0000 --_000_BF6B00CC65FD2D45A326E74492B2C19FB764EC19FR711WXCHMBA05z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgIGFsbCwNCg0KSSBqdXN0IHByb3Bvc2VkIG5vdGljZWQgeW91ciBkaXNjdXNzaW9uIGhlcmUs IHdoaWNoIGNvdWxkIGJlIG9mIGludGVyZXN0IG9uIHRyeWluZyBEQ1RDUCBvbiBtb2JpbGUgbmV0 d29ya3M6DQoNCj4gQWxzbywgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZSBvYmplY3RpdmUg b2Ygc29tZSB2ZW5kb3JzL2NhcnJpZXJzIHdhcyB0byByZWx5IG9uIGEgc3RlcC1saWtlIGZ1bmN0 aW9uIGluIGhhdmluZyB0aGUgY29kZWMgKGVnLCBBTVItV0IpIHJlZHVjZSBpdHMgbG9hZCBvbiBy ZWNlaXB0IG9mIEVDTi1DRSBpbnN0ZWFkIG9mIHJlbHlpbmcgb24gYSBtb3JlIGVsYWJvcmF0ZSBj b25nZXN0aW9uIGNvbnRyb2wgYWxnb3JpdGhtLiAgSeKAmW0gY2PigJlpbmcgSW5nZW1hciBmb3Ig YSBzYW5pdHkgY2hlY2sgKG9uIHdoYXQgSSB3cm90ZSwgdmVyc3VzIG15IGN1cnJlbnQgc3RhdGUg b2YgbWluZCA6LSkNCltJSl0gWWVzLCBJIGFtIHBhcnRseSBndWlsdHkgdG8gdGhpcy4gSSBndWVz cyBpdCBpcyBnb29kIGVub3VnaCBmb3IgYml0cmF0ZXMgYmVsb3cgfjMwa2Jwcy4gQnV0IEkgYW0g cXVpdGUgY29uZmlkZW50IHRvZGF5IHRoYXQgaXQgd29u4oCZdCB3b3JrIHdlbGwgYXQgdmlkZW8g Yml0cmF0ZXMgb3IgaGlnaGVyIGF1ZGlvIGJpdHJhdGVzLCB0aGF0IGlzIHdoeSBJIHRyeSB0byBw aXRjaCB0aGUgU0NSZUFNIGFsZ29yaXRobS4NCltCQl0gU28sIGFyZSB5b3UgY29uZmlybWluZyBk ZWZpbml0ZWx5IHRoYXQgdGhlIGludGVudCB3YXMgZm9yIG9uLW9mZiBtYXJraW5nIGF0IHRoZSBl Tm9kZUIgKGV2ZW4gdGhvIGl0IGRvZXNuJ3QgZ28gYXMgZmFyIGFzIHNheWluZyB0aGF0LCBpdCBz b3VuZHMgYXMgaWYgdGhhdCB3YXMgaW4gdGhlIG1pbmQgb2YgdGhlIHdyaXRlcik/DQoNCklzIHRo aXMgc3RlcCBmdW5jdGlvbiB0aGUgcmlnaHQgb25lIHRvIHJ1biBhIERDVENQIGxpa2UgY29uZ2Vz dGlvbiBjb250cm9sIG9uIGl0PyBJcyBpdCBhIHN0ZXAgdGhhdCBpcyBub3Qgc21vb3RoZWQgYW5k IHNoYWxsb3cgZW5vdWdoPyBJcyB0aGVyZSBlcXVpcG1lbnQgdGhhdCBpbXBsZW1lbnRzIHRoaXMg c3RlcCwgYW5kIGNhbiB3ZSBkbyBzb21lIHRlc3RzIHVzaW5nIERDVENQIG9uIHRoaXM/DQoNClJl Z2FyZHMsDQpLb2VuLg0KDQoNCkZyb206IHRzdndnIFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEVYVCBCb2IgQnJpc2NvZQ0KU2VudDogdnJpamRhZyA4IGFwcmls IDIwMTYgMTU6MTkNClRvOiBJbmdlbWFyIEpvaGFuc3NvbiBTOyBjYXJsYmVyZ0BnMTEub3JnLnVr OyB0c3Z3ZyBJRVRGIGxpc3QNClN1YmplY3Q6IFJlOiBbdHN2d2ddIDNHUFAgcmVmZXJlbmNlcyB0 byBFQ04NCg0KSW5nZW1hciwNCg0KQ2MnaW5nIHRoZSBsaXN0IGFzIGFncmVlZC4uLg0KT24gMDgv MDQvMTYgMDg6MjksIEluZ2VtYXIgSm9oYW5zc29uIFMgd3JvdGU6DQpIaQ0KDQpBIGZldyBjb21t ZW50cyBpbmxpbmUgYmVsb3cNCldpbGwgbGlzdGVuIGluIG9uIHRoZSBUU1ZXRyBzZXNzaW9uIEFT QVAuDQoNCi9JbmdlbWFyDQoNCkZyb206IGtlbiBjYXJsYmVyZyBbbWFpbHRvOmNhcmxiZXJnQGcx MS5vcmcudWtdDQpTZW50OiBkZW4gNyBhcHJpbCAyMDE2IDIxOjA2DQpUbzogQm9iIEJyaXNjb2UN CkNjOiBJbmdlbWFyIEpvaGFuc3NvbiBTDQpTdWJqZWN0OiAzR1BQIHJlZmVyZW5jZXMgdG8gRUNO DQoNCkJvYg0KDQpJIHZlcnkgbXVjaCBsaWtlZCB5b3VyIDNHUFAgcmVmZXJlbmNlcyBzbGlkZSBp biB0aGUgVFNWV0cgcHJlc2VudGF0aW9uLiAgVGhlIG9uZSB0aGluZywgdGhvdWdoLCB0aGF0IHJl bWluZGVkIG1lIG9mIGEgY29uY2VybiBJIGhhZCB3aXRoIDNHUFDigJlzIHN1cHBvcnQgZm9yIEVD TiBjZW50ZXJzIGluIGFuIG9ic2N1cmUgc2VudGVuY2UgaW4gVFMuMjkuMTYyLCBlbmQgb2YgU2Vj dGlvbiAxMC4yLjEzLjIgSW5jb21pbmcgU0RQIG9mZmVyIHdpdGggRUNOLCB3aGljaCBzdGF0ZXM6 DQoNCiAgICAgICAgICAiVGhlIFRyR1cgc2hvdWxkIG5vdCBzZW5kIFJUQ1AgWFIgRUNOIHN1bW1h cnkgcmVwb3J0cy7igJ0NCg0KVGhpcyBkZXBhcnRzIGZyb20gUkZDLTY2NzksIGFuZCBJIHRoaW5r IHRoZSBtb3RpdmF0aW9uIHN0ZW1zIGZyb20gYSBjb25jZXJuIGJ5IElNUyB2ZW5kb3JzIHRoYXQg dGhlIHJhdGUgb2YgZmVlZGJhY2sgd291bGQgYmUgZXhjZXNzaXZlLiAgSSBhZ3JlZSB0aGF0IHRo ZSBSRkMgd2lsbCBjbGVhcmx5IGFkZCBtb3JlIGNvbnRyb2wgdHJhZmZpYywgYnV0IEnigJltIG5v dCBpbiBhZ3JlZW1lbnQgdGhhdCBpdCBpcyBleGNlc3NpdmUuDQpbSUpdIEkgZG9u4oCZdCBoYXZl IHRoZSBmdWxsIHVuZGVyc3RhbmRpbmcgb2Ygd2hhdCBoYXBwZW5zIGluIDNHUFAsIEkgcmVjYWxs IHRoYXQgdGhlcmUgd2FzIGEgbG90IG9mIGRpc2N1c3Npb24gb2YgdGhlIGFtb3VudCBvZiBvdmVy aGVhZCB0aGF0IFJUQ1AgZ2l2ZXMuIEJ1dCBJIG5ldmVyIGhhZCBhbnkgcmVhbCBpbmZsdWVuY2Ug aW4gdGhpcyBhcmVhLg0KW0JCXSBJIGNhbiBhZGQgS2VuJ3MgcG9pbnQgdG8gdGhlIGxpYWlzb24s IGJ1dCBpZiB0aGUgM0dQUCB3b3JkZWQgaXQgdGhlIHdheSBpdCBkaWQgaW4gZnVsbCBrbm93bGVk Z2Ugb2Ygd2hhdCB3YXMgaW4gdGhlIElFVEYgUkZDLCBhbmQgeW91IHRyaWVkIHRvIGluZmx1ZW5j ZSBpdCBhdCB0aGUgdGltZSwgYnV0IGZhaWxlZCwgdGhhdCdzIGEgZGlmZmVyZW50IHByb2JsZW0g ZnJvbSBtaXN1bmRlcnN0YW5kaW5nIG9yIGxhY2sgb2YgY2xhcml0eSBiZXR3ZWVuIFNET3MuIFdl J2xsIHNlZSB3aGF0IG90aGVycyB0aGluay4NCg0KDQoNCg0KSSBicmluZyB0aGlzIHVwIGluIHlv dXIgcmVmZXJlbmNlcyBzbGlkZSwgeW91IHN0YXRlIHRoYXQgdGhlIEw0LTcgaXMg4oCcZnVsbHkg Y29tcGF0aWJsZSB3aXRoIEVDLWluLVJUUOKAnSwgd2hpY2ggaXQgaXMgbm90Lg0KDQpBbHNvLCBt eSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlIG9iamVjdGl2ZSBvZiBzb21lIHZlbmRvcnMvY2Fy cmllcnMgd2FzIHRvIHJlbHkgb24gYSBzdGVwLWxpa2UgZnVuY3Rpb24gaW4gaGF2aW5nIHRoZSBj b2RlYyAoZWcsIEFNUi1XQikgcmVkdWNlIGl0cyBsb2FkIG9uIHJlY2VpcHQgb2YgRUNOLUNFIGlu c3RlYWQgb2YgcmVseWluZyBvbiBhIG1vcmUgZWxhYm9yYXRlIGNvbmdlc3Rpb24gY29udHJvbCBh bGdvcml0aG0uICBJ4oCZbSBjY+KAmWluZyBJbmdlbWFyIGZvciBhIHNhbml0eSBjaGVjayAob24g d2hhdCBJIHdyb3RlLCB2ZXJzdXMgbXkgY3VycmVudCBzdGF0ZSBvZiBtaW5kIDotKQ0KW0lKXSBZ ZXMsIEkgYW0gcGFydGx5IGd1aWx0eSB0byB0aGlzLiBJIGd1ZXNzIGl0IGlzIGdvb2QgZW5vdWdo IGZvciBiaXRyYXRlcyBiZWxvdyB+MzBrYnBzLiBCdXQgSSBhbSBxdWl0ZSBjb25maWRlbnQgdG9k YXkgdGhhdCBpdCB3b27igJl0IHdvcmsgd2VsbCBhdCB2aWRlbyBiaXRyYXRlcyBvciBoaWdoZXIg YXVkaW8gYml0cmF0ZXMsIHRoYXQgaXMgd2h5IEkgdHJ5IHRvIHBpdGNoIHRoZSBTQ1JlQU0gYWxn b3JpdGhtLg0KW0JCXSBTbywgYXJlIHlvdSBjb25maXJtaW5nIGRlZmluaXRlbHkgdGhhdCB0aGUg aW50ZW50IHdhcyBmb3Igb24tb2ZmIG1hcmtpbmcgYXQgdGhlIGVOb2RlQiAoZXZlbiB0aG8gaXQg ZG9lc24ndCBnbyBhcyBmYXIgYXMgc2F5aW5nIHRoYXQsIGl0IHNvdW5kcyBhcyBpZiB0aGF0IHdh cyBpbiB0aGUgbWluZCBvZiB0aGUgd3JpdGVyKT8NCg0KSGF2ZSB5b3Ugc2VlbiB0aGUgcHJvYmxl bSBKb2huIEsgaGFzIHBvaW50ZWQgb3V0IChpbiBvdXIgc2xpZGVzKSB3aGVyZSB0aGUgbWFya2lu ZyBtaWdodCBlaXRoZXIgY29tZSBmcm9tIGFuIEFRTSBpbiBhIG5vbi0zR1BQIG5ldHdvcmsgb3Ig b24tb2ZmIG1hcmtpbmcgaW4gdGhlIDNHUFAgbmV0d29yay4gU28gYWxsIGNvZGVjcyBoYXZlIHRv IGludGVycHJldCBib3RoIGEgbG93IGxldmVsIG9mIHJhbmRvbSBtYXJraW5nIChhcyBpbiBBUU0p IGFuZCB0b2dnbGluZyBiZXR3ZWVuIGEgY29uc3RhbnQgMTAwJSBsZXZlbCBvZiBtYXJraW5nIGFu ZCAwJSwgZXZlbiB0aG8gdGhleSBib3RoIG9jY3VyIHVuZGVyIHRoZSBzYW1lIGNvbmRpdGlvbnMg YW5kIHRoZXkgZG9uJ3Qga25vdyB3aGVyZSB0aGUgbWFya2luZyBpcyBjb21pbmcgZnJvbS4NCg0K Tm93IHRoYXQgd2UgaGF2ZSBwb2ludGVkIHRoaXMgZGlzY3JlcGFuY3kgb3V0LCBkbyB5b3UgdGhp bmsgaXQncyBiZXN0IHRoYXQgM0dQUCBhZGRzIHNvbWUgdGV4dCB0byB0aGVzZSBzcGVjcyB0byBy ZWZlciB0byAoc2F5KSB0aGUgcmVjZW50IElFVEYgQVFNIFJlY29tbWVuZGF0aW9ucyBmb3IgdGhl IG1hcmtpbmcgYmVoYXZpb3VyIFtSRkM3NTY3XS4gRG9lcyB0aGF0IGNyZWF0ZSBhbiBpbmNyZW1l bnRhbCBkZXBsb3ltZW50IHByb2JsZW0gaW4gM0dQUD8NCg0KQ2hlZXJzDQoNCg0KDQpCb2INCg0K Y2hlZXJzLA0KDQota2VuDQoNCg0KDQoNCi0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQm9iIEJyaXNjb2UgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNjb2UubmV0Lw0K --_000_BF6B00CC65FD2D45A326E74492B2C19FB764EC19FR711WXCHMBA05z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0 ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJh Z3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCglt YXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0K CW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9y OmJsYWNrO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFi LXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNw YW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30N CnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIg bGFuZz0iTkwtQkUiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkmbmJzcDsgYWxsLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGp1c3QgcHJvcG9zZWQgbm90aWNlZCB5b3VyIGRp c2N1c3Npb24gaGVyZSwgd2hpY2ggY291bGQgYmUgb2YgaW50ZXJlc3Qgb24gdHJ5aW5nIERDVENQ IG9uIG1vYmlsZSBuZXR3b3Jrczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IEFsc28sIG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0 aGUgb2JqZWN0aXZlIG9mIHNvbWUgdmVuZG9ycy9jYXJyaWVycyB3YXMgdG8gcmVseSBvbiBhIHN0 ZXAtbGlrZSBmdW5jdGlvbiBpbiBoYXZpbmcgdGhlIGNvZGVjIChlZywgQU1SLVdCKSByZWR1Y2Ug aXRzIGxvYWQgb24gcmVjZWlwdCBvZiBFQ04tQ0UgaW5zdGVhZCBvZiByZWx5aW5nIG9uIGEgbW9y ZSBlbGFib3JhdGUNCiBjb25nZXN0aW9uIGNvbnRyb2wgYWxnb3JpdGhtLiAmbmJzcDtJ4oCZbSBj Y+KAmWluZyBJbmdlbWFyIGZvciBhIHNhbml0eSBjaGVjayAob24gd2hhdCBJIHdyb3RlLCB2ZXJz dXMgbXkgY3VycmVudCBzdGF0ZSBvZiBtaW5kIDotKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6I0MwNTA0RCI+W0lKXSBZZXMsIEkgYW0gcGFydGx5IGd1aWx0eSB0byB0aGlzLiBJ IGd1ZXNzIGl0IGlzIGdvb2QgZW5vdWdoIGZvciBiaXRyYXRlcyBiZWxvdyB+MzBrYnBzLiBCdXQg SSBhbSBxdWl0ZSBjb25maWRlbnQgdG9kYXkgdGhhdCBpdCB3b27igJl0IHdvcmsgd2VsbA0KIGF0 IHZpZGVvIGJpdHJhdGVzIG9yIGhpZ2hlciBhdWRpbyBiaXRyYXRlcywgdGhhdCBpcyB3aHkgSSB0 cnkgdG8gcGl0Y2ggdGhlIFNDUmVBTSBhbGdvcml0aG0uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+W0JCXSBTbywgYXJlIHlvdSBjb25maXJtaW5nIGRlZmluaXRlbHkgdGhhdCB0aGUg aW50ZW50IHdhcyBmb3Igb24tb2ZmIG1hcmtpbmcgYXQgdGhlIGVOb2RlQiAoZXZlbiB0aG8gaXQg ZG9lc24ndCBnbyBhcyBmYXIgYXMgc2F5aW5nIHRoYXQsIGl0IHNvdW5kcyBhcyBpZiB0aGF0IHdh cyBpbiB0aGUgbWluZCBvZiB0aGUgd3JpdGVyKT88YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklzIHRoaXMgc3RlcCBmdW5jdGlvbiB0 aGUgcmlnaHQgb25lIHRvIHJ1biBhIERDVENQIGxpa2UgY29uZ2VzdGlvbiBjb250cm9sIG9uIGl0 PyBJcyBpdCBhIHN0ZXAgdGhhdCBpcyBub3Qgc21vb3RoZWQgYW5kIHNoYWxsb3cgZW5vdWdoPyBJ cyB0aGVyZQ0KIGVxdWlwbWVudCB0aGF0IGltcGxlbWVudHMgdGhpcyBzdGVwLCBhbmQgY2FuIHdl IGRvIHNvbWUgdGVzdHMgdXNpbmcgRENUQ1Agb24gdGhpcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPktvZW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 d2luZG93dGV4dCI+IHRzdndnIFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9u IEJlaGFsZiBPZiA8L2I+RVhUIEJvYiBCcmlzY29lPGJyPg0KPGI+U2VudDo8L2I+IHZyaWpkYWcg OCBhcHJpbCAyMDE2IDE1OjE5PGJyPg0KPGI+VG86PC9iPiBJbmdlbWFyIEpvaGFuc3NvbiBTOyBj YXJsYmVyZ0BnMTEub3JnLnVrOyB0c3Z3ZyBJRVRGIGxpc3Q8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFt0c3Z3Z10gM0dQUCByZWZlcmVuY2VzIHRvIEVDTjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JbmdlbWFyLDxicj4NCjxicj4NCkNjJ2luZyB0aGUgbGlz dCBhcyBhZ3JlZWQuLi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiAwOC8wNC8xNiAwODoyOSwgSW5nZW1hciBKb2hhbnNzb24gUyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkEgZmV3IGNvbW1lbnRzIGlubGlu ZQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj5iZWxv dzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaWxsIGxpc3RlbiBpbiBvbiB0aGUgVFNW V0cgc2Vzc2lvbiBBU0FQLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+L0luZ2VtYXI8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4ga2VuIGNhcmxiZXJnIFs8YSBocmVmPSJtYWlsdG86Y2Fy bGJlcmdAZzExLm9yZy51ayI+bWFpbHRvOmNhcmxiZXJnQGcxMS5vcmcudWs8L2E+XQ0KPGJyPg0K PGI+U2VudDo8L2I+IGRlbiA3IGFwcmlsIDIwMTYgMjE6MDY8YnI+DQo8Yj5Ubzo8L2I+IEJvYiBC cmlzY29lPGJyPg0KPGI+Q2M6PC9iPiBJbmdlbWFyIEpvaGFuc3NvbiBTPGJyPg0KPGI+U3ViamVj dDo8L2I+IDNHUFAgcmVmZXJlbmNlcyB0byBFQ048L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Cb2I8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgdmVyeSBtdWNoIGxpa2VkIHlvdXIgM0dQUCByZWZlcmVuY2VzIHNsaWRl IGluIHRoZSBUU1ZXRyBwcmVzZW50YXRpb24uICZuYnNwO1RoZSBvbmUgdGhpbmcsIHRob3VnaCwg dGhhdCByZW1pbmRlZCBtZSBvZiBhIGNvbmNlcm4gSSBoYWQgd2l0aCAzR1BQ4oCZcyBzdXBwb3J0 IGZvciBFQ04gY2VudGVycyBpbiBhbiBvYnNjdXJlIHNlbnRlbmNlIGluIFRTLjI5LjE2MiwgZW5k IG9mIFNlY3Rpb24mbmJzcDs8YSBuYW1lPSJfVG9jNDQ1ODIyMjczIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImNvbG9yOiMxOTNBRkYiPjEwLjIuPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImNvbG9yOiMxOTNBRkYiPjEzLjINCiBJbmNvbWluZyBTRFAgb2ZmZXIgd2l0aCBF Q048L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPiwgd2hpY2ggc3RhdGVzOjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xh c3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPiZxdW90O1RoZSBUckdXPGI+IDx1Pg0Kc2hvdWxkPC91 PiA8L2I+bm90IHNlbmQgUlRDUCBYUiBFQ04gc3VtbWFyeSByZXBvcnRzLuKAnTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGRlcGFydHMg ZnJvbSBSRkMtNjY3OSwgYW5kIEkgdGhpbmsgdGhlIG1vdGl2YXRpb24gc3RlbXMgZnJvbSBhIGNv bmNlcm4gYnkgSU1TIHZlbmRvcnMgdGhhdCB0aGUgcmF0ZSBvZiBmZWVkYmFjayB3b3VsZCBiZSBl eGNlc3NpdmUuJm5ic3A7IEkgYWdyZWUgdGhhdCB0aGUgUkZDIHdpbGwgY2xlYXJseSBhZGQgbW9y ZSBjb250cm9sIHRyYWZmaWMsIGJ1dCBJ4oCZbSBub3QgaW4gYWdyZWVtZW50IHRoYXQgaXQgaXMg ZXhjZXNzaXZlLg0KICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPltJSl0gSSBkb27igJl0 IGhhdmUgdGhlIGZ1bGwgdW5kZXJzdGFuZGluZyBvZiB3aGF0IGhhcHBlbnMgaW4gM0dQUCwgSSBy ZWNhbGwgdGhhdCB0aGVyZSB3YXMgYSBsb3Qgb2YgZGlzY3Vzc2lvbiBvZiB0aGUgYW1vdW50IG9m IG92ZXJoZWFkIHRoYXQgUlRDUCBnaXZlcy4gQnV0DQogSSBuZXZlciBoYWQgYW55IHJlYWwgaW5m bHVlbmNlIGluIHRoaXMgYXJlYS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W0JCXSBJIGNhbiBhZGQgS2Vu J3MgcG9pbnQgdG8gdGhlIGxpYWlzb24sIGJ1dCBpZiB0aGUgM0dQUCB3b3JkZWQgaXQgdGhlIHdh eSBpdCBkaWQgaW4gZnVsbCBrbm93bGVkZ2Ugb2Ygd2hhdCB3YXMgaW4gdGhlIElFVEYgUkZDLCBh bmQgeW91IHRyaWVkIHRvIGluZmx1ZW5jZSBpdCBhdCB0aGUgdGltZSwgYnV0IGZhaWxlZCwgdGhh dCdzIGEgZGlmZmVyZW50IHByb2JsZW0gZnJvbSBtaXN1bmRlcnN0YW5kaW5nIG9yDQogbGFjayBv ZiBjbGFyaXR5IGJldHdlZW4gU0RPcy4gV2UnbGwgc2VlIHdoYXQgb3RoZXJzIHRoaW5rLjxicj4N Cjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGJyaW5nIHRoaXMgdXAgaW4geW91ciByZWZlcmVuY2Vz IHNsaWRlLCB5b3Ugc3RhdGUgdGhhdCB0aGUgTDQtNyBpcyDigJxmdWxseSBjb21wYXRpYmxlIHdp dGggRUMtaW4tUlRQ4oCdLCB3aGljaCBpdCBpcyBub3QuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvLCBteSB1bmRlcnN0YW5k aW5nIGlzIHRoYXQgdGhlIG9iamVjdGl2ZSBvZiBzb21lIHZlbmRvcnMvY2FycmllcnMgd2FzIHRv IHJlbHkgb24gYSBzdGVwLWxpa2UgZnVuY3Rpb24gaW4gaGF2aW5nIHRoZSBjb2RlYyAoZWcsIEFN Ui1XQikgcmVkdWNlIGl0cyBsb2FkIG9uIHJlY2VpcHQgb2YgRUNOLUNFIGluc3RlYWQgb2YgcmVs eWluZyBvbiBhIG1vcmUgZWxhYm9yYXRlIGNvbmdlc3Rpb24gY29udHJvbCBhbGdvcml0aG0uDQog Jm5ic3A7SeKAmW0gY2PigJlpbmcgSW5nZW1hciBmb3IgYSBzYW5pdHkgY2hlY2sgKG9uIHdoYXQg SSB3cm90ZSwgdmVyc3VzIG15IGN1cnJlbnQgc3RhdGUgb2YgbWluZCA6LSk8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojQzA1MDREIj5bSUpdIFllcywgSSBhbSBwYXJ0bHkgZ3VpbHR5IHRvIHRoaXMuIEkgZ3Vlc3Mg aXQgaXMgZ29vZCBlbm91Z2ggZm9yIGJpdHJhdGVzIGJlbG93IH4zMGticHMuIEJ1dCBJIGFtIHF1 aXRlIGNvbmZpZGVudCB0b2RheSB0aGF0IGl0IHdvbuKAmXQgd29yayB3ZWxsIGF0IHZpZGVvDQog Yml0cmF0ZXMgb3IgaGlnaGVyIGF1ZGlvIGJpdHJhdGVzLCB0aGF0IGlzIHdoeSBJIHRyeSB0byBw aXRjaCB0aGUgU0NSZUFNIGFsZ29yaXRobS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W0JCXSBTbywgYXJlIHlvdSBjb25maXJtaW5n IGRlZmluaXRlbHkgdGhhdCB0aGUgaW50ZW50IHdhcyBmb3Igb24tb2ZmIG1hcmtpbmcgYXQgdGhl IGVOb2RlQiAoZXZlbiB0aG8gaXQgZG9lc24ndCBnbyBhcyBmYXIgYXMgc2F5aW5nIHRoYXQsIGl0 IHNvdW5kcyBhcyBpZiB0aGF0IHdhcyBpbiB0aGUgbWluZCBvZiB0aGUgd3JpdGVyKT88YnI+DQo8 YnI+DQpIYXZlIHlvdSBzZWVuIHRoZSBwcm9ibGVtIEpvaG4gSyBoYXMgcG9pbnRlZCBvdXQgKGlu IG91ciBzbGlkZXMpIHdoZXJlIHRoZSBtYXJraW5nIG1pZ2h0IGVpdGhlciBjb21lIGZyb20gYW4g QVFNIGluIGEgbm9uLTNHUFAgbmV0d29yayBvciBvbi1vZmYgbWFya2luZyBpbiB0aGUgM0dQUCBu ZXR3b3JrLiBTbyBhbGwgY29kZWNzIGhhdmUgdG8gaW50ZXJwcmV0IGJvdGggYSBsb3cgbGV2ZWwg b2YgcmFuZG9tIG1hcmtpbmcgKGFzIGluIEFRTSkgYW5kDQogdG9nZ2xpbmcgYmV0d2VlbiBhIGNv bnN0YW50IDEwMCUgbGV2ZWwgb2YgbWFya2luZyBhbmQgMCUsIGV2ZW4gdGhvIHRoZXkgYm90aCBv Y2N1ciB1bmRlciB0aGUgc2FtZSBjb25kaXRpb25zIGFuZCB0aGV5IGRvbid0IGtub3cgd2hlcmUg dGhlIG1hcmtpbmcgaXMgY29taW5nIGZyb20uDQo8YnI+DQo8YnI+DQpOb3cgdGhhdCB3ZSBoYXZl IHBvaW50ZWQgdGhpcyBkaXNjcmVwYW5jeSBvdXQsIGRvIHlvdSB0aGluayBpdCdzIGJlc3QgdGhh dCAzR1BQIGFkZHMgc29tZSB0ZXh0IHRvIHRoZXNlIHNwZWNzIHRvIHJlZmVyIHRvIChzYXkpIHRo ZSByZWNlbnQgSUVURiBBUU0gUmVjb21tZW5kYXRpb25zIGZvciB0aGUgbWFya2luZyBiZWhhdmlv dXIgW1JGQzc1NjddLiBEb2VzIHRoYXQgY3JlYXRlIGFuIGluY3JlbWVudGFsIGRlcGxveW1lbnQg cHJvYmxlbSBpbiAzR1BQPzxicj4NCjxicj4NCkNoZWVyczxicj4NCjxicj4NCjxicj4NCjxicj4N CkJvYiA8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5jaGVlcnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1rZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PHByZT4tLSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4N CjxwcmU+Qm9iIEJyaXNjb2UmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL2JvYmJyaXNjb2UubmV0 LyI+aHR0cDovL2JvYmJyaXNjb2UubmV0LzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BF6B00CC65FD2D45A326E74492B2C19FB764EC19FR711WXCHMBA05z_-- From nobody Fri Apr 8 10:16:46 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26BC12D8DC; Fri, 8 Apr 2016 10:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 xbGuwo6LdnUt; Fri, 8 Apr 2016 10:16:38 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E98812D0B9; Fri, 8 Apr 2016 10:16:36 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-1b-5707e7729cc1 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 92.83.22880.277E7075; Fri, 8 Apr 2016 19:16:34 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.173]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0248.002; Fri, 8 Apr 2016 19:16:26 +0200 From: Ingemar Johansson S To: "koen.de_schepper@nokia.com" , "ietf@bobbriscoe.net" , "carlberg@g11.org.uk" , "tsvwg@ietf.org" Thread-Topic: [tcpPrague] [tsvwg] 3GPP references to ECN Thread-Index: AQHRkbRA4dAkbUNhaUWyswQuveTtcp+ATnBQ Date: Fri, 8 Apr 2016 17:16:25 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA43DC2EC1@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA43DC2347@ESESSMB205.ericsson.se> <5707AFE0.5080200@bobbriscoe.net> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_053D_01D191CB.2455DAD0" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUyM2K7sW7Rc/Zwg45FOhbPZ2VbHH24gNXi /tk3rBZTGw6yWBx7c5fNgdXj1f0LrB6T3y1h8liy5CeTx91bl5gCWKK4bFJSczLLUov07RK4 Mn6072EqmPyfsWL1jsvMDYwdTxi7GDk5JARMJLZ+28QMYYtJXLi3nq2LkYtDSOAIo0TbglPs EM5iRonXzavYQKrYBGwkVh76zgiSEBHYxyix9v9ZFpAEs0C6xL9Dv8BGCQuYS6z80MAEYosI WEh8utzACmEbSax9thGshkVAReLjyf1gNq+Ar8TX9VuYILb9YJRY9ucVO0iCUyBWYsaFd2DN jAKyEve/34NaJi5x68l8Joi7RSQeXjzNBmGLSrx8/I8VwlaSWHt4OwvIUGaBXkaJb53bmSC2 CUqcnPmEZQKj6Cwks2Yhq5uFpG4WIwdQIlrixWo2iHptiac3n7LA2MsWvmaGKNGSWDzLE1UY xLaWmPHrIFSrosSU7ofsELapxOujHxkXMHKvYhQtTi0uzk03MtZLLcpMLi7Oz9PLSy3ZxAhM BAe3/Nbdwbj6teMhRgEORiUe3gUC7OFCrIllxZW5hxhVgOY82rD6AqMUS15+XqqSCO+NZ0Bp 3pTEyqrUovz4otKc1OJDjNIcLErivDmR/8KEBNITS1KzU1MLUotgskwcnFINjMr63xYuP2es IrzEks31asGKwzvX+fV9dy2Z+Pl0WJ13UF9w054XVSZ5bOcZji0Jebz/GeMDyUXftm1jWrYk UKp7t/Gcdd53whn/sh4RfVjtabrKLeQFm7J1afjayKJbl0/UanZWPftyRWj7+aLrdV+Ezy80 6lqd8b14EXtCX+dNYXf5StnZc5VYijMSDbWYi4oTAZiyRkEMAwAA Archived-At: Cc: Ingemar Johansson S , "tcpprague@ietf.org" Subject: Re: [tsvwg] [tcpPrague] 3GPP references to ECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 17:16:45 -0000 ------=_NextPart_000_053D_01D191CB.2455DAD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_053E_01D191CB.2455DAD0" ------=_NextPart_001_053E_01D191CB.2455DAD0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi =20 My comments inline /Ingemar =20 From: De Schepper, Koen (Nokia - BE) [mailto:koen.de_schepper@nokia.com] = Sent: den 8 april 2016 18:32 To: EXT Bob Briscoe; Ingemar Johansson S; carlberg@g11.org.uk; tsvwg = IETF list Cc: tcpprague@ietf.org Subject: Re: [tcpPrague] [tsvwg] 3GPP references to ECN =20 Hi all, =20 I just proposed noticed your discussion here, which could be of interest = on trying DCTCP on mobile networks: =20 > Also, my understanding is that the objective of some vendors/carriers = was to rely on a step-like function in having the codec (eg, AMR-WB) = reduce its load on receipt of ECN-CE instead of relying on a more = elaborate congestion control algorithm. I=E2=80=99m cc=E2=80=99ing = Ingemar for a sanity check (on what I wrote, versus my current state of = mind :-) [IJ] Yes, I am partly guilty to this. I guess it is good enough for = bitrates below ~30kbps. But I am quite confident today that it = won=E2=80=99t work well at video bitrates or higher audio bitrates, that = is why I try to pitch the SCReAM algorithm. [BB] So, are you confirming definitely that the intent was for on-off = marking at the eNodeB (even tho it doesn't go as far as saying that, it = sounds as if that was in the mind of the writer)? [IJ] No I would not take it that far, parts of the text in 36.300 may = imply this (1st para in section 11.6), but this is actually only a = discussion text. The normative text is the 2nd para. My interpretation = is that ECN marking should be something according to RFC7567, problem is = however that ECN is not implemented.=20 Is this step function the right one to run a DCTCP like congestion = control on it? Is it a step that is not smoothed and shallow enough? Is = there equipment that implements this step, and can we do some tests = using DCTCP on this? [IJ] Currently I cannot answer the question, if ECN is implemented I = would believe that it would be more RFC3168-ish at least initially. =20 Regards, Koen. =20 =20 From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of EXT Bob Briscoe Sent: vrijdag 8 april 2016 15:19 To: Ingemar Johansson S; carlberg@g11.org.uk; tsvwg IETF list Subject: Re: [tsvwg] 3GPP references to ECN =20 Ingemar, Cc'ing the list as agreed... On 08/04/16 08:29, Ingemar Johansson S wrote: Hi =20 A few comments inline below Will listen in on the TSVWG session ASAP. =20 /Ingemar =20 From: ken carlberg [mailto:carlberg@g11.org.uk]=20 Sent: den 7 april 2016 21:06 To: Bob Briscoe Cc: Ingemar Johansson S Subject: 3GPP references to ECN =20 Bob =20 I very much liked your 3GPP references slide in the TSVWG presentation. = The one thing, though, that reminded me of a concern I had with = 3GPP=E2=80=99s support for ECN centers in an obscure sentence in = TS.29.162, end of Section 10.2.13.2 Incoming SDP offer with ECN, which = states: =20 "The TrGW should not send RTCP XR ECN summary = reports.=E2=80=9D =20 This departs from RFC-6679, and I think the motivation stems from a = concern by IMS vendors that the rate of feedback would be excessive. I = agree that the RFC will clearly add more control traffic, but = I=E2=80=99m not in agreement that it is excessive. =20 [IJ] I don=E2=80=99t have the full understanding of what happens in = 3GPP, I recall that there was a lot of discussion of the amount of = overhead that RTCP gives. But I never had any real influence in this = area. [BB] I can add Ken's point to the liaison, but if the 3GPP worded it the = way it did in full knowledge of what was in the IETF RFC, and you tried = to influence it at the time, but failed, that's a different problem from = misunderstanding or lack of clarity between SDOs. We'll see what others = think. =20 =20 I bring this up in your references slide, you state that the L4-7 is = =E2=80=9Cfully compatible with EC-in-RTP=E2=80=9D, which it is not. =20 =20 Also, my understanding is that the objective of some vendors/carriers = was to rely on a step-like function in having the codec (eg, AMR-WB) = reduce its load on receipt of ECN-CE instead of relying on a more = elaborate congestion control algorithm. I=E2=80=99m cc=E2=80=99ing = Ingemar for a sanity check (on what I wrote, versus my current state of = mind :-) [IJ] Yes, I am partly guilty to this. I guess it is good enough for = bitrates below ~30kbps. But I am quite confident today that it = won=E2=80=99t work well at video bitrates or higher audio bitrates, that = is why I try to pitch the SCReAM algorithm. [BB] So, are you confirming definitely that the intent was for on-off = marking at the eNodeB (even tho it doesn't go as far as saying that, it = sounds as if that was in the mind of the writer)? Have you seen the problem John K has pointed out (in our slides) where = the marking might either come from an AQM in a non-3GPP network or = on-off marking in the 3GPP network. So all codecs have to interpret both = a low level of random marking (as in AQM) and toggling between a = constant 100% level of marking and 0%, even tho they both occur under = the same conditions and they don't know where the marking is coming = from.=20 Now that we have pointed this discrepancy out, do you think it's best = that 3GPP adds some text to these specs to refer to (say) the recent = IETF AQM Recommendations for the marking behaviour [RFC7567]. Does that = create an incremental deployment problem in 3GPP? Cheers Bob=20 =20 cheers, =20 -ken =20 =20 --=20 ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ ------=_NextPart_001_053E_01D191CB.2455DAD0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi

 

My comments inline

/Ingemar

 

From: De Schepper, Koen (Nokia - BE) [mailto:koen.de_schepper@nokia.com] =
Sent: den 8 april 2016 18:32
To: EXT Bob Briscoe; = Ingemar Johansson S; carlberg@g11.org.uk; tsvwg IETF list
Cc: = tcpprague@ietf.org
Subject: Re: [tcpPrague] [tsvwg] 3GPP = references to ECN

 

Hi  all,

 

I just proposed noticed your discussion here, which could be of = interest on trying DCTCP on mobile networks:

 

> Also, my = understanding is that the objective of some vendors/carriers was to rely = on a step-like function in having the codec (eg, AMR-WB) reduce its load = on receipt of ECN-CE instead of relying on a more elaborate congestion = control algorithm.  I=E2=80=99m cc=E2=80=99ing Ingemar for a sanity = check (on what I wrote, versus my current state of mind = :-)

[IJ] Yes, I am partly guilty to this. I guess it is good enough for = bitrates below ~30kbps. But I am quite confident today that it = won=E2=80=99t work well at video bitrates or higher audio bitrates, that = is why I try to pitch the SCReAM algorithm.

[BB] So, are you = confirming definitely that the intent was for on-off marking at the = eNodeB (even tho it doesn't go as far as saying that, it sounds as if = that was in the mind of the writer)?

[IJ] No I would=C2=A0 not take it that far, parts of the text in = 36.300 may imply this (1st para in section 11.6), but this is = actually only a discussion text. The normative text is the = 2nd para. My interpretation is that ECN marking should be = something according to RFC7567, problem is however that ECN is not = implemented.

Is this step function the right one to run a DCTCP like congestion = control on it? Is it a step that is not smoothed and shallow enough? Is = there equipment that implements this step, and can we do some tests = using DCTCP on this?

[IJ] Currently I cannot answer the question, if ECN is implemented I = would believe that it would be more RFC3168-ish at least = initially.

 

Regards,

Koen.

 

 

From: tsvwg [mailto:tsvwg-bounces@ietf.org]= On Behalf Of EXT Bob Briscoe
Sent: vrijdag 8 april = 2016 15:19
To: Ingemar Johansson S; carlberg@g11.org.uk; tsvwg IETF = list
Subject: Re: [tsvwg] 3GPP references to = ECN

 

Ingemar,

Cc'ing = the list as agreed...

On 08/04/16 08:29, Ingemar = Johansson S wrote:

Hi

 

A few comments inline below

Will listen in on the TSVWG session ASAP.

 

/Ingemar

 

From:= ken = carlberg [mailto:carlberg@g11.org.uk] =
Sent: den 7 april 2016 21:06
To: Bob = Briscoe
Cc: Ingemar Johansson S
Subject: 3GPP = references to ECN

 

Bob

 

I very much liked your 3GPP = references slide in the TSVWG presentation.  The one thing, though, = that reminded me of a concern I had with 3GPP=E2=80=99s support for ECN = centers in an obscure sentence in TS.29.162, end of = Section 10.2.13.2 Incoming SDP offer with ECN, which states:

 

          = "The TrGW should not = send RTCP XR ECN summary = reports.=E2=80=9D

 

This departs from RFC-6679, and I = think the motivation stems from a concern by IMS vendors that the rate = of feedback would be excessive.  I agree that the RFC will clearly = add more control traffic, but I=E2=80=99m not in agreement that it is = excessive.  

[IJ] I don=E2=80=99t have the full understanding of what happens in = 3GPP, I recall that there was a lot of discussion of the amount of = overhead that RTCP gives. But I never had any real influence in this = area.

[BB] = I can add Ken's point to the liaison, but if the 3GPP worded it the way = it did in full knowledge of what was in the IETF RFC, and you tried to = influence it at the time, but failed, that's a different problem from = misunderstanding or lack of clarity between SDOs. We'll see what others = think.

 

 

I bring this up in your references = slide, you state that the L4-7 is =E2=80=9Cfully compatible with = EC-in-RTP=E2=80=9D, which it is not. =  

 

Also, my understanding is that the = objective of some vendors/carriers was to rely on a step-like function = in having the codec (eg, AMR-WB) reduce its load on receipt of ECN-CE = instead of relying on a more elaborate congestion control algorithm. =  I=E2=80=99m cc=E2=80=99ing Ingemar for a sanity check (on what I = wrote, versus my current state of mind :-)

[IJ] Yes, I am partly guilty to this. I guess it is good enough for = bitrates below ~30kbps. But I am quite confident today that it = won=E2=80=99t work well at video bitrates or higher audio bitrates, that = is why I try to pitch the SCReAM algorithm.

[BB] So, are you confirming = definitely that the intent was for on-off marking at the eNodeB (even = tho it doesn't go as far as saying that, it sounds as if that was in the = mind of the writer)?

Have you seen the problem John K has pointed = out (in our slides) where the marking might either come from an AQM in a = non-3GPP network or on-off marking in the 3GPP network. So all codecs = have to interpret both a low level of random marking (as in AQM) and = toggling between a constant 100% level of marking and 0%, even tho they = both occur under the same conditions and they don't know where the = marking is coming from.

Now that we have pointed this = discrepancy out, do you think it's best that 3GPP adds some text to = these specs to refer to (say) the recent IETF AQM Recommendations for = the marking behaviour [RFC7567]. Does that create an incremental = deployment problem in 3GPP?

Cheers



Bob =

 

cheers,

 

-ken

 

 

-- =

____________________________________________________________=
____
Bob =
Briscoe           =
            &=
nbsp;       http://bobbriscoe.net/
------=_NextPart_001_053E_01D191CB.2455DAD0-- ------=_NextPart_000_053D_01D191CB.2455DAD0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVYzCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGADCCA+igAwIBAgIQ eyeE6FBBHSc8YzDpWR1mVTANBgkqhkiG9w0BAQUFADA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMG A1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjAeFw0xNDEyMDIxNDI5MTdaFw0xNzEy MDIxNDI5MTZaMHQxETAPBgNVBAoMCEVyaWNzc29uMRwwGgYDVQQDDBNJbmdlbWFyIEpvaGFuc3Nv biBTMS8wLQYJKoZIhvcNAQkBFiBpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTEQMA4G A1UEBRMHRVBMSUpPSDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK6dOkJu7hl4aOKX k6YBf5PgWpDbO6iINxyYJetBuJZJqEdDqKukaHZmP8Rn5hhiQZDWa89koR41DNS7umMwZtHQkN+j m3b5Z1LUMQle7XDtUy3rn47hgjYUFgZOEp1fWYIoAKxZNOTf4AfiMbOGn2t8IFxe8JUYrAVy6tAE YnSnPM+nn4UeipLBwncBVhxUQU5R4W8b5k7tY8HJB+CWGgSbkyLWfxeuiwAA48nKqa6fOqo2ZpS4 ukNf9u8Hk3fIT8XvDJVnT2NwB7Z29oL3Fq20tm4M96SkuLlNjLZ9wvskfmYAk+PUP44ugvkB7Uon cAzoPXlkz3N5IB9Ly7/SIgsCAwEAAaOCAcYwggHCMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9j cmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggrBgEF BQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVh bGNhdjIuY2VyMCsGA1UdEQQkMCKBIGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9y eS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcD AjAdBgNVHQ4EFgQUOrfg77a5Xcj2OffxTY1aeC+5CqEwHwYDVR0jBBgwFoAUsQ3K1Ea3r4YCwy9v BsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQCddA412wylfbLwBiyQ uVz1IDcaYZ14Yh1L52IhX14BGl0eNc/5BbWL3yCF2eGv8h6FmckZHOM7+OS4g+inNZbaKysTkLah T3UbrUWFPpkZFAS1HfaxBJZTVS3UIVnIYP06ZvRRRNf3VJzwpZSES4tu0euzI2CatWCZLa+N4QyT ZkMnw1JLUXbz0dPA40b9Qdoec23PkpMqf1CxNNuaRBF9L5wKGily7RyPOtkcrWJ3R2oSGC7ugKK9 vWzQzEHoE95txgF/kq7MdRJks8BXqnb3w8Fthu+1zIORjcR9yxv1e9gYo0ZcaPqyjC/LDdzsHv59 5hkwQnxAGyPDBgCdq5Ion/4Lx+YI61SKcyGEH+VYD6CJX44/IfRAE+tq8BHZYOJLW8uCd7Jboqd2 jklsUfSPN8i4cvQpfYzDkrSziyfcvdplEvxSEbTEFZ+w6IbvCtV0xBSfS9+RhqBOn6LZSdw/jp+b 9penQAWekRykrKyKroDtwesqg0HbC7bkprqOwSaar5gcFGYVYJ5JuHT3Ou44hGn/yiwbTnc2Mb12 8nWesZQZvIT2n5Y42ZYebo1cLBYdF6U/Q5OHLOUk596LephQggvKphe7F2w87CpaUUoANa4H1ri+ LTOKdz+itrkbu3dDs6oDZuSwMU3fJaf8d/3PPLoGJtFQWQ8v2e/Oxxe0sDCCBrYwggSeoAMCAQIC EQCgDMvMm5mY7OI6cPR8wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJh MR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUy NzA3NDYyMVowOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqj ddx4Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehBraHZ abrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI7LvMiZtV aqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd0D7TGJtkdldV JtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGjA/CxX9aC5Vi1EMRJ iOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2FGBaauE8qHEO6qR3WAEgv jVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXdvo+6eAt45Bhvmeka2TrJDxML WiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzxb3nT1iHue5co9J93ta06kxiASHvc IzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQw gYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25l cmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5j b20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBM MEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3Qu dGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3Qu dGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUF BwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZx f0s3MB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBu ByBsr6x3PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9Iewy aV8n65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fvdcy0 4/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdness3e1qAEu eSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZWOs38FQhGWHWX I0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9bywhEfXjxLIC3Qhtu5l JPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92wbehSZD3mSSAemDVwGB2Y u0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEmJqe6g4XSQFj4mqtwvqhP4dg2 QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/emOtwCGXQ6tZCByMNLxeDwU1TGbTGC AvMwggLvAgEBME4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjICEHsnhOhQQR0nPGMw6VkdZlUwCQYFKw4DAhoFAKCCAXowGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNDA4MTcxNjI0WjAjBgkqhkiG9w0B CQQxFgQUUdS/c2awADMnFNtMNy6S6SVuPd0wWwYJKoZIhvcNAQkPMU4wTDAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF Kw4DAhowXQYJKwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJp Y3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQeyeE6FBBHSc8YzDpWR1mVTBfBgsqhkiG9w0BCRAC CzFQoE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEHsnhOhQQR0nPGMw6VkdZlUwDQYJKoZIhvcNAQEBBQAEggEAJzAAcmIP7jrz4Cs4 MOhtHazkJ16b0UDJoKq3HRwJVthm1rAKYxy6wqCVksQ77FgCds3OpqzRUn6EuMTZKIBRU0n47buX Zv7NDvMkp2jZfjg4C9TpypbQEAu4IHlkf8+k6XeOhH8kAVBhN/chsHMMzhDXdbsKYqUkZRopmSL4 gXXZtMAEhf4kpW5dZC+A7VWquTSBGszW8LnCnfsPuI1nqoXBOWyjB+ZNQOJRvydi+jc/yF1E77RS zHTR1rh1E1EuFueHSeM/GlPYlt1dyTtePifmfyfuk1g+67eyxC4FsRV+RtUnlhg9q3ym30qLWcx+ Z9+U5/7jgskeNoks2wufYgAAAAAAAA== ------=_NextPart_000_053D_01D191CB.2455DAD0-- From nobody Sat Apr 9 09:36:00 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C02112B049 for ; Sat, 9 Apr 2016 09:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.296 X-Spam-Level: X-Spam-Status: No, score=-3.296 tagged_above=-999 required=5 tests=[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 1Lm-Nn1bJnuZ for ; Sat, 9 Apr 2016 09:35:56 -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 77C0512B048 for ; Sat, 9 Apr 2016 09:35:56 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id BE7F61B00252 for ; Sat, 9 Apr 2016 17:48:07 +0100 (BST) Received: from 190.111.246.165 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Sat, 9 Apr 2016 17:35:54 +0100 Message-ID: Date: Sat, 9 Apr 2016 17:35:54 +0100 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: [tsvwg] TSVWG meeting notes now available - please send comments. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 16:35:59 -0000 The link below contains the current notes from the tsvwg meetings this week. Thanks to the note taker for taking the notes, and those who sentr me details. The notes also incorporate comments in the audio archive. If you have any further comments or corrections do contact the chairs (and/or the mailing list). Best wsihes, Gorry https://www.ietf.org/proceedings/95/minutes/minutes-95-tsvwg From nobody Mon Apr 11 11:45:10 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A36312B05F for ; Mon, 11 Apr 2016 11:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 0s4MP7eA5AM2 for ; Mon, 11 Apr 2016 11:45:07 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFD7112DBE9 for ; Mon, 11 Apr 2016 11:36:59 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-45-570beec95d28 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 28.80.22880.9CEEB075; Mon, 11 Apr 2016 20:36:58 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.173]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0248.002; Mon, 11 Apr 2016 20:36:33 +0200 From: Ingemar Johansson S To: "tsvwg@ietf.org" Thread-Topic: ECN support for UDP Thread-Index: AdGUH1Lod2hkx/E7R8Ssw5c7jhVcUw== Date: Mon, 11 Apr 2016 18:36:32 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA43DC47D4@ESESSMB205.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0501_01D19431.D50D9300" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsUyM2J7uO6pd9zhBvNmsVrsmzGR0eLYm7ts DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfG++l/mAtWtTNW/H/VyN7AuKuui5GTQ0LA RGLHz0lsELaYxIV764FsLg4hgSOMEruW/oZyljBK/NqxBKyKTcBGYuWh74wgtoiAqsTljrVM XYwcHMwCNRJ3btmDhIUFZCTmfL3ABlGiKLF3/XMmCFtPou3SNXYQmwWotfHJeVYQm1fAV+La kdNgcUYBWYn73++xgNjMAuISt57MZ4I4TkTi4cXTUIeKSrx8/I8VwlaSWHt4OwvIncwCvYwS 9/71MUEMFZQ4OfMJywRG4VlIZs1CVjcLSR1EUbTE1x/H2SFsA4n7hzpYIWxtiWULXzND2PoS bcdWM2OKW0vM+HWQDcJWlJjS/RBqjqnE66MfGRcwcq9iFC1OLS7OTTcy1kstykwuLs7P08tL LdnECIzSg1t+6+5gXP3a8RCjAAejEg+vAit3uBBrYllxZe4hRhWgOY82rL7AKMWSl5+XqiTC +/gNUJo3JbGyKrUoP76oNCe1+BCjNAeLkjhvTuS/MCGB9MSS1OzU1ILUIpgsEwenVANjWfPL 0917G8/3dGuWndyc5fDm+MHfu3MmV0uFMM5yPbZkyaukxGMzzM4Isk8IYt+/hdXEc8e0uyu/ znLOuf7g+QKPsuUxW/b8Wu64uYinZ83ha1EK77ImruELC66N2Wj8a81VgePhF4Oj36uXOt7b JZfB9+/fklAVuVlbuBSO5hvOyFLNqgu9oMRSnJFoqMVcVJwIALnGapXaAgAA Archived-At: Cc: Ingemar Johansson S Subject: [tsvwg] ECN support for UDP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 18:45:08 -0000 ------=_NextPart_000_0501_01D19431.D50D9300 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0502_01D19431.D50D9300" ------=_NextPart_001_0502_01D19431.D50D9300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi =20 The lack of support for ECN over UDP is every once in a while brought up = as an argument against ECN.=20 As there are (I believe) representatives for major OS vendors and also kernel experts on this list, the humble question is :=20 What are the possible ways to get access to the ECN bits from an UDP = socket for operative systems such as MS Windows, iOS, Linux, FreeBSD=85 Can = these methods be done from user space or do they require that e.g. the device = is rooted ?.=20 =20 Piers O=B4Hanlon compiled the summary in the link below, I wonder if = something has happened recently https://mailarchive.ietf.org/arch/msg/rmcat/rRKF3PVmFL2zHCp1bOPKimqSsbM =20 /Ingemar =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc.=20 Master Researcher =20 Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 = ingemar.s.johansson@ericsson.com www.ericsson.com =20 This report, by it=B4s very length,=20 defends itself against the risk of being read Winston Churchill =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 ------=_NextPart_001_0502_01D19431.D50D9300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

The lack of support for = ECN over UDP is every once in a while brought up as an argument against = ECN.

As there are (I believe) representatives for = major OS vendors and also kernel experts on this list, the humble = question is :

What are the possible ways to get access to the = ECN bits from an UDP socket for operative systems such as MS Windows, = iOS, Linux, FreeBSD… Can these methods be done from user space or = do they require that e.g. the device is rooted ?. =

 

Piers O=B4Hanlon = compiled the summary in the link below, I wonder if something has = happened recently

https://mailarchive.ietf.org/arch/msg/rmcat/rRKF3PVmFL2zHCp1bOPKi= mqSsbM

 

/Ingemar

 

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

Ingemar = Johansson  M.Sc.

Master = Researcher

 

Ericsson = AB

Wireless = Access Networks

Labratoriegr=E4= nd 11

971 28, = Lule=E5, Sweden

Phone = +46-1071 43042

SMS/MMS = +46-73 078 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 This report, by it=B4s very length, =

=A0defends = itself against the risk of being read

= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Wins= ton Churchill

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

 

------=_NextPart_001_0502_01D19431.D50D9300-- ------=_NextPart_000_0501_01D19431.D50D9300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVYzCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGADCCA+igAwIBAgIQ eyeE6FBBHSc8YzDpWR1mVTANBgkqhkiG9w0BAQUFADA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMG A1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjAeFw0xNDEyMDIxNDI5MTdaFw0xNzEy MDIxNDI5MTZaMHQxETAPBgNVBAoMCEVyaWNzc29uMRwwGgYDVQQDDBNJbmdlbWFyIEpvaGFuc3Nv biBTMS8wLQYJKoZIhvcNAQkBFiBpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTEQMA4G A1UEBRMHRVBMSUpPSDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK6dOkJu7hl4aOKX k6YBf5PgWpDbO6iINxyYJetBuJZJqEdDqKukaHZmP8Rn5hhiQZDWa89koR41DNS7umMwZtHQkN+j m3b5Z1LUMQle7XDtUy3rn47hgjYUFgZOEp1fWYIoAKxZNOTf4AfiMbOGn2t8IFxe8JUYrAVy6tAE YnSnPM+nn4UeipLBwncBVhxUQU5R4W8b5k7tY8HJB+CWGgSbkyLWfxeuiwAA48nKqa6fOqo2ZpS4 ukNf9u8Hk3fIT8XvDJVnT2NwB7Z29oL3Fq20tm4M96SkuLlNjLZ9wvskfmYAk+PUP44ugvkB7Uon cAzoPXlkz3N5IB9Ly7/SIgsCAwEAAaOCAcYwggHCMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9j cmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggrBgEF BQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVh bGNhdjIuY2VyMCsGA1UdEQQkMCKBIGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9y eS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcD AjAdBgNVHQ4EFgQUOrfg77a5Xcj2OffxTY1aeC+5CqEwHwYDVR0jBBgwFoAUsQ3K1Ea3r4YCwy9v BsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQCddA412wylfbLwBiyQ uVz1IDcaYZ14Yh1L52IhX14BGl0eNc/5BbWL3yCF2eGv8h6FmckZHOM7+OS4g+inNZbaKysTkLah T3UbrUWFPpkZFAS1HfaxBJZTVS3UIVnIYP06ZvRRRNf3VJzwpZSES4tu0euzI2CatWCZLa+N4QyT ZkMnw1JLUXbz0dPA40b9Qdoec23PkpMqf1CxNNuaRBF9L5wKGily7RyPOtkcrWJ3R2oSGC7ugKK9 vWzQzEHoE95txgF/kq7MdRJks8BXqnb3w8Fthu+1zIORjcR9yxv1e9gYo0ZcaPqyjC/LDdzsHv59 5hkwQnxAGyPDBgCdq5Ion/4Lx+YI61SKcyGEH+VYD6CJX44/IfRAE+tq8BHZYOJLW8uCd7Jboqd2 jklsUfSPN8i4cvQpfYzDkrSziyfcvdplEvxSEbTEFZ+w6IbvCtV0xBSfS9+RhqBOn6LZSdw/jp+b 9penQAWekRykrKyKroDtwesqg0HbC7bkprqOwSaar5gcFGYVYJ5JuHT3Ou44hGn/yiwbTnc2Mb12 8nWesZQZvIT2n5Y42ZYebo1cLBYdF6U/Q5OHLOUk596LephQggvKphe7F2w87CpaUUoANa4H1ri+ LTOKdz+itrkbu3dDs6oDZuSwMU3fJaf8d/3PPLoGJtFQWQ8v2e/Oxxe0sDCCBrYwggSeoAMCAQIC EQCgDMvMm5mY7OI6cPR8wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJh MR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUy NzA3NDYyMVowOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqj ddx4Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehBraHZ abrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI7LvMiZtV aqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd0D7TGJtkdldV JtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGjA/CxX9aC5Vi1EMRJ iOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2FGBaauE8qHEO6qR3WAEgv jVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXdvo+6eAt45Bhvmeka2TrJDxML WiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzxb3nT1iHue5co9J93ta06kxiASHvc IzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQw gYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25l cmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5j b20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBM MEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3Qu dGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3Qu dGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUF BwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZx f0s3MB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBu ByBsr6x3PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9Iewy aV8n65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fvdcy0 4/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdness3e1qAEu eSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZWOs38FQhGWHWX I0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9bywhEfXjxLIC3Qhtu5l JPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92wbehSZD3mSSAemDVwGB2Y u0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEmJqe6g4XSQFj4mqtwvqhP4dg2 QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/emOtwCGXQ6tZCByMNLxeDwU1TGbTGC AvMwggLvAgEBME4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjICEHsnhOhQQR0nPGMw6VkdZlUwCQYFKw4DAhoFAKCCAXowGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNDExMTgzNjMxWjAjBgkqhkiG9w0B CQQxFgQU4qXv2TpY3b/8zwf/VlaSwnhC2k0wWwYJKoZIhvcNAQkPMU4wTDAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF Kw4DAhowXQYJKwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJp Y3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQeyeE6FBBHSc8YzDpWR1mVTBfBgsqhkiG9w0BCRAC CzFQoE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEHsnhOhQQR0nPGMw6VkdZlUwDQYJKoZIhvcNAQEBBQAEggEAeO0946zmEVqDg2du YbSN26/AonoNR4zZt4KEZxPE4cpFr1EgkR5+vUcBmrxGYX36+KOA3LXZFxtLbNnNm8GFjGea7r0x buNhBJOMp9UQbj05ipoheo6/m3ZQY8PckTsEAlMRUYL94goNdICTyOlm+YoFg1CFNe7CdKjt/2kg J91y5Y/4lWD86xT0YKk3XFarMG8/vqY/oNFN9R8MXL0b1yM+o4wjefJUXtShyUu8C4bOgZ/Rp3XD LZWx0a62hiu+V0nFdKwvBVO+yhVC+7lcJ9NMDW132cwlA1+PH27r5F5Sya16EOO2JotZMCl/DFOG ogi5oOJJ4tH0IShlj/cOeAAAAAAAAA== ------=_NextPart_000_0501_01D19431.D50D9300-- From nobody Mon Apr 11 12:32:54 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB5E12E968 for ; Mon, 11 Apr 2016 12:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 mSgugRRosqSj for ; Mon, 11 Apr 2016 12:32:51 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 976B112E68D for ; Mon, 11 Apr 2016 12:32:51 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id g185so222979700ioa.2 for ; Mon, 11 Apr 2016 12:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=1zobRkLbP2KACEZrQraPrTqDZFbMCpxKd1KOSELMOeQ=; b=TxjldhlsGbr69Q5sN0arUDllsuauXRHxfkIBzL+7ME8MuGcrrwWN3XeQIFfDOOQZSj 7zqp4/baqIVQASyO/68ar0rZgVpdkEs2HBiXBV2bUyT2JqNhpH3bxXfHVfIJbgLDg5zv M/fRQwPiEcgXmweM+dQL4EHNuj0svGbC7RJTTgZ9uYTnCCrCGbs/x4qAgVSTMRVdPMWK reRzUtVedwMq5DsaB8r9ziaiM4yfUk1gNv5swBG1daSBGGpc3fZDZc/LJ9e+ndqeY1za xZ83iQhxeviRqBgpvrjB+78Ry0JRkdDPhZldjw+RPM44ke+d9bj9nVHyC+dE8kWF+yVR HV0Q== 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:content-transfer-encoding; bh=1zobRkLbP2KACEZrQraPrTqDZFbMCpxKd1KOSELMOeQ=; b=DWxFCOLwHVvn5EYE715cKVwRoyVeX7cvjnvW0oKYnaC11GWO0/yvLEEdcA5+Xljhep E+hoftYwBLOVRj2YhLlIaTUC/LOzdZbZwdXe0iGd2NOQ3u8Z3ZzHa12f8l8hNn1cFzl5 HwDC3gz1HMmLqQSO8mcQLbnuAQUjqYThbcrLxFU9TD3JvVrKRpWkDm3A3jvFTo7NO9nR QnJWY7H+y+3t0F3WptRx8P8ove8QsEiJJPFkmn5QmDXGXK3grmOCfujOLXBZtbDp1ZhQ E8n23i0q3afayKkA59RdrHM9FFj5Slacnn9ZM27TVTNsBgpDgRCM0LbEklIEHjrhS4xj Jjng== X-Gm-Message-State: AD7BkJIcjQeZLvNBavzKHU9ovCCT7IixFBpZiq0OHXOawvVisfzuxwTQTsYK+0uSOkn6XsM29+v7CNyqVX/eQg== MIME-Version: 1.0 X-Received: by 10.107.7.30 with SMTP id 30mr27973061ioh.107.1460403170824; Mon, 11 Apr 2016 12:32:50 -0700 (PDT) Received: by 10.107.142.67 with HTTP; Mon, 11 Apr 2016 12:32:50 -0700 (PDT) In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA43DC47D4@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA43DC47D4@ESESSMB205.ericsson.se> Date: Mon, 11 Apr 2016 12:32:50 -0700 Message-ID: From: Tom Herbert To: Ingemar Johansson S Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] ECN support for UDP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 19:32:54 -0000 On Mon, Apr 11, 2016 at 11:36 AM, Ingemar Johansson S wrote: > Hi > > > > The lack of support for ECN over UDP is every once in a while brought up = as > an argument against ECN. > > As there are (I believe) representatives for major OS vendors and also > kernel experts on this list, the humble question is : > > What are the possible ways to get access to the ECN bits from an UDP sock= et > for operative systems such as MS Windows, iOS, Linux, FreeBSD=E2=80=A6 Ca= n these > methods be done from user space or do they require that e.g. the device i= s > rooted ?. > The ECN bits and be set and received as described in the the document for at least Linux and presumably FreeBSD. These are not privileged operations. I don't think anything has changed recently for these. Tom > > > Piers O=C2=B4Hanlon compiled the summary in the link below, I wonder if s= omething > has happened recently > > https://mailarchive.ietf.org/arch/msg/rmcat/rRKF3PVmFL2zHCp1bOPKimqSsbM > > > > /Ingemar > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Ingemar Johansson M.Sc. > > Master Researcher > > > > Ericsson AB > > Wireless Access Networks > > Labratoriegr=C3=A4nd 11 > > 971 28, Lule=C3=A5, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 > > ingemar.s.johansson@ericsson.com > > www.ericsson.com > > > > This report, by it=C2=B4s very length, > > defends itself against the risk of being read > > Winston Churchill > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > From nobody Tue Apr 12 02:15:07 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82B312EB04 for ; Tue, 12 Apr 2016 02:15:06 -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 ZejpQBbyhon1 for ; Tue, 12 Apr 2016 02:15:03 -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 0D90F12EB01 for ; Tue, 12 Apr 2016 02:15:03 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 642221B001C9; Tue, 12 Apr 2016 10:27:13 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Tue, 12 Apr 2016 10:15:01 +0100 Message-ID: <61e555df80c580708d7bc634e0034e7a.squirrel@erg.abdn.ac.uk> In-Reply-To: References: <81564C0D7D4D2A4B9A86C8C7404A13DA43DC47D4@ESESSMB205.ericsson.se> Date: Tue, 12 Apr 2016 10:15:01 +0100 From: gorry@erg.abdn.ac.uk To: "Tom Herbert" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: Ingemar Johansson S , "tsvwg@ietf.org" Subject: Re: [tsvwg] ECN support for UDP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 09:15:06 -0000 Although it's not an immediate solution... my UDP document to the TAPS WG will describe ECN support for UDP as a stanadrd transport API function. Gorry > On Mon, Apr 11, 2016 at 11:36 AM, Ingemar Johansson S > wrote: >> Hi >> >> >> >> The lack of support for ECN over UDP is every once in a while brought up >> as >> an argument against ECN. >> >> As there are (I believe) representatives for major OS vendors and also >> kernel experts on this list, the humble question is : >> >> What are the possible ways to get access to the ECN bits from an UDP >> socket >> for operative systems such as MS Windows, iOS, Linux, FreeBSD… Can >> these >> methods be done from user space or do they require that e.g. the device >> is >> rooted ?. >> > The ECN bits and be set and received as described in the the document > for at least Linux and presumably FreeBSD. These are not privileged > operations. I don't think anything has changed recently for these. > > Tom > >> >> >> Piers O´Hanlon compiled the summary in the link below, I wonder if >> something >> has happened recently >> >> https://mailarchive.ietf.org/arch/msg/rmcat/rRKF3PVmFL2zHCp1bOPKimqSsbM >> >> >> >> /Ingemar >> >> >> >> ================================== >> >> Ingemar Johansson M.Sc. >> >> Master Researcher >> >> >> >> Ericsson AB >> >> Wireless Access Networks >> >> Labratoriegränd 11 >> >> 971 28, Luleå, Sweden >> >> Phone +46-1071 43042 >> >> SMS/MMS +46-73 078 3289 >> >> ingemar.s.johansson@ericsson.com >> >> www.ericsson.com >> >> >> >> This report, by it´s very length, >> >> defends itself against the risk of being read >> >> Winston Churchill >> >> ================================== >> >> > From nobody Tue Apr 12 02:35:03 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B5712EB3E for ; Tue, 12 Apr 2016 02:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_HELO_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 yj0aLLssK3EZ for ; Tue, 12 Apr 2016 02:34:59 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D27D912E998 for ; Tue, 12 Apr 2016 02:34:58 -0700 (PDT) Received: from [192.168.1.7] (p4FE3078A.dip0.t-ipconnect.de [79.227.7.138]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id BFC7B7004401B; Tue, 12 Apr 2016 11:34:54 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Tuexen In-Reply-To: Date: Tue, 12 Apr 2016 11:34:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <81564C0D7D4D2A4B9A86C8C7404A13DA43DC47D4@ESESSMB205.ericsson.se> To: Tom Herbert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Ingemar Johansson S , "tsvwg@ietf.org" Subject: Re: [tsvwg] ECN support for UDP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 09:35:02 -0000 > On 11 Apr 2016, at 21:32, Tom Herbert wrote: >=20 > On Mon, Apr 11, 2016 at 11:36 AM, Ingemar Johansson S > wrote: >> Hi >>=20 >>=20 >>=20 >> The lack of support for ECN over UDP is every once in a while brought = up as >> an argument against ECN. >>=20 >> As there are (I believe) representatives for major OS vendors and = also >> kernel experts on this list, the humble question is : >>=20 >> What are the possible ways to get access to the ECN bits from an UDP = socket >> for operative systems such as MS Windows, iOS, Linux, FreeBSD=E2=80=A6 = Can these >> methods be done from user space or do they require that e.g. the = device is >> rooted ?. >>=20 > The ECN bits and be set and received as described in the the document > for at least Linux and presumably FreeBSD. These are not privileged FreeBSD supports it. Best regards Michael > operations. I don't think anything has changed recently for these. >=20 > Tom >=20 >>=20 >>=20 >> Piers O=C2=B4Hanlon compiled the summary in the link below, I wonder = if something >> has happened recently >>=20 >> = https://mailarchive.ietf.org/arch/msg/rmcat/rRKF3PVmFL2zHCp1bOPKimqSsbM >>=20 >>=20 >>=20 >> /Ingemar >>=20 >>=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Ingemar Johansson M.Sc. >>=20 >> Master Researcher >>=20 >>=20 >>=20 >> Ericsson AB >>=20 >> Wireless Access Networks >>=20 >> Labratoriegr=C3=A4nd 11 >>=20 >> 971 28, Lule=C3=A5, Sweden >>=20 >> Phone +46-1071 43042 >>=20 >> SMS/MMS +46-73 078 3289 >>=20 >> ingemar.s.johansson@ericsson.com >>=20 >> www.ericsson.com >>=20 >>=20 >>=20 >> This report, by it=C2=B4s very length, >>=20 >> defends itself against the risk of being read >>=20 >> Winston Churchill >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>=20 >=20 From nobody Fri Apr 15 07:47:55 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8A212E7C5 for ; Fri, 15 Apr 2016 07:47:53 -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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 i-fIMu_Mcd27 for ; Fri, 15 Apr 2016 07:47:50 -0700 (PDT) Received: from smtp90.iad3a.emailsrvr.com (smtp90.iad3a.emailsrvr.com [173.203.187.90]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA72812E346 for ; Fri, 15 Apr 2016 07:47:50 -0700 (PDT) Received: from smtp28.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp28.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id ED642380456; Fri, 15 Apr 2016 10:47:49 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp28.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 06D2A380499; Fri, 15 Apr 2016 10:47:48 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.191]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Fri, 15 Apr 2016 10:47:49 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Fri, 15 Apr 2016 08:47:50 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160321174750.31944.71903.idtracker@ietfa.amsl.com> <56F26AD3.3010403@ericsson.com> <5BB71158-3530-47A2-9A33-811F65B2F677@iii.ca> <56FBBBC1.5060902@ericsson.com> To: "Black, David" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Magnus Westerlund , "tsvwg@ietf.org" , "draft-ietf-tsvwg-rtcweb-qos@ietf.org" , "ietf@ietf.org" , "tsvwg-chairs@ietf.org" Subject: Re: [tsvwg] Last Call: (DSCP and other packet markings for WebRTC QoS) to Proposed Standard X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 14:47:53 -0000 > On Apr 3, 2016, at 3:37 PM, Black, David wrote: >=20 > I see a couple of Magnus's points that appear to need additional text > in the draft: >=20 > [1] Flow Type in application-facing browser API: >=20 >>>>>> o Flow Type: The browser provides this input as it knows if >>>>>> the flow is audio, interactive video with or without audio, >>>>>> non-interactive video with or without audio, or data. >=20 > [... snip ...] >=20 >> The main issue here is that to me it was not clear that "Interactive >> Video with or without audio" allows for setting these DSCP values = also >> for the RTP stream containing audio also. This, I do see a need for >> clarification on. >=20 > Propose an additional sentence: > OLD > o Flow Type: The browser provides this input as it knows if the = flow > is audio, interactive video with or without audio, = non-interactive > video with or without audio, or data. > NEW > o Flow Type: The browser provides this input as it knows if the = flow > is audio, interactive video with or without audio, = non-interactive > video with or without audio, or data. For audio that is = associated > with a video flow, the flow type of the associated video MAY > be used instead of the associated audio type. >=20 > I hesitate to say anything stronger than "MAY" here. Looks good.=20 >=20 > [2] What does "interactive" mean in an implementation?: We could add something along lines of ..... Currently in WebRTC, media = sent over RTP is assumed to be interactive while media streamed over = HTTP is assumed not to be. Future WebRTC extensions could allow streamed = media over RTP. >=20 >> The issue is that this document is called: DSCP and other packet >> markings for WebRTC QoS. Then this document define something that is = not >> immediately mappable onto what is being defined in the other WebRTC >> specifications. That is why I am raising that there need to be more >> clear coupling. If that coupling is to mostly happen in another >> document, can we at least then have a proposal on the table for that >> change to ensure that the result is understandable. >=20 > Well, this TSVWG draft is definitely not the right place for a = discussion of > when a video flow is interactive or non-interactive - I hope we can = agree > on that. >=20 > Beyond that, as Cullen (Jennings) is both an author of this document = and > one of the chairs of the rtcweb WG, I'd suggest that he and/or the = rtcweb > WG propose an appropriate location for discussion of when a video flow > is interactive or non-interactive. This TSVWG draft would then have = an > additional sentence added, e.g., >=20 > See [TBD] for further discussion of how to determine > whether a video flow is interactive vs. non-interactive. >=20 > I believe that the added reference here ([TBD] above) would be = normative. >=20 > Cullen? That discussion happened long ago for WebRTC and we decided we did not = need a JavaScript controls point in the WebRTC API to indicate if RTP = was interactive or not. If people start doing streaming video over RTP = we can come back and revisit this and trivially add an API to indicate = that in the W3C WebRTC API. Part of what drove this decision is the = likes of Netflix / ITunes / Youtube are not asking the browser vendors = for streaming media over RTSP or RTP. They think HTTP works much better = for this. Thus the browser vendors see no need for non interactive video = over RTP. I agree with Magnus that this might change some day in the = future but right now, I think it's close enough that everyone can live = with it.=20 I'm not OK in treating it like some open issue that is still in = discussion that somehow holds up this spec - it's not.=20 >=20 > Thanks, --David (as document shepherd) >=20 From nobody Mon Apr 18 06:05:20 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2477F12D5D7; Mon, 18 Apr 2016 06:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.317 X-Spam-Level: X-Spam-Status: No, score=-5.317 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 pJAXAN0rYD1f; Mon, 18 Apr 2016 06:05:15 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 9805B12D60F; Mon, 18 Apr 2016 06:05:15 -0700 (PDT) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u3ID58ZA010541 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Apr 2016 09:05:09 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com u3ID58ZA010541 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1460984709; bh=hBMeVa+zh9In9/S5DCDKI4HW7RY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=riy6hRjooHfNi10zHttjD3l6DurcbCQSAjtqNL6ExhKYIfwddcirU4OzyGgtuFrH7 aJY2gZH5jjTqj47rjpu9uL4TeHN1u4AmKfNSFQleIF0mHskUmUHRwWfa7hTrwYMtCL RseHbZ7+Isj6Z6gn2kW9M9U87yfyG05EuDUQ+L6M= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com u3ID58ZA010541 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd53.lss.emc.com (RSA Interceptor); Mon, 18 Apr 2016 09:04:30 -0400 Received: from MXHUB106.corp.emc.com (MXHUB106.corp.emc.com [10.253.58.23]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u3ID4rjo018392 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Apr 2016 09:04:53 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.9]) by MXHUB106.corp.emc.com ([10.253.58.23]) with mapi id 14.03.0266.001; Mon, 18 Apr 2016 09:04:52 -0400 From: "Black, David" To: Cullen Jennings Thread-Topic: [tsvwg] Last Call: (DSCP and other packet markings for WebRTC QoS) to Proposed Standard Thread-Index: AQHRg5nK94t/8iR5sU+B/9y+8LxFIp9nE2eAgADT/gCACkcQgIAGp9UQgBKxIQCABFTqQA== Date: Mon, 18 Apr 2016 13:04:52 +0000 Message-ID: References: <20160321174750.31944.71903.idtracker@ietfa.amsl.com> <56F26AD3.3010403@ericsson.com> <5BB71158-3530-47A2-9A33-811F65B2F677@iii.ca> <56FBBBC1.5060902@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.240.141] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: Magnus Westerlund , "draft-ietf-tsvwg-rtcweb-qos@ietf.org" , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" , "ietf@ietf.org" Subject: Re: [tsvwg] Last Call: (DSCP and other packet markings for WebRTC QoS) to Proposed Standard X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 13:05:17 -0000 So, summarizing Magnus's concerns with proposals: > > [1] Flow Type in application-facing browser API: > > Propose an additional sentence: > > OLD > > o Flow Type: The browser provides this input as it knows if the flow > > is audio, interactive video with or without audio, non-interactive > > video with or without audio, or data. > > NEW > > o Flow Type: The browser provides this input as it knows if the flow > > is audio, interactive video with or without audio, non-interactive > > video with or without audio, or data. For audio that is associate= d > > with a video flow, the flow type of the associated video MAY > > be used instead of the associated audio type. Magnus - does that new text suffice? > > [2] What does "interactive" mean in an implementation?: >=20 > We could add something along lines of ..... Currently in WebRTC, media se= nt over > RTP is assumed to be interactive while media streamed over HTTP is assume= d not > to be. Future WebRTC extensions could allow streamed media over RTP. I believe the proposed additional sentence addresses the question of how a = browser determines whether a video flow is interactive. This proposed sentence wil= l need to cite a WebRTC document that contains a statement to that effect, as I don't= think this draft is the right place to be the primary reference for that statement. Magnus - would this approach be ok? Thanks, --David > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@iii.ca] > Sent: Friday, April 15, 2016 10:48 AM > To: Black, David > Cc: Magnus Westerlund; ietf@ietf.org; tsvwg-chairs@ietf.org; draft-ietf-t= svwg- > rtcweb-qos@ietf.org; tsvwg@ietf.org > Subject: Re: [tsvwg] Last Call: (DSC= P and > other packet markings for WebRTC QoS) to Proposed Standard >=20 >=20 > > On Apr 3, 2016, at 3:37 PM, Black, David wrote: > > > > I see a couple of Magnus's points that appear to need additional text > > in the draft: > > > > [1] Flow Type in application-facing browser API: > > > >>>>>> o Flow Type: The browser provides this input as it knows if > >>>>>> the flow is audio, interactive video with or without audio, > >>>>>> non-interactive video with or without audio, or data. > > > > [... snip ...] > > > >> The main issue here is that to me it was not clear that "Interactive > >> Video with or without audio" allows for setting these DSCP values also > >> for the RTP stream containing audio also. This, I do see a need for > >> clarification on. > > > > Propose an additional sentence: > > OLD > > o Flow Type: The browser provides this input as it knows if the flow > > is audio, interactive video with or without audio, non-interactive > > video with or without audio, or data. > > NEW > > o Flow Type: The browser provides this input as it knows if the flow > > is audio, interactive video with or without audio, non-interactive > > video with or without audio, or data. For audio that is associate= d > > with a video flow, the flow type of the associated video MAY > > be used instead of the associated audio type. > > > > I hesitate to say anything stronger than "MAY" here. >=20 > Looks good. >=20 > > > > [2] What does "interactive" mean in an implementation?: >=20 > We could add something along lines of ..... Currently in WebRTC, media se= nt over > RTP is assumed to be interactive while media streamed over HTTP is assume= d not > to be. Future WebRTC extensions could allow streamed media over RTP. >=20 >=20 > > > >> The issue is that this document is called: DSCP and other packet > >> markings for WebRTC QoS. Then this document define something that is n= ot > >> immediately mappable onto what is being defined in the other WebRTC > >> specifications. That is why I am raising that there need to be more > >> clear coupling. If that coupling is to mostly happen in another > >> document, can we at least then have a proposal on the table for that > >> change to ensure that the result is understandable. > > > > Well, this TSVWG draft is definitely not the right place for a discussi= on of > > when a video flow is interactive or non-interactive - I hope we can agr= ee > > on that. > > > > Beyond that, as Cullen (Jennings) is both an author of this document an= d > > one of the chairs of the rtcweb WG, I'd suggest that he and/or the rtcw= eb > > WG propose an appropriate location for discussion of when a video flow > > is interactive or non-interactive. This TSVWG draft would then have an > > additional sentence added, e.g., > > > > See [TBD] for further discussion of how to determine > > whether a video flow is interactive vs. non-interactive. > > > > I believe that the added reference here ([TBD] above) would be normativ= e. > > > > Cullen? >=20 > That discussion happened long ago for WebRTC and we decided we did not ne= ed > a JavaScript controls point in the WebRTC API to indicate if RTP was inte= ractive or > not. If people start doing streaming video over RTP we can come back and = revisit > this and trivially add an API to indicate that in the W3C WebRTC API. Par= t of what > drove this decision is the likes of Netflix / ITunes / Youtube are not as= king the > browser vendors for streaming media over RTSP or RTP. They think HTTP wor= ks > much better for this. Thus the browser vendors see no need for non intera= ctive > video over RTP. I agree with Magnus that this might change some day in th= e > future but right now, I think it's close enough that everyone can live wi= th it. >=20 > I'm not OK in treating it like some open issue that is still in discussio= n that > somehow holds up this spec - it's not. >=20 > > > > Thanks, --David (as document shepherd) > > From nobody Mon Apr 18 11:57:54 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8551F12E5A7; Mon, 18 Apr 2016 11:57:52 -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 KIUF471tE0K2; Mon, 18 Apr 2016 11:57:49 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id EC61012E5A4; Mon, 18 Apr 2016 11:57:48 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id C68F31B00055; Mon, 18 Apr 2016 20:09:55 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Mon, 18 Apr 2016 19:57:47 +0100 Message-ID: In-Reply-To: References: <20160321174750.31944.71903.idtracker@ietfa.amsl.com> <56F26AD3.3010403@ericsson.com> <5BB71158-3530-47A2-9A33-811F65B2F677@iii.ca> <56FBBBC1.5060902@ericsson.com> Date: Mon, 18 Apr 2016 19:57:47 +0100 From: gorry@erg.abdn.ac.uk To: "Black, David" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: Magnus Westerlund , "draft-ietf-tsvwg-rtcweb-qos@ietf.org" , "ietf@ietf.org" , "tsvwg-chairs@ietf.org" , Cullen Jennings , "tsvwg@ietf.org" Subject: Re: [tsvwg] Last Call: (DSCP and other packet markings for WebRTC QoS) to Proposed Standard X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 18:57:52 -0000 Looks good to me, but I'd prefer /as/because/ Gorry > So, summarizing Magnus's concerns with proposals: > >> > [1] Flow Type in application-facing browser API: > >> > Propose an additional sentence: >> > OLD >> > o Flow Type: The browser provides this input as it knows if the >> flow >> > is audio, interactive video with or without audio, >> non-interactive >> > video with or without audio, or data. >> > NEW >> > o Flow Type: The browser provides this input as it knows if the >> flow >> > is audio, interactive video with or without audio, >> non-interactive >> > video with or without audio, or data. For audio that is >> associated >> > with a video flow, the flow type of the associated video MAY >> > be used instead of the associated audio type. > > Magnus - does that new text suffice? > >> > [2] What does "interactive" mean in an implementation?: >> >> We could add something along lines of ..... Currently in WebRTC, media >> sent over >> RTP is assumed to be interactive while media streamed over HTTP is >> assumed not >> to be. Future WebRTC extensions could allow streamed media over RTP. > > I believe the proposed additional sentence addresses the question of how a > browser > determines whether a video flow is interactive. This proposed sentence > will need to > cite a WebRTC document that contains a statement to that effect, as I > don't think this > draft is the right place to be the primary reference for that statement. > > Magnus - would this approach be ok? > > Thanks, --David > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@iii.ca] >> Sent: Friday, April 15, 2016 10:48 AM >> To: Black, David >> Cc: Magnus Westerlund; ietf@ietf.org; tsvwg-chairs@ietf.org; >> draft-ietf-tsvwg- >> rtcweb-qos@ietf.org; tsvwg@ietf.org >> Subject: Re: [tsvwg] Last Call: >> (DSCP and >> other packet markings for WebRTC QoS) to Proposed Standard >> >> >> > On Apr 3, 2016, at 3:37 PM, Black, David wrote: >> > >> > I see a couple of Magnus's points that appear to need additional text >> > in the draft: >> > >> > [1] Flow Type in application-facing browser API: >> > >> >>>>>> o Flow Type: The browser provides this input as it knows if >> >>>>>> the flow is audio, interactive video with or without audio, >> >>>>>> non-interactive video with or without audio, or data. >> > >> > [... snip ...] >> > >> >> The main issue here is that to me it was not clear that "Interactive >> >> Video with or without audio" allows for setting these DSCP values >> also >> >> for the RTP stream containing audio also. This, I do see a need for >> >> clarification on. >> > >> > Propose an additional sentence: >> > OLD >> > o Flow Type: The browser provides this input as it knows if the >> flow >> > is audio, interactive video with or without audio, >> non-interactive >> > video with or without audio, or data. >> > NEW >> > o Flow Type: The browser provides this input as it knows if the >> flow >> > is audio, interactive video with or without audio, >> non-interactive >> > video with or without audio, or data. For audio that is >> associated >> > with a video flow, the flow type of the associated video MAY >> > be used instead of the associated audio type. >> > >> > I hesitate to say anything stronger than "MAY" here. >> >> Looks good. >> >> > >> > [2] What does "interactive" mean in an implementation?: >> >> We could add something along lines of ..... Currently in WebRTC, media >> sent over >> RTP is assumed to be interactive while media streamed over HTTP is >> assumed not >> to be. Future WebRTC extensions could allow streamed media over RTP. >> >> >> > >> >> The issue is that this document is called: DSCP and other packet >> >> markings for WebRTC QoS. Then this document define something that is >> not >> >> immediately mappable onto what is being defined in the other WebRTC >> >> specifications. That is why I am raising that there need to be more >> >> clear coupling. If that coupling is to mostly happen in another >> >> document, can we at least then have a proposal on the table for that >> >> change to ensure that the result is understandable. >> > >> > Well, this TSVWG draft is definitely not the right place for a >> discussion of >> > when a video flow is interactive or non-interactive - I hope we can >> agree >> > on that. >> > >> > Beyond that, as Cullen (Jennings) is both an author of this document >> and >> > one of the chairs of the rtcweb WG, I'd suggest that he and/or the >> rtcweb >> > WG propose an appropriate location for discussion of when a video flow >> > is interactive or non-interactive. This TSVWG draft would then have >> an >> > additional sentence added, e.g., >> > >> > See [TBD] for further discussion of how to determine >> > whether a video flow is interactive vs. non-interactive. >> > >> > I believe that the added reference here ([TBD] above) would be >> normative. >> > >> > Cullen? >> >> That discussion happened long ago for WebRTC and we decided we did not >> need >> a JavaScript controls point in the WebRTC API to indicate if RTP was >> interactive or >> not. If people start doing streaming video over RTP we can come back and >> revisit >> this and trivially add an API to indicate that in the W3C WebRTC API. >> Part of what >> drove this decision is the likes of Netflix / ITunes / Youtube are not >> asking the >> browser vendors for streaming media over RTSP or RTP. They think HTTP >> works >> much better for this. Thus the browser vendors see no need for non >> interactive >> video over RTP. I agree with Magnus that this might change some day in >> the >> future but right now, I think it's close enough that everyone can live >> with it. >> >> I'm not OK in treating it like some open issue that is still in >> discussion that >> somehow holds up this spec - it's not. >> >> > >> > Thanks, --David (as document shepherd) >> > > From nobody Mon Apr 18 12:41:20 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4820F12E680; Mon, 18 Apr 2016 12:41:17 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160418194117.11079.98395.idtracker@ietfa.amsl.com> Date: Mon, 18 Apr 2016 12:41:17 -0700 Archived-At: Cc: tsvwg-chairs@ietf.org, draft-ietf-tsvwg-rtcweb-qos@ietf.org, tsvwg@ietf.org Subject: [tsvwg] Second Last Call: (DSCP and other packet markings for WebRTC QoS) to Proposed Standard X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 19:41:18 -0000 The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'DSCP and other packet markings for WebRTC QoS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-05-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Many networks, such as service provider and enterprise networks, can provide different forwarding treatments for individual packets based on Differentiated Services Code Point (DSCP) values on a per-hop basis. This document provides the recommended DSCP values for web browsers to use for various classes of WebRTC traffic. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/ballot/ No IPR declarations have been submitted directly on this I-D. Please note that this standards-track draft includes normative references to RFC 4594 and RFC 7657, which are both Informational RFCs. The previous Last Call announcement did not call attention to this, as required by BCP 97. From nobody Tue Apr 19 01:47:04 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC0512E0D8; Tue, 19 Apr 2016 01:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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_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 s083o6D4L6op; Tue, 19 Apr 2016 01:46:58 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9427512DF4F; Tue, 19 Apr 2016 01:46:57 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-57-5715f07fa2af Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E6.DA.12926.F70F5175; Tue, 19 Apr 2016 10:46:55 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.248.2; Tue, 19 Apr 2016 10:46:54 +0200 To: "Black, David" , Cullen Jennings References: <20160321174750.31944.71903.idtracker@ietfa.amsl.com> <56F26AD3.3010403@ericsson.com> <5BB71158-3530-47A2-9A33-811F65B2F677@iii.ca> <56FBBBC1.5060902@ericsson.com> From: Magnus Westerlund Message-ID: <5715F07D.1050502@ericsson.com> Date: Tue, 19 Apr 2016 10:46:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM2J7oG79B9Fwgw2nlSy2Hl7LbvHnyj0W iw/rfzBaPNs4n8Wioe8uq8WxN3fZHNg8jhyZzeKxZMlPJo/L5z8yBjBHcdmkpOZklqUW6dsl cGVcvTGJpeCgUcWcB1PZGhgbNLoYOTkkBEwkWvbNYIKwxSQu3FvP1sXIxSEkcIRRYtHCRYwQ znJGic2r3jCBOMIC3YwSc850gbWICHhKbDw+nxnEFhJ4zSTxZV0+SBGzwClGiY5d88GK2AQs JG7+aGQDsXkFtCXWPXrGAmKzCKhKbFy7BcwWFYiRaHxwigmiRlDi5MwnYHFOAT+JHf1rWLsY OYCG2ks82FoGEmYWkJdo3jobaq+2RENTB+sERsFZSLpnIXTMQtKxgJF5FaNocWpxUm66kbFe alFmcnFxfp5eXmrJJkZgiB/c8lt1B+PlN46HGAU4GJV4eBUmioYLsSaWFVfmHmKU4GBWEuE9 +AYoxJuSWFmVWpQfX1Sak1p8iFGag0VJnDc78l+YkEB6YklqdmpqQWoRTJaJg1OqgTErfJdd YVP6r/P3Zj2cIGzxeqLFX1fbwsxZD+ddXDCv2OnIq8O6ixKrKn/d/PAhRmr9RzP5U1K9gfqC /CayO+Jiu08a5Dc4a+puPrD3lKHPpU6d7cx75yWzbni25du0mI9zSmqlA97ZhsSduV6dXCL4 zMyWW2mhULy6yd9eU5EPFy6tnDZ3+V8lluKMREMt5qLiRAAGxxHDbQIAAA== Archived-At: Cc: "tsvwg@ietf.org" , "draft-ietf-tsvwg-rtcweb-qos@ietf.org" , "ietf@ietf.org" , "tsvwg-chairs@ietf.org" Subject: Re: [tsvwg] Last Call: (DSCP and other packet markings for WebRTC QoS) to Proposed Standard X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 08:47:00 -0000 Den 2016-04-18 kl. 15:04, skrev Black, David: > So, summarizing Magnus's concerns with proposals: > >>> [1] Flow Type in application-facing browser API: > >>> Propose an additional sentence: >>> OLD >>> o Flow Type: The browser provides this input as it knows if the flow >>> is audio, interactive video with or without audio, non-interactive >>> video with or without audio, or data. >>> NEW >>> o Flow Type: The browser provides this input as it knows if the flow >>> is audio, interactive video with or without audio, non-interactive >>> video with or without audio, or data. For audio that is associated >>> with a video flow, the flow type of the associated video MAY >>> be used instead of the associated audio type. > > Magnus - does that new text suffice? Yes. > >>> [2] What does "interactive" mean in an implementation?: >> >> We could add something along lines of ..... Currently in WebRTC, media sent over >> RTP is assumed to be interactive while media streamed over HTTP is assumed not >> to be. Future WebRTC extensions could allow streamed media over RTP. > > I believe the proposed additional sentence addresses the question of how a browser > determines whether a video flow is interactive. This proposed sentence will need to > cite a WebRTC document that contains a statement to that effect, as I don't think this > draft is the right place to be the primary reference for that statement. > > Magnus - would this approach be ok? Yes. /Magnus > > Thanks, --David > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@iii.ca] >> Sent: Friday, April 15, 2016 10:48 AM >> To: Black, David >> Cc: Magnus Westerlund; ietf@ietf.org; tsvwg-chairs@ietf.org; draft-ietf-tsvwg- >> rtcweb-qos@ietf.org; tsvwg@ietf.org >> Subject: Re: [tsvwg] Last Call: (DSCP and >> other packet markings for WebRTC QoS) to Proposed Standard >> >> >>> On Apr 3, 2016, at 3:37 PM, Black, David wrote: >>> >>> I see a couple of Magnus's points that appear to need additional text >>> in the draft: >>> >>> [1] Flow Type in application-facing browser API: >>> >>>>>>>> o Flow Type: The browser provides this input as it knows if >>>>>>>> the flow is audio, interactive video with or without audio, >>>>>>>> non-interactive video with or without audio, or data. >>> >>> [... snip ...] >>> >>>> The main issue here is that to me it was not clear that "Interactive >>>> Video with or without audio" allows for setting these DSCP values also >>>> for the RTP stream containing audio also. This, I do see a need for >>>> clarification on. >>> >>> Propose an additional sentence: >>> OLD >>> o Flow Type: The browser provides this input as it knows if the flow >>> is audio, interactive video with or without audio, non-interactive >>> video with or without audio, or data. >>> NEW >>> o Flow Type: The browser provides this input as it knows if the flow >>> is audio, interactive video with or without audio, non-interactive >>> video with or without audio, or data. For audio that is associated >>> with a video flow, the flow type of the associated video MAY >>> be used instead of the associated audio type. >>> >>> I hesitate to say anything stronger than "MAY" here. >> >> Looks good. >> >>> >>> [2] What does "interactive" mean in an implementation?: >> >> We could add something along lines of ..... Currently in WebRTC, media sent over >> RTP is assumed to be interactive while media streamed over HTTP is assumed not >> to be. Future WebRTC extensions could allow streamed media over RTP. >> >> >>> >>>> The issue is that this document is called: DSCP and other packet >>>> markings for WebRTC QoS. Then this document define something that is not >>>> immediately mappable onto what is being defined in the other WebRTC >>>> specifications. That is why I am raising that there need to be more >>>> clear coupling. If that coupling is to mostly happen in another >>>> document, can we at least then have a proposal on the table for that >>>> change to ensure that the result is understandable. >>> >>> Well, this TSVWG draft is definitely not the right place for a discussion of >>> when a video flow is interactive or non-interactive - I hope we can agree >>> on that. >>> >>> Beyond that, as Cullen (Jennings) is both an author of this document and >>> one of the chairs of the rtcweb WG, I'd suggest that he and/or the rtcweb >>> WG propose an appropriate location for discussion of when a video flow >>> is interactive or non-interactive. This TSVWG draft would then have an >>> additional sentence added, e.g., >>> >>> See [TBD] for further discussion of how to determine >>> whether a video flow is interactive vs. non-interactive. >>> >>> I believe that the added reference here ([TBD] above) would be normative. >>> >>> Cullen? >> >> That discussion happened long ago for WebRTC and we decided we did not need >> a JavaScript controls point in the WebRTC API to indicate if RTP was interactive or >> not. If people start doing streaming video over RTP we can come back and revisit >> this and trivially add an API to indicate that in the W3C WebRTC API. Part of what >> drove this decision is the likes of Netflix / ITunes / Youtube are not asking the >> browser vendors for streaming media over RTSP or RTP. They think HTTP works >> much better for this. Thus the browser vendors see no need for non interactive >> video over RTP. I agree with Magnus that this might change some day in the >> future but right now, I think it's close enough that everyone can live with it. >> >> I'm not OK in treating it like some open issue that is still in discussion that >> somehow holds up this spec - it's not. >> >>> >>> Thanks, --David (as document shepherd) >>> > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Apr 19 15:37:27 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCA112E8FF for ; Tue, 19 Apr 2016 15:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.517 X-Spam-Level: X-Spam-Status: No, score=-115.517 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 EbktIY5fkanF for ; Tue, 19 Apr 2016 15:37:24 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3ED12E870 for ; Tue, 19 Apr 2016 15:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1589; q=dns/txt; s=iport; t=1461105444; x=1462315044; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IsA/VmXB8sifGLPsdJDapaWLcXY9NlY3YenVq91SSXM=; b=I3b6t0o2AKJeSjiLrU9N/a7XDdR3tYphysXFjGdtmuBxGtwnIlozXCpN kCjZi5Gaa0TtrpiFFlUYc8JC7tGSi0zM7wFBwG4ymt3sl0QwbWQ7T6V+t tpIEXXiALwOjHK2o9J4Fi0RrkrVi5TugUsy0F5qSe18VVLHgmKI/JBQmj g=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZBQD4sRZX/4MNJK1eDoMqgVAGt2GED?= =?us-ascii?q?oYOAoFLOxEBAQEBAQEBZRwLhEEBAQEDAXkFCwIBCBguMiUCBA4FDogTCL1tAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBDQiIFgiCTodqgisFmA4BgyeBZokEgVABFYROg?= =?us-ascii?q?ymFM48qATYsgy07bIgVfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,507,1454976000"; d="asc'?scan'208";a="93621267" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Apr 2016 22:37:23 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3JMbNSJ005854 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Apr 2016 22:37:23 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Apr 2016 17:37:22 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Tue, 19 Apr 2016 17:37:22 -0500 From: "Fred Baker (fred)" To: "gorry@erg.abdn.ac.uk" Thread-Topic: [tsvwg] TSVWG Agenda today Thread-Index: AQHRmowKCX1dR/V420SqZC5uYQ5R9A== Date: Tue, 19 Apr 2016 22:37:22 +0000 Message-ID: <74629695-E2A6-4C5B-AAC1-D1937A0DA19E@cisco.com> References: <6071f3219132d739701804efda25b820.squirrel@erg.abdn.ac.uk> In-Reply-To: <6071f3219132d739701804efda25b820.squirrel@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.119.50] Content-Type: multipart/signed; boundary="Apple-Mail=_D7F96F19-0F6A-43A7-816F-67C5849D8742"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] TSVWG Agenda today X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 22:37:26 -0000 --Apple-Mail=_D7F96F19-0F6A-43A7-816F-67C5849D8742 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 > On Apr 6, 2016, at 10:34 AM, gorry@erg.abdn.ac.uk wrote: > > 9.1 Tim Szigeti - Mapping to 802.11 (15 minutes) > draft-szigeti-tsvwg-ieee-802-11 > [Please read and comment on ID - WG Adoption requested] Tell me, if you would - what is the status of this? --Apple-Mail=_D7F96F19-0F6A-43A7-816F-67C5849D8742 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVxazIUayAOS/EQ8MAQJGsxAA1wvY7bc+Jzloafwkp+Bt9Oj+u32oxl5J BQDzNckcLfAyJCsq+hGBh3Cxm1kbQsTY8QGvjzUUSybMmQMJ0T1eAZbnVP2UTM3O zf9xhMbb+NZJBPyzlQVpMavk6z2ChgM9p3pV0XgB6wZTkWsswC+heRB7+pj9hD1L 0SGmOWPK9aM0L0nY6s8qsd7odzOnHPRDx0mUXXxO73a7JHPeFyZyvw3ARdIox0xK x1H+gon86YyzJuQexgN4c8Y+KNff2zocrm70z7twgD6zHSkVw+rl/6nJ3nm7zLyI IQ7F81jnP9JVluxCobWwEghpUct7WYUgj2hc0LfTC3HN7cWIcJriPbphKImzkH1o oMnIi+YKUg8YFoXQK6kboKwprY0WjYqKZpKoYou/SMHxvyX17/+j33Z1FcNTiYqj BZwU5z5za2TIKpL00vrQidZ4ObUvLM0FIKrP8nxGZ8Yf7fcagM0yCNcm05M+yKgl tC2GUlBfUZmOUSVzAmN9EOfQOakYIYsLaD5c95+1v29hSRDlBIDHqKKIS6muo7bK qR3k4daxyKwWR0QhgCmj7nzc8YlNImPmXbOYjAQXY+46HGOc26jjm1w2641XpOnb LdRQYiTdv2c4OOL7zldxt9qOROhhyRAQlu5M+EFWUHG1vL9vNUsVm5kszaF6zPIO 8zYLAL8moyY= =4Lzp -----END PGP SIGNATURE----- --Apple-Mail=_D7F96F19-0F6A-43A7-816F-67C5849D8742-- From nobody Tue Apr 19 16:29:57 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DABF712DB07; Tue, 19 Apr 2016 16:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.898 X-Spam-Level: X-Spam-Status: No, score=-107.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 FMLRBcevMJAW; Tue, 19 Apr 2016 16:29:45 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5FC12D62F; Tue, 19 Apr 2016 16:29:43 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id EB313180209; Tue, 19 Apr 2016 16:29:10 -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: <20160419232910.EB313180209@rfc-editor.org> Date: Tue, 19 Apr 2016 16:29:10 -0700 (PDT) Archived-At: Cc: tsvwg@ietf.org, rfc-editor@rfc-editor.org Subject: [tsvwg] RFC 7829 on SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 23:29:50 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7829 Title: SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol Author: Y. Nishida, P. Natarajan, A. Caro, P. Amer, K. Nielsen Status: Standards Track Stream: IETF Date: April 2016 Mailbox: nishida@wide.ad.jp, prenatar@cisco.com, acaro@bbn.com, amer@udel.edu, karen.nielsen@tieto.com Pages: 23 Characters: 53922 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tsvwg-sctp-failover-16.txt URL: https://www.rfc-editor.org/info/rfc7829 DOI: http://dx.doi.org/10.17487/RFC7829 The Stream Control Transmission Protocol (SCTP) supports multihoming. However, when the failover operation specified in RFC 4960 is followed, there can be significant delay and performance degradation in the data transfer path failover. This document specifies a quick failover algorithm and introduces the SCTP Potentially Failed (SCTP-PF) destination state in SCTP Path Management. This document also specifies a dormant state operation of SCTP that is required to be followed by an SCTP-PF implementation, but it may equally well be applied by a standard SCTP implementation, as described in RFC 4960. Additionally, this document introduces an alternative switchback operation mode called "Primary Path Switchover" that will be beneficial in certain situations. This mode of operation applies to both a standard SCTP implementation and an SCTP-PF implementation. The procedures defined in the document require only minimal modifications to the specification in RFC 4960. The procedures are sender-side only and do not impact the SCTP receiver. This document is a product of the Transport Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. 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 Thu Apr 28 15:47:54 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BE012D14C; Thu, 28 Apr 2016 15:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.898 X-Spam-Level: X-Spam-Status: No, score=-107.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 xzLzTFDsBLRT; Thu, 28 Apr 2016 15:47:50 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F69C12B038; Thu, 28 Apr 2016 15:47:50 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3DA85180004; Thu, 28 Apr 2016 15:47:33 -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: <20160428224733.3DA85180004@rfc-editor.org> Date: Thu, 28 Apr 2016 15:47:33 -0700 (PDT) Archived-At: Cc: tsvwg@ietf.org, rfc-editor@rfc-editor.org Subject: [tsvwg] BCP 127, RFC 7857 on Updates to Network Address Translation (NAT) Behavioral Requirements X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 22:47:52 -0000 A new Request for Comments is now available in online RFC libraries. BCP 127 RFC 7857 Title: Updates to Network Address Translation (NAT) Behavioral Requirements Author: R. Penno, S. Perreault, M. Boucadair, Ed., S. Sivakumar, K. Naito Status: Best Current Practice Stream: IETF Date: April 2016 Mailbox: repenno@cisco.com, sperreault@jive.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, k.naito@nttv6.jp Pages: 14 Characters: 29255 Updates: RFC 4787, RFC 5382, RFC 5508 See Also: BCP 127 I-D Tag: draft-ietf-tsvwg-behave-requirements-update-08.txt URL: https://www.rfc-editor.org/info/rfc7857 DOI: http://dx.doi.org/10.17487/RFC7857 This document clarifies and updates several requirements of RFCs 4787, 5382, and 5508 based on operational and development experience. The focus of this document is Network Address Translation from IPv4 to IPv4 (NAT44). This document updates RFCs 4787, 5382, and 5508. This document is a product of the Transport Area Working Group Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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