From nobody Tue Jul 1 00:01:08 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE7901B27C7 for ; Tue, 1 Jul 2014 00:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 pjsAgsAuulbt for ; Tue, 1 Jul 2014 00:01:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC4F1A0191 for ; Tue, 1 Jul 2014 00:01:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJL16359; Tue, 01 Jul 2014 07:01:03 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 1 Jul 2014 08:01:02 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 1 Jul 2014 15:00:51 +0800 From: "Huangyihong (Rachel)" To: "tsvwg@ietf.org" Thread-Topic: [tsvwg] FW: New Version Notification for draft-huang-tsvwg-tr-tcp-ps-00.txt Thread-Index: AQHPlPoxIVBzKChiKECjUAydeJHzlw== Date: Tue, 1 Jul 2014 07:00:51 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB861E853E@nkgeml501-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.144] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/lJ_97zaUhH9Cd9OzKTyU1iATUiQ Cc: Youjianjie Subject: [tsvwg] FW: New Version Notification for draft-huang-tsvwg-tr-tcp-ps-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 07:01:06 -0000 RGVhciBhbGwsDQoNCldlIGhhdmUganVzdCBzdWJtaXQgYSBuZXcgZHJhZnQgdGFsa2luZyBhYm91 dCBUQ1AgcHJvYmxlbXMuIFlvdSByZXZpZXcgYW5kIGNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC4N Cg0KQlIsDQpSYWNoZWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpT ZW50OiBUdWVzZGF5LCBKdWx5IDAxLCAyMDE0IDI6NTYgUE0NClRvOiBZb3VqaWFuamllOyBIdWFu Z3lpaG9uZyAoUmFjaGVsKTsgSHVhbmd5aWhvbmcgKFJhY2hlbCk7IFlvdWppYW5qaWUNClN1Ympl Y3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVhbmctdHN2d2ctdHItdGNw LXBzLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1odWFuZy10c3Z3Zy10 ci10Y3AtcHMtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJhY2hl bCBIdWFuZyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFm dC1odWFuZy10c3Z3Zy10ci10Y3AtcHMNClJldmlzaW9uOgkwMA0KVGl0bGU6CQlUcmFkaXRpb25h bCBUQ1AgUHJvYmxlbSBTdGF0ZW1lbnQNCkRvY3VtZW50IGRhdGU6CTIwMTQtMDctMDENCkdyb3Vw OgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTgNClVSTDogICAgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1odWFuZy10c3Z3Zy10ci10Y3At cHMtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaHVhbmctdHN2d2ctdHItdGNwLXBzLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1YW5nLXRzdndnLXRyLXRjcC1wcy0wMA0KDQoNCkFi c3RyYWN0Og0KICAgVGhpcyBkcmFmdCBkaXNjdXNzZXMgdGhlIHByb2JsZW0gc3RhdGVtZW50IGFu ZCBjb25zaWRlcmF0aW9uIGZvcg0KICAgZXhpc3RpbmcgVENQLg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVU RiBTZWNyZXRhcmlhdA0KDQo= From nobody Tue Jul 1 00:26:44 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3AB1A0190 for ; Tue, 1 Jul 2014 00:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.58 X-Spam-Level: X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=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 RYzvBDwbJutT for ; Tue, 1 Jul 2014 00:26:38 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 963A01A017D for ; Tue, 1 Jul 2014 00:26:38 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 1B18527815B for ; Tue, 1 Jul 2014 16:26:34 +0900 (JST) Received: by mail-la0-f43.google.com with SMTP id e16so5663918lan.30 for ; Tue, 01 Jul 2014 00:26:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.234.201 with SMTP id ug9mr357699lac.73.1404199592400; Tue, 01 Jul 2014 00:26:32 -0700 (PDT) Received: by 10.114.95.101 with HTTP; Tue, 1 Jul 2014 00:26:32 -0700 (PDT) In-Reply-To: <20140701053756.27711.5517.idtracker@ietfa.amsl.com> References: <20140701053756.27711.5517.idtracker@ietfa.amsl.com> Date: Tue, 1 Jul 2014 00:26:32 -0700 Message-ID: From: Yoshifumi Nishida To: tsvwg Content-Type: multipart/alternative; boundary=001a11349488e61b4004fd1cb16b Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/TjIeae9zrnq4C4P50XlQpGzrOZg Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-failover-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 07:26:40 -0000 --001a11349488e61b4004fd1cb16b Content-Type: text/plain; charset=UTF-8 Hi, We've submitted a new version of SCTP quick failover draft. We've added some changes in order to reflect the previous comments we've received. The main parts of changes are the followings. 1: Restructuring of some sections We've moved some sections that are not directly related to the spec for quick failover (related works, some discussions for side effects) to Appendix 2: Clarifying the logics for quick failover with standards recommendations We've added explicit recommendations in the behavior of quick failover (Section 4) 3: Updating abstract to provide clearer view of the document If you have any questions, comments or suggestions, please let us know. Regards, -- Yoshi On Mon, Jun 30, 2014 at 10:37 PM, wrote: > > 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 Working Group of the IETF. > > Title : Quick Failover Algorithm in SCTP > Authors : Yoshifumi Nishida > Preethi Natarajan > Armando Caro > Paul D. Amer > Karen E. E. Nielsen > Filename : draft-ietf-tsvwg-sctp-failover-04.txt > Pages : 17 > Date : 2014-06-30 > > Abstract: > One of the major advantages of SCTP is that it supports multi-homed > communication. A multi-homed SCTP end-point has the ability to > withstand network failures by migrating the traffic from an inactive > network to an active one. However, if the [RFC4960] specified > failover operation is followed there can be a significant delay in > the migration to the active destination addresses, thus severely > reducing the effectiveness of SCTP multi-homed operation. > > The memo complements RFC4960 by the introduction of the Potentially > Failed state and associated new Quick Failover operation to apply > during network failure and specifies for SCTP senders to support this > more performance optimal failover procedure as an add-on to the > [RFC4960] failover operation. The memo in addition updates [RFC4960] > by clarifying a number of issues related to the path management > operation during periods of partial or complete network failures. > Finally the memo complements [RFC4960] by introduction of alternative > switchover operation modes for the data transfer path management > after a failover. These operation modes offer for more performance > optimal operation in some network environments. From the perspective > of this memo the implementation of the additional switchover > operation modes is considered optional. > > The procedures defined require only minimal modifications to the > current specification. The procedures are sender-side only and do > not impact the SCTP receiver. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-failover/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-failover-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-failover-04 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --001a11349488e61b4004fd1cb16b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
We've submitted a new version of SCTP quick fai= lover draft.
We've added some changes in order to reflect the previo= us comments we've received. The main parts of changes are the following= s.

1: Restructuring of some sections
=C2=A0 =C2=A0 We've moved some= sections that are not directly related to the spec for quick failover (rel= ated works, some discussions for side effects) to Appendix
2: Clarifying= the logics for quick failover with standards recommendations
=C2=A0 =C2=A0 We've added explicit recommendations in the behavior of q= uick failover (Section 4)
3: Updating abstract to provide clearer view = of the document

If you have any questions, comment= s or suggestions, please let us know.

Regards,
--
Yoshi

On Mon, Ju= n 30, 2014 at 10:37 PM, =C2=A0<internet-drafts@ietf.org> wrote:
>
> A New Internet-D= raft is available from the on-line Internet-Drafts directories.
> =C2=A0This draft is a work item of the Transport Area Working Group Wo= rking Group of the IETF.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Quick Failover Algorithm in SCTP
&g= t; =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Yoshif= umi Nishida
> =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 Preethi Natarajan
> =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 Armando Caro=
> =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 Paul D. Amer
> =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 Karen E. E. = Nielsen
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 = =C2=A0: draft-ietf-tsvwg-sctp-failover-04.txt
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 17
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: 2014-06-30
>
> Abstract:
> =C2=A0 =C2=A0On= e of the major advantages of SCTP is that it supports multi-homed
> = =C2=A0 =C2=A0communication. =C2=A0A multi-homed SCTP end-point has the abil= ity to
> =C2=A0 =C2=A0withstand network failures by migrating the traffic from = an inactive
> =C2=A0 =C2=A0network to an active one. =C2=A0However, i= f the [RFC4960] specified
> =C2=A0 =C2=A0failover operation is follow= ed there can be a significant delay in
> =C2=A0 =C2=A0the migration to the active destination addresses, thus s= everely
> =C2=A0 =C2=A0reducing the effectiveness of SCTP multi-homed= operation.
>
> =C2=A0 =C2=A0The memo complements RFC4960 by th= e introduction of the Potentially
> =C2=A0 =C2=A0Failed state and associated new Quick Failover operation = to apply
> =C2=A0 =C2=A0during network failure and specifies for SCTP= senders to support this
> =C2=A0 =C2=A0more performance optimal fail= over procedure as an add-on to the
> =C2=A0 =C2=A0[RFC4960] failover operation. =C2=A0The memo in addition = updates [RFC4960]
> =C2=A0 =C2=A0by clarifying a number of issues rel= ated to the path management
> =C2=A0 =C2=A0operation during periods o= f partial or complete network failures.
> =C2=A0 =C2=A0Finally the memo complements [RFC4960] by introduction of= alternative
> =C2=A0 =C2=A0switchover operation modes for the data t= ransfer path management
> =C2=A0 =C2=A0after a failover. =C2=A0These = operation modes offer for more performance
> =C2=A0 =C2=A0optimal operation in some network environments. =C2=A0Fro= m the perspective
> =C2=A0 =C2=A0of this memo the implementation of t= he additional switchover
> =C2=A0 =C2=A0operation modes is considered= optional.
>
> =C2=A0 =C2=A0The procedures defined require only= minimal modifications to the
> =C2=A0 =C2=A0current specification. =C2=A0The procedures are sender-si= de only and do
> =C2=A0 =C2=A0not impact the SCTP receiver.
>>
> The IETF datatracker status page for this draft is:
> = https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-failover/
>
> There's also a htmlized version available at:
> http:/= /tools.ietf.org/html/draft-ietf-tsvwg-sctp-failover-04
>
> = A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-sctp-failove= r-04
>
>
> Please note that it may take a couple of m= inutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are al= so available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-An= nounce mailing list
> I-D-An= nounce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
--001a11349488e61b4004fd1cb16b-- From nobody Tue Jul 1 12:26:33 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BAC1B28BD; Tue, 1 Jul 2014 12:26:30 -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] autolearn=ham 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 rdw3VZjoIiXG; Tue, 1 Jul 2014 12:26:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABED1A061D; Tue, 1 Jul 2014 12:26:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140701192628.19439.61287.idtracker@ietfa.amsl.com> Date: Tue, 01 Jul 2014 12:26:28 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/kcMTaKVDiQZfhoz9biPRvokE8-4 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 19:26:30 -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 Working Group of the IETF. Title : Generic UDP Encapsulation for IP Tunneling Authors : Edward Crabbe Lucy Yong Xiaohu Xu Filename : draft-ietf-tsvwg-gre-in-udp-encap-02.txt Pages : 13 Date : 2014-07-01 Abstract: This document describes a method of encapsulating arbitrary protocols within GRE and UDP headers. In this encapsulation, the source UDP port may be used as an entropy field for purposes of load balancing while the payload protocol may be identified by the GRE Protocol Type. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-gre-in-udp-encap-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 2 06:33:13 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1C21A00B6 for ; Wed, 2 Jul 2014 06:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 c9lpBvNTaB40 for ; Wed, 2 Jul 2014 06:33:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2951A00AD for ; Wed, 2 Jul 2014 06:33:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGS35395; Wed, 02 Jul 2014 13:33:07 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 2 Jul 2014 14:32:58 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.95]) by dfweml704-chm.china.huawei.com ([169.254.6.218]) with mapi id 14.03.0158.001; Wed, 2 Jul 2014 06:32:47 -0700 From: Lucy yong To: "tsvwg@ietf.org" Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-02.txt Thread-Index: AQHPlWJ7q8xjrI3RKEixGHP1joxOBpuMyBSA Date: Wed, 2 Jul 2014 13:32:47 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453B0EFA@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.131.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/CgOLbvhEqT6oeFHsVBxt6P1zewg Subject: [tsvwg] FW: I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 13:33:12 -0000 SGVsbG8sDQoNClRoZSBuZXcgdmVyc2lvbiBpcyB1cGxvYWRlZC4gSXQgYWRkcmVzc2VzIHRoZSBj b21tZW50cyBpbiBMb25kb24ncyBtZWV0aW5nLCBpLmUuIGNvbmdlc3Rpb24gY29udHJvbCwgY2hl Y2tzdW0sIGV0Yy4gUGxlYXNlIGxldCB1cyBrbm93IGlmIHRoZSBkZXNjcmlwdGlvbiBpcyBzdWZm aWNpZW50IGluIHRoaXMgdmVyc2lvbi4gT3RoZXIgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNClRo YW5rcywNCkx1Y3kNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHRzdndnIFtt YWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZw0KU2VudDogVHVlc2RheSwgSnVseSAwMSwgMjAxNCAyOjI2IFBNDQpUbzogaS1k LWFubm91bmNlQGlldGYub3JnDQpDYzogdHN2d2dAaWV0Zi5vcmcNClN1YmplY3Q6IFt0c3Z3Z10g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10c3Z3Zy1ncmUtaW4tdWRwLWVuY2FwLTAyLnR4dA0KDQoN CkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVy bmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRo ZSBUcmFuc3BvcnQgQXJlYSBXb3JraW5nIEdyb3VwIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYu DQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogR2VuZXJpYyBVRFAgRW5jYXBzdWxhdGlvbiBm b3IgSVAgVHVubmVsaW5nDQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IEVkd2FyZCBDcmFiYmUN CiAgICAgICAgICAgICAgICAgICAgICAgICAgTHVjeSBZb25nDQogICAgICAgICAgICAgICAgICAg ICAgICAgIFhpYW9odSBYdQ0KCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtdHN2d2ctZ3Jl LWluLXVkcC1lbmNhcC0wMi50eHQNCglQYWdlcyAgICAgICAgICAgOiAxMw0KCURhdGUgICAgICAg ICAgICA6IDIwMTQtMDctMDENCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJl cyBhIG1ldGhvZCBvZiBlbmNhcHN1bGF0aW5nIGFyYml0cmFyeQ0KICAgcHJvdG9jb2xzIHdpdGhp biBHUkUgYW5kIFVEUCBoZWFkZXJzLiAgSW4gdGhpcyBlbmNhcHN1bGF0aW9uLCB0aGUNCiAgIHNv dXJjZSBVRFAgcG9ydCBtYXkgYmUgdXNlZCBhcyBhbiBlbnRyb3B5IGZpZWxkIGZvciBwdXJwb3Nl cyBvZiBsb2FkDQogICBiYWxhbmNpbmcgd2hpbGUgdGhlIHBheWxvYWQgcHJvdG9jb2wgbWF5IGJl IGlkZW50aWZpZWQgYnkgdGhlIEdSRQ0KICAgUHJvdG9jb2wgVHlwZS4NCg0KDQpUaGUgSUVURiBk YXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHN2d2ctZ3JlLWluLXVkcC1lbmNhcC8NCg0K VGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQpodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRzdndnLWdyZS1pbi11ZHAtZW5jYXAtMDINCg0K QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cDov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10c3Z3Zy1ncmUtaW4tdWRwLWVu Y2FwLTAyDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpJbnRlcm5ldC1E cmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQo= From nobody Wed Jul 2 14:55:26 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E443C1B2AD8 for ; Wed, 2 Jul 2014 14:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham 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 sNJVF67ZDu_X for ; Wed, 2 Jul 2014 14:55:17 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 199A21B2AD9 for ; Wed, 2 Jul 2014 14:55:15 -0700 (PDT) Received: from [192.168.1.200] (p508F356D.dip0.t-ipconnect.de [80.143.53.109]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id EA5041C0E97AF; Wed, 2 Jul 2014 23:55:10 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <53A97D04.6050909@erg.abdn.ac.uk> Date: Wed, 2 Jul 2014 23:55:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53A97D04.6050909@erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/ApRqnawS4F-_suesSoGRZZZ9fGQ Cc: draft-ietf-tsvwg-sctp-dtls-encaps@tools.ietf.org, tsvwg WG Subject: Re: [tsvwg] WGLC Follow-Up: draft-ietf-tsvwg-sctp-dtls-encaps X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 21:55:21 -0000 On 24 Jun 2014, at 15:28, Gorry Fairhurst wrote: > The WGLC for the above document ended 28th February 2014, and = follow-up discussions resulted in a revised draft. >=20 > I am now starting to prepare for submission of the above document for = requested publication. Please find detailed comments/questions about the = text below. Thank you very much for your comments. See my answers in-line. Best regards Michael >=20 > Best wishes, >=20 > Gorry Fairhurst. > (TSVWG Co-Chair) >=20 > --- > ABSTRACT: > "Using > encapsulation method described in this document, SCTP is..." > ^ > - insert /the/ ? Done. >=20 >=20 > --- > ABSTRACT: > "As a consequence, the SCTP associations are single homed." > - This final statement is not clear, although true. Please add text to = explain to the reader why this is needed in the abstract. Could you say = something that follows this below, and also explain why in section 6.1? Not sure why the conclusion is not clear. How would you setup a = multihomed SCTP association without using IP addresses in control chunks = (INIT/INIT-ACK/ASCONF)? > "The security properties of this encapsulation limit usage to = single-homed SCTP associations." > --- > Section 5: > "a safe value for the path MTU has to be used by the SCTP stack." > - How do you choose? - please specify a default or a method. The data channel document specifies 1280 for IPv6 and 1200 for IPv4. The IPv4 values was chosen based on experience by some WG members. I can put the numbers in this document, if you want. > --- > Section 5: > "Differentiated services code point (DSCP) " > - reference needed. I added a reference to RFC 2474. > --- > Section 5: > "explicit congestion notifications (ECN)" > - reference needed. Added a reference to RFC 3168. > --- > Section 5: > "SCTP performs segmentation and reassembly based on the path MTU. > Therefore the DTLS layer MUST NOT use any compression algorithm. >=20 > The DTLS MUST support sending messages larger than the current path > MTU. This might result in sending IP level fragmented messages." > - I wonder if some reordering of paras within teh section could > gather all the size-related topics in one part of the section? Makes sense. I moved them up. > --- > Section 6: > - I am surprised this section does not mention how to handle > any path changes, should PMTUD be triggered following known changes, > for instance? Does this affect the SCTP CC state? The data channel document contains: The ICE/UDP layer can handle IP address changes during a session without = needing interaction with the DTLS and SCTP layers. However, SCTP SHOULD be notified when an address changes has happened. In this case SCTP SHOULD retest the Path MTU and reset the congestion state to the initial state. In case of a window based congestion control like the one specified in , this means setting the congestion window and slow start threshold to its initial values. So I added a bullet: If the SCTP is notified about a path change by its lower layers, SCTP SHOULD retest the Path MTU and reset the congestion state to the initial state. In case of a window based congestion control like the = one specified in , this means setting the = congestion window and slow start threshold to its initial values. Does this address your issue? > --- > Section 6.1: > /doesn't deal/does not deal/ > - please change. Done. > --- > Section 6.1: > "All SCTP associations are single-homed." > Could you add something like: > ", because DTLS does not expose any address > management to its upper layer." Done. > --- > Section 6.2: > "The padding extension defined in [RFC4820] MUST be supported and = used > for probe packets when performing path MTU discovery as specified in > [RFC4821]." > - Is this section relevant when DTLS implements PMTUD, please explain? I added "by the SCTP layer". > --- > References: > A later version (-10) exists ofdraft-ietf-rtcweb-overview-09 > A later version (-10) exists of draft-ietf-rtcweb-data-channel-08 They will be updated when submitting a new revision. > --- > The requirement to use SCTP/DTLS appears to also be cited in = draft-ietf-rtcweb-overview-09, section 5.5, which requires normative use = of SCTP/DTLS, but this document is not cited in the current document, I = think it should be, if not why not? It is cited as the first ID in = http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-04#section-10= .2 >=20 >=20 >=20 >=20 >=20 From nobody Wed Jul 2 22:51:21 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE42D1A0AEF for ; Wed, 2 Jul 2014 22:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.852 X-Spam-Level: X-Spam-Status: No, score=-112.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_BEEF=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 FW-lLO2f3LUH for ; Wed, 2 Jul 2014 22:51:03 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B29111A0A94 for ; Wed, 2 Jul 2014 22:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8318; q=dns/txt; s=iport; t=1404366655; x=1405576255; h=from:to:cc:subject:date:message-id:references: mime-version; bh=mVKbQBzxlLziG1FTFfJz7UWkw9PzxJ6FQmXTMFcvqfk=; b=ke1CtocvF1CwZBgZfaEUGKPPd9HJ80J1c7/3TIvBr3jH/vwObIil11BU P3gZ2Me8tW+Mcv1+XlJIuj71c9YNbvZymX0I/S4W9VrcPttrmMbYFduEl 9pUKwRTY6MGxO/L9xWx+/UHXnF0qI6n+MrUn5MBD2UfjrIhrplx0w8cLf 8=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAN7utFOtJA2I/2dsb2JhbABagw1SWr5jh0GBCRZ1hAMBAQEDAQEBAWgDAgQFBQsCARkBAgECAS4nCxcEAggCBAoEBQ6ILAgNxzEXjxERDYMngRYFkhyBQ4J2hBiBSJJCg0NsgUQ X-IronPort-AV: E=Sophos;i="5.01,593,1400025600"; d="asc'?scan'208";a="57908065" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP; 03 Jul 2014 05:50:54 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s635osba015691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jul 2014 05:50:54 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Thu, 3 Jul 2014 00:50:54 -0500 From: "Fred Baker (fred)" To: "tsvwg@ietf.org" Thread-Topic: [OPS-DIR] Early Ops-Dir review for rtcweb-qos draft Thread-Index: AQHPlhRff7CzC69nrky4tjPHpHxziA== Date: Thu, 3 Jul 2014 05:50:53 +0000 Message-ID: <696AF7FE-4E14-4825-8B81-0EC5FB752342@cisco.com> References: <4AAB478A-442A-4A01-84D5-2B21EE63C7D4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.113.202] Content-Type: multipart/signed; boundary="Apple-Mail=_F8611C35-0CD3-484E-A39C-244E11E9DCEA"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/TNN_XPGzAn5MJY92z5Rh67dyAXM Subject: [tsvwg] Fwd: [OPS-DIR] Early Ops-Dir review for rtcweb-qos draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 05:51:09 -0000 --Apple-Mail=_F8611C35-0CD3-484E-A39C-244E11E9DCEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 David Black asked me to forward my Ops Directorate =93early review=94 of = draft-ietf-tsvwg-rtcweb-qos to the list. As an additional comment, reflecting on comments in other quarters = (dart), it may be worthwhile pointing out in the draft that the DSCP = indicates a minimum acceptable service level; if a network thinks it can = achieve that service level within some larger scheme (such as a traffic = class described in Ruediger=92s draft, RFC 5127, or simply by = oversupplying bandwidth), that is at the operator=92s discretion. Begin forwarded message: > From: "Fred Baker (fred)" > Subject: Re: [OPS-DIR] Early Ops-Dir review for rtcweb-qos draft > Date: July 2, 2014 at 11:07:43 AM PDT > To: "Benoit Claise (bclaise)" , "ops-dir@ietf.org" = > Cc: "tsv-ads@tools.ietf.org" , = "tsvwg-chairs@tools.ietf.org" , = "draft-ietf-tsvwg-rtcweb-qos.all@tools.ietf.org" = >=20 >=20 > On Jul 2, 2014, at 9:40 AM, Benoit Claise wrote: >=20 >> Hi David, >>=20 >> Fred Baker accepted to review this document for the early Ops-DIR >> Thanks Fred. >> Gunter, can you please mark it as such in the in OPS DIR review tool. >>=20 >> Regards, Benoit >>=20 >>> Greetings, >>>=20 >>> On behalf of the tsvwg WG, I'd like to request an early OPS-Dir = review of draft-ietf-tsvwg-rtcweb-qos from a network operations = perspective: >>>=20 >>> http://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/ >>>=20 >>> Although I'm an OPS-Dir member, I'm looking for a review from = someone w/actual network operations expertise, which I freely admit is = not me ;-). The concern that motivates this review is that this draft = recommends use of a significant number of Diffserv DSCPs in Section 5: >>>=20 >>> = http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-02#section-5 >>>=20 >>> I have input from one large network operator (DT) that this is well = off (by a factor of 2 or more) from the number of DSCPs that are (and = are likely to be) supported on their network (and other similar = networks) for non-internal (e.g., subscriber/customer) traffic, and = hence much of the differentiation is likely to vanish on ingress to such = a network, if not before. >>>=20 >>> Input from someone else familiar with the QoS aspects of network = operations would be rather helpful at this stage. >>>=20 >>> Thanks, >>> =97David >=20 > In fairness, I=92m not an operator either. To directly answer David's = question, you need an operator to respond. >=20 > I am, however, one of the authors of RFC 4594, which this note quotes, = and RFC 5127, which addresses aggregation of those classes in high speed = networks.=20 >=20 > https://tools.ietf.org/html/rfc4594 > 4594 Configuration Guidelines for DiffServ Service Classes. J. > Babiarz, K. Chan, F. Baker. August 2006. (Format: TXT=3D144044 = bytes) > (Updated by RFC5865) (Status: INFORMATIONAL) >=20 > https://tools.ietf.org/html/rfc5127 > 5127 Aggregation of Diffserv Service Classes. K. Chan, J. Babiarz, F. > Baker. February 2008. (Format: TXT=3D43751 bytes) (Status: > INFORMATIONAL) >=20 > The heart of the document is section 5, in which it makes specific = DSCP recommendations. Were I to try to implement it, I think I would = find it confusing and difficult. Color me pedantic, but let me give you = the questions that flow through my head as I read it. >=20 > An important statement made here is: >=20 >> = +---------------------------+-------+------+------------+-----------+ >> | Data Type | Very | Low | Medium | High = | >> | | Low | | | = | >> = +---------------------------+-------+------+------------+-----------+ >> | Audio | CS1 | BE | EF (46) | EF (46) = | >> | | (8) | (0) | | = | >> >> = +---------------------------+-------+------+------------+-----------+ >>=20 >> Table 1 >>=20 >> The columns "very low", "low", "Medium" and "high" are the priority >> levels. The browser SHOULD first select the data type of the = media >> flow. Within the data type, the priority of the media flow SHOULD = be >> selected. All packets within a media flow SHOULD have the same >> priority. [snip] >=20 > RFC 4594 has no corollary concept of =93priority=94 of the data = traffic. It focuses on the type of application and that application=92s = requirements; if it needs to minimize network-induced jitter, it might = recommend using a priority scheduler, transferring jitter from EF to = other traffic classes, and if it targets TCP traffic, it might recommend = the use of AQM technologies. For it, the question is not the relative = importance of the session to the user or some other outside observer, = but the technology required to deliver the QoS services that the = application requires. By comparison, RFC 5865 does discuss precedence = classes for sessions; in that case, the question is a service policy = that might admit a new session to the network if it is deemed = =93important=94 via some authenticated authorization process when it = would not admit a new session from just anyone. So I struggle to = determine how the browser would decide whether a given session was =93very= low=94, =93low=94, =93medium=94, or =93high=94 priority, and what the = concept of =93priority=94 means in the context. >=20 > I also struggle to understand the meaning of the reference to =93BE=94. = I presume it means =93Best Effort=94. RFC 4594 does not describe a =93Best= Effort=94 DSCP or traffic class; it does describe =93Default=94, which = I think this is referring to. Similarly, definitions of the = Differentiated Services architecture (I haven=92t checked all of the 272 = specifications that include the text string =93Differentiated Services=94,= but I have reviewed the documents from RFC 2474 through 2999) make no = such reference. =93Best Effort=94 is a term describing a characteristic = of any datagram network service; packets in flight may be dropped, = duplicated, or reordered, as compared with services that enforce = in-order and in some cases reliable delivery. I would prefer to see the = appropriate traffic class, which I think might be =93Default=94, used in = this document. >=20 > The document also makes a statement that I think is unnecessary: >=20 > The above table assumes that packets marked with CS1 is treated as > "less than best effort". However, the treatment of CS1 is > implementation dependent. If an implementation treats CS1 as other > than "less than best effort", then the priority of the packets may = be > changed from what is intended. >=20 > With respect, the treatment of every traffic class is = implementation-dependent, and every mark is fungible. The document = should describe how traffic should be marked, and what traffic so marked = expects from the network. The network will then do whatever it thinks is = appropriate to satisfy that requirement. >=20 > I would not recommend the adoption or publication of the draft in its = present form. > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir --Apple-Mail=_F8611C35-0CD3-484E-A39C-244E11E9DCEA 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 iD8DBQFTtO89bjEdbHIsm0MRAiqSAKCsYbHXRLWDrtjMn6j64udCfxOgmgCg5F7f BzpXMElBpAjSBjVw8n+qVQo= =POdg -----END PGP SIGNATURE----- --Apple-Mail=_F8611C35-0CD3-484E-A39C-244E11E9DCEA-- From nobody Thu Jul 3 01:45:55 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A1D1A0AAE; Thu, 3 Jul 2014 01:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 ewEas3bqkg7A; Thu, 3 Jul 2014 01:45:48 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6873B1A03E9; Thu, 3 Jul 2014 01:45:48 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id B96572B44A6; Thu, 3 Jul 2014 09:45:47 +0100 (BST) Received: from ra-gorry.erg.abdn.ac.uk (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id D80342B40E1; Thu, 3 Jul 2014 09:45:46 +0100 (BST) Message-ID: <53B5183A.7060301@erg.abdn.ac.uk> Date: Thu, 03 Jul 2014 09:45:46 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tsvwg-chairs@ietf.org, tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/Ty7Y9Qk4vPI_U6jHDTmKbJPXqp0 Subject: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-prpolicies-03 - due to conclude Monday, July 21st, 2014 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 03 Jul 2014 08:45:50 -0000 This is the start of the WGLC on "Additional Policies for the Partial Reliability Extension of the Stream Control Transmission Protocol" for publication intended as a PS. https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-prpolicies/ This WGLC will last until Monday, July 21st, 2014 (longer since this includes time prior to an IETF meeting). Could people please send *any* comments to the list if they think this is ready to publish? A good note is "I have read this version of the draft, and I approve (or support) its progression to RFC". James/Gorry/David TSVWG chairs From nobody Thu Jul 3 02:37:39 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A10F1B27FA for ; Thu, 3 Jul 2014 02:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 X8AD3dUlf1d8 for ; Thu, 3 Jul 2014 02:37:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5F9C1A0AB1 for ; Thu, 3 Jul 2014 02:37:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJN54751; Thu, 03 Jul 2014 09:37:34 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 3 Jul 2014 10:37:34 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.117]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Thu, 3 Jul 2014 17:37:29 +0800 From: Weixinpeng To: "tsvwg@ietf.org" Thread-Topic: draft-wei-tsvwg-tunnel-congestion-feedback-02 Thread-Index: Ac+Womb2VUiiDB+6T/KhLo/6jyD90Q== Date: Thu, 3 Jul 2014 09:37:29 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.176] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46D81AA01nkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/BONqvW82DPpqe_XN98GxX6ppa6M Subject: [tsvwg] draft-wei-tsvwg-tunnel-congestion-feedback-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 09:37:38 -0000 --_000_C5C3BB522B1DDF478AA09545169155B46D81AA01nkgeml507mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, A new version of draft-wei-tsvwg-tunnel-congestion-feedback-02 is submitted= . Comments are welcomed! Thanks. Best Regards, -Xinpeng Name: draft-wei-tsvwg-tunnel-congestion-feedback Revision: 02 Title: Tunnel Congestion Feedback Document date: 2014-07-03 Group: Individual Submission Pages: 18 URL: http://www.ietf.org/internet-drafts/draft-wei-tsvwg-tunnel-= congestion-feedback-02.txt Status: https://datatracker.ietf.org/doc/draft-wei-tsvwg-tunnel-con= gestion-feedback/ Htmlized: http://tools.ietf.org/html/draft-wei-tsvwg-tunnel-congestio= n-feedback-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-wei-tsvwg-tunnel-c= ongestion-feedback-02 Abstract: This document describes a mechanism to calculate congestion of a tunnel segment based on RFC 6040 recommendations, and a feedback protocol by which to send the measured congestion of the tunnel from egress to ingress router. A basic model for measuring tunnel congestion and feedback is described, and a protocol for carrying the feedback data is outlined. --_000_C5C3BB522B1DDF478AA09545169155B46D81AA01nkgeml507mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

A new version of draft-wei-t= svwg-tunnel-congestion-feedback-02 is submitted.

Comments are welcomed!<= /o:p>

Thanks.

 

Best Regards,

-Xinpeng

 

 

Name:    = ;           draft-wei-tsv= wg-tunnel-congestion-feedback

Revision:  02

Title:   &nbs= p;            &= nbsp; Tunnel Congestion Feedback

Document date:  &n= bsp;    2014-07-03

Group:   &nbs= p;           Individual S= ubmission

Pages:   &nbs= p;           18

URL:    =         http://www.ietf.org/internet-drafts/draft-wei-tsvwg-tunnel-congestion-feedb= ack-02.txt

Status:   &nb= sp;     https://datatracker.ietf.org/doc/draft-wei-tsvwg-tunnel-congestion-feedback= /

Htmlized:   &= nbsp;   http://tools.ietf.org/html/draft-wei-tsvwg-tunnel-congestion-feedback-02

Diff:    = ;       http://www.ietf.org/rfcdiff?url2=3Ddraft-wei-tsvwg-tunnel-congestion-feedba= ck-02

 

Abstract:<= /p>

   This document d= escribes a mechanism to calculate congestion of a

   tunnel segment = based on RFC 6040 recommendations, and a feedback

   protocol by whi= ch to send the measured congestion of the tunnel from

   egress to ingre= ss router. A basic  model for measuring tunnel

   congestion and = feedback is described, and a protocol for carrying the

   feedback data i= s outlined.

 

--_000_C5C3BB522B1DDF478AA09545169155B46D81AA01nkgeml507mbxchi_-- From nobody Thu Jul 3 06:01:49 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A531B2965 for ; Thu, 3 Jul 2014 06:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 1UTJ2Jhme0yh for ; Thu, 3 Jul 2014 06:01:33 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id D5ADD1B2990 for ; Thu, 3 Jul 2014 06:01:02 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 1BD572B40E1 for ; Thu, 3 Jul 2014 14:01:02 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 3 Jul 2014 14:01:02 +0100 Message-ID: Date: Thu, 3 Jul 2014 14:01:02 +0100 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/vXPHlixVrgDrqlhsQiAcGKlFU0k Subject: [tsvwg] TSVWG - Request for Agenda Items for Toronto meetings X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 13:01:37 -0000 Hi tsvwg'ers, This is a request for people to offer presentations on drafts to be presented to the tsvwg working group at the Toronto IETF. I've upload a very initial agenda here: http://www.ietf.org/proceedings/90/agenda/agenda-90-tsvwg Many of the talks are marked TBC (editors please confirm). We do have space to discuss additional drafts. Please send all requests and any corrections to the chairs asap. Gorry, David and James (tsvwg co-chairs) From nobody Thu Jul 3 13:26:47 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21541B28B1 for ; Thu, 3 Jul 2014 13:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 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, MANGLED_BEEF=2.3, SPF_PASS=-0.001] autolearn=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 JxUv5EEPkztA for ; Thu, 3 Jul 2014 13:26:29 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C681B289A for ; Thu, 3 Jul 2014 13:26:25 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id rd3so778889pab.32 for ; Thu, 03 Jul 2014 13:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3T34hwUC+kKwGpl65UZwMJhX7p1ZgTLeP2OT2Zj0Wnc=; b=r0Ox1DvEmgejwFhfFITw7lNKxN3VMl0pDkqpkqLx6HRh0dknfPKRssMr118SY40Hr5 wD+iphyvscNp2UBBbjSmlORdfdCPYlayKUL/uM970d744m6hrFX9ZgHUL3SbSb7SY3c4 TaMnGUpZyb4Q9495xCLWCulbq4yFE99vWh82ok2OgJ8cozb6NrwmsyDNy8drr0fjZOXa rFGYxw0+bIz5seivFd12c9DVo/y6PDpByZEiYkLnfwERiTCIMHyWG4jPFJJOG72F1I9O aeDQB7Zw1Xn5b8MtrTU3KYiuMYT03116+278uGQQj162QLtaBTi8/7KRiO+QFl/F2eT0 6eLw== X-Received: by 10.68.237.67 with SMTP id va3mr6809502pbc.19.1404419184842; Thu, 03 Jul 2014 13:26:24 -0700 (PDT) Received: from [192.168.178.23] (98.197.69.111.dynamic.snap.net.nz. [111.69.197.98]) by mx.google.com with ESMTPSA id ek2sm41945205pbd.30.2014.07.03.13.26.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 13:26:24 -0700 (PDT) Message-ID: <53B5BC78.4060409@gmail.com> Date: Fri, 04 Jul 2014 08:26:32 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <4AAB478A-442A-4A01-84D5-2B21EE63C7D4@cisco.com> <696AF7FE-4E14-4825-8B81-0EC5FB752342@cisco.com> In-Reply-To: <696AF7FE-4E14-4825-8B81-0EC5FB752342@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/PFy24dzyojmevgB-ycPtGArLAwc Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Fwd: [OPS-DIR] Early Ops-Dir review for rtcweb-qos draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 20:26:32 -0000 Hi Fred, I agree with your review. Just two remarks inserted below: On 03/07/2014 17:50, Fred Baker (fred) wrote: > David Black asked me to forward my Ops Directorate =E2=80=9Cearly revie= w=E2=80=9D of draft-ietf-tsvwg-rtcweb-qos to the list. >=20 > As an additional comment, reflecting on comments in other quarters (dar= t), it may be worthwhile pointing out in the draft that the DSCP indicate= s a minimum acceptable service level; if a network thinks it can achieve = that service level within some larger scheme (such as a traffic class des= cribed in Ruediger=E2=80=99s draft, RFC 5127, or simply by oversupplying = bandwidth), that is at the operator=E2=80=99s discretion. Yes. However, EF is a little bit strange in that respect, as I understand= the formal definition. EF is supposed to provide a configured maximum capacity, and traffic that exceeds that capacity is presumed to be dropped. So the excess traffic, at least in theory, gets the worst treatment of all, and the capacity in excess of that configured for EF is left free for non-EF traffic. That is a bit counter-intuitive for people who think of EF as the "best" class. > Begin forwarded message: >=20 >> From: "Fred Baker (fred)" >> Subject: Re: [OPS-DIR] Early Ops-Dir review for rtcweb-qos draft >> Date: July 2, 2014 at 11:07:43 AM PDT >> To: "Benoit Claise (bclaise)" , "ops-dir@ietf.org" = >> Cc: "tsv-ads@tools.ietf.org" , "tsvwg-chairs@t= ools.ietf.org" , "draft-ietf-tsvwg-rtcweb-qo= s.all@tools.ietf.org" >> >> >> On Jul 2, 2014, at 9:40 AM, Benoit Claise wrote: >> >>> Hi David, >>> >>> Fred Baker accepted to review this document for the early Ops-DIR >>> Thanks Fred. >>> Gunter, can you please mark it as such in the in OPS DIR review tool.= >>> >>> Regards, Benoit >>> >>>> Greetings, >>>> >>>> On behalf of the tsvwg WG, I'd like to request an early OPS-Dir revi= ew of draft-ietf-tsvwg-rtcweb-qos from a network operations perspective: >>>> >>>> http://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/ >>>> >>>> Although I'm an OPS-Dir member, I'm looking for a review from someon= e w/actual network operations expertise, which I freely admit is not me ;= -). The concern that motivates this review is that this draft recommends= use of a significant number of Diffserv DSCPs in Section 5: >>>> >>>> http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-02#section-5= >>>> >>>> I have input from one large network operator (DT) that this is well = off (by a factor of 2 or more) from the number of DSCPs that are (and are= likely to be) supported on their network (and other similar networks) fo= r non-internal (e.g., subscriber/customer) traffic, and hence much of the= differentiation is likely to vanish on ingress to such a network, if not= before. >>>> >>>> Input from someone else familiar with the QoS aspects of network ope= rations would be rather helpful at this stage. >>>> >>>> Thanks, >>>> =E2=80=94David >> In fairness, I=E2=80=99m not an operator either. To directly answer Da= vid's question, you need an operator to respond. >> >> I am, however, one of the authors of RFC 4594, which this note quotes,= and RFC 5127, which addresses aggregation of those classes in high speed= networks.=20 >> >> https://tools.ietf.org/html/rfc4594 >> 4594 Configuration Guidelines for DiffServ Service Classes. J. >> Babiarz, K. Chan, F. Baker. August 2006. (Format: TXT=3D144044 byt= es) >> (Updated by RFC5865) (Status: INFORMATIONAL) >> >> https://tools.ietf.org/html/rfc5127 >> 5127 Aggregation of Diffserv Service Classes. K. Chan, J. Babiarz, F. >> Baker. February 2008. (Format: TXT=3D43751 bytes) (Status: >> INFORMATIONAL) >> >> The heart of the document is section 5, in which it makes specific DSC= P recommendations. Were I to try to implement it, I think I would find it= confusing and difficult. Color me pedantic, but let me give you the ques= tions that flow through my head as I read it. >> >> An important statement made here is: >> >>> +---------------------------+-------+------+------------+----------= -+ >>> | Data Type | Very | Low | Medium | High = | >>> | | Low | | | = | >>> +---------------------------+-------+------+------------+----------= -+ >>> | Audio | CS1 | BE | EF (46) | EF (46) = | >>> | | (8) | (0) | | = | >>> >>> +---------------------------+-------+------+------------+----------= -+ >>> >>> Table 1 >>> >>> The columns "very low", "low", "Medium" and "high" are the priority= >>> levels. The browser SHOULD first select the data type of the medi= a >>> flow. Within the data type, the priority of the media flow SHOULD = be >>> selected. All packets within a media flow SHOULD have the same >>> priority. [snip] >> RFC 4594 has no corollary concept of =E2=80=9Cpriority=E2=80=9D of the= data traffic. It focuses on the type of application and that application= =E2=80=99s requirements; if it needs to minimize network-induced jitter, = it might recommend using a priority scheduler, transferring jitter from E= F to other traffic classes, and if it targets TCP traffic, it might recom= mend the use of AQM technologies. For it, the question is not the relativ= e importance of the session to the user or some other outside observer, b= ut the technology required to deliver the QoS services that the applicati= on requires. By comparison, RFC 5865 does discuss precedence classes for = sessions; in that case, the question is a service policy that might admit= a new session to the network if it is deemed =E2=80=9Cimportant=E2=80=9D= via some authenticated authorization process when it would not admit a n= ew session from just anyone. So I struggle to determine how the browser w= ould decide whether a given session was =E2=80=9Cvery low=E2=80=9D, =E2=80= =9Clow=E2=80=9D, =E2=80=9C medium=E2=80=9D, or =E2=80=9Chigh=E2=80=9D priority, and what the concept= of =E2=80=9Cpriority=E2=80=9D means in the context. >> >> I also struggle to understand the meaning of the reference to =E2=80=9C= BE=E2=80=9D. I presume it means =E2=80=9CBest Effort=E2=80=9D. RFC 4594 d= oes not describe a =E2=80=9CBest Effort=E2=80=9D DSCP or traffic class; i= t does describe =E2=80=9CDefault=E2=80=9D, which I think this is referrin= g to. Similarly, definitions of the Differentiated Services architecture = (I haven=E2=80=99t checked all of the 272 specifications that include the= text string =E2=80=9CDifferentiated Services=E2=80=9D, but I have review= ed the documents from RFC 2474 through 2999) make no such reference. =E2=80= =9CBest Effort=E2=80=9D is a term describing a characteristic of any data= gram network service; packets in flight may be dropped, duplicated, or re= ordered, as compared with services that enforce in-order and in some case= s reliable delivery. I would prefer to see the appropriate traffic class,= which I think might be =E2=80=9CDefault=E2=80=9D, used in this document.= >> >> The document also makes a statement that I think is unnecessary: >> >> The above table assumes that packets marked with CS1 is treated as >> "less than best effort". However, the treatment of CS1 is >> implementation dependent. If an implementation treats CS1 as other >> than "less than best effort", then the priority of the packets may b= e >> changed from what is intended. >> >> With respect, the treatment of every traffic class is implementation-d= ependent, and every mark is fungible. The document should describe how tr= affic should be marked, and what traffic so marked expects from the netwo= rk. The network will then do whatever it thinks is appropriate to satisfy= that requirement. Yes. And specifically, diffserv carefully avoids the primitive idea of "priority", because that implies simple preemption, which is not how diffserv works. The text about CS1 presumably intends to refer to RFC 3662 (A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services) which is only Informational, but at least gives a complete description of a specific behaviour called LE, not LBE. Brian >> I would not recommend the adoption or publication of the draft in its = present form. >> _______________________________________________ >> OPS-DIR mailing list >> OPS-DIR@ietf.org >> https://www.ietf.org/mailman/listinfo/ops-dir >=20 From nobody Thu Jul 3 18:34:10 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9031A0240 for ; Thu, 3 Jul 2014 18:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 bxGGJGzmw0y6 for ; Thu, 3 Jul 2014 18:34:07 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [142.59.210.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 304491A0235 for ; Thu, 3 Jul 2014 18:34:06 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s641Y5B1003703 for ; Thu, 3 Jul 2014 19:34:05 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s641Y52p013545 for ; Thu, 3 Jul 2014 19:34:05 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id s641Y437013544 for tsvwg@ietf.org; Thu, 3 Jul 2014 19:34:04 -0600 Date: Thu, 3 Jul 2014 19:34:04 -0600 From: "Brian F. G. Bidulock" To: tsvwg@ietf.org Message-ID: <20140704013404.GB11240@openss7.org> Mail-Followup-To: tsvwg@ietf.org References: <53B5183A.7060301@erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53B5183A.7060301@erg.abdn.ac.uk> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/Mhc7C2BWFk2WmXqxY1taRL-TiPo Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-prpolicies-03 - due to conclude Monday, July 21st, 2014 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 01:34:09 -0000 Gorry, Please see comments below: Gorry Fairhurst wrote: (Thu, 03 Jul 2014 09:45:46) > This is the start of the WGLC on "Additional Policies for the Partial > Reliability Extension of the Stream Control Transmission Protocol" for > publication intended as a PS. > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-prpolicies/ > > This WGLC will last until Monday, July 21st, 2014 (longer since this > includes time prior to an IETF meeting). > > Could people please send *any* comments to the list if they think this > is ready to publish? > > A good note is "I have read this version of the draft, > and I approve (or support) its progression to RFC". > > James/Gorry/David > TSVWG chairs I have read this version of the draft; however, I have some comments: It appears that the document only has about 3 (or 4) normative paragraphs. Of those three (or 4) paragraphs the key word "REQUIRED" is used once with reference to RFC3758; the key word "MUST" is used once with regard to abandoning a user message that would exceed a retransmission limit. There are two "MAY" and one "OPTIONAL" key words. The rest of the document is informational. I question the sole "MUST" in section 3.1. The most I think it should be is a "SHOULD" and it should probably just be a "MAY". Other considerations could go into whether to abandon or simply postpone a retransmission that achieve the same effect. Perhaps what is attempted here is to say that "after a message has reached its retransmission limit, the sender SHOULD NOT retransmit the message again at the exclusion of resources to other messages available for transmission or retransmission." I do not see why you would want to abandon retransmissions of messages on otherwise idle associations: it would unnecessarily lower the reliability of the association. Also, when the sender is to abandon the message, it should likely only be on the event of a timer-based retransmission request. A sender can get all kinds of spurious fast-retransmission requests resulting in the discard of an excessive number of messages under the current policy. In fact, abandoning messages _in_itself_ is likely to cause additional spurious gap reports and fast-retransmission. However, abandoning on a timer-based retransmission would make the policy hardly distinguishable on the wire from the existing lifetimes-based PR policy. In summary, it seems to me that the document simply asks us to implement some loose definition of a sender-side only API that does not describe anything that "is required for interoperation or to limit the behavior which has potential for causing harm" as required by RFC 2119. It seems to abuse the only normative MUST in the document applied to a sender-side procedure that appears to not to have been given much careful consideration. The entire document appears more focused on the INFORMATIONAL section 4 than on the NORMATIVE section 3. As such, I object to it being published as a PS. I would support the draft being published as an INFORMATIONAL RFC if the procedure described in section 3.1 is properly revised. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From nobody Thu Jul 3 18:37:49 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3BF1A045D for ; Thu, 3 Jul 2014 18:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 c80GLLBvqZ6P for ; Thu, 3 Jul 2014 18:37:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B5261A0652 for ; Thu, 3 Jul 2014 18:37:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJP57417; Fri, 04 Jul 2014 01:37:24 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Jul 2014 02:37:23 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 4 Jul 2014 09:37:19 +0800 From: "Huangyihong (Rachel)" To: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] TSVWG - Request for Agenda Items for Toronto meetings Thread-Index: AQHPlr8C/3zugp/z0EeJH2BTC37NRJuPIxOA Date: Fri, 4 Jul 2014 01:37:18 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB861E96E0@nkgeml501-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.144] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/-eu-DgHeviC0ltCh4ZJlJN_Jfj0 Subject: Re: [tsvwg] TSVWG - Request for Agenda Items for Toronto meetings X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 01:37:35 -0000 Hi Chairs, I'd like to request a slot for my draft http://www.ietf.org/internet-drafts= /draft-huang-tsvwg-tr-tcp-ps-00.txt. 10 minutes would be fine. Thank you so= much. BR, Rachel > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of > gorry@erg.abdn.ac.uk > Sent: Thursday, July 03, 2014 9:01 PM > To: tsvwg@ietf.org > Subject: [tsvwg] TSVWG - Request for Agenda Items for Toronto meetings >=20 >=20 > Hi tsvwg'ers, >=20 > This is a request for people to offer presentations on drafts to be prese= nted to > the tsvwg working group at the Toronto IETF. >=20 > I've upload a very initial agenda here: > http://www.ietf.org/proceedings/90/agenda/agenda-90-tsvwg >=20 > Many of the talks are marked TBC (editors please confirm). We do have spa= ce > to discuss additional drafts. >=20 > Please send all requests and any corrections to the chairs asap. >=20 > Gorry, David and James > (tsvwg co-chairs) >=20 From nobody Fri Jul 4 01:50:04 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA7B1A0396 for ; Fri, 4 Jul 2014 01:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 5rKGbafb_l3w for ; Fri, 4 Jul 2014 01:49:59 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id E27141B2C8C for ; Fri, 4 Jul 2014 01:49:58 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id AF70E2B44A6; Fri, 4 Jul 2014 09:49:57 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Fri, 4 Jul 2014 09:49:57 +0100 Message-ID: In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB861E96E0@nkgeml501-mbs.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB861E96E0@nkgeml501-mbs.china.huawei.com> Date: Fri, 4 Jul 2014 09:49:57 +0100 From: gorry@erg.abdn.ac.uk To: "Huangyihong (Rachel)" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/SdDI7JiaynfFMATnAYnddVtAVlI Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" Subject: Re: [tsvwg] TSVWG - Request for Agenda Items for Toronto meetings X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 08:50:00 -0000 Thanks for submitting this draft. This may be an interesting topic, however, we don't normally present initial drafts until there has been discussion at a WG meeting or on the list. It is best to start by asking the list comments on the mailing list. If you haven't already done so - you should probably post a note separately to the TAPS group and ask them for feedback on the proposed topics. I'll consult my co-chairs about the Agenda, and note your interest in presenting. Gorry > Hi Chairs, > > I'd like to request a slot for my draft > http://www.ietf.org/internet-drafts/draft-huang-tsvwg-tr-tcp-ps-00.txt. 10 > minutes would be fine. Thank you so much. > > BR, > Rachel > >> -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of >> gorry@erg.abdn.ac.uk >> Sent: Thursday, July 03, 2014 9:01 PM >> To: tsvwg@ietf.org >> Subject: [tsvwg] TSVWG - Request for Agenda Items for Toronto meetings >> >> >> Hi tsvwg'ers, >> >> This is a request for people to offer presentations on drafts to be >> presented to >> the tsvwg working group at the Toronto IETF. >> >> I've upload a very initial agenda here: >> http://www.ietf.org/proceedings/90/agenda/agenda-90-tsvwg >> >> Many of the talks are marked TBC (editors please confirm). We do have >> space >> to discuss additional drafts. >> >> Please send all requests and any corrections to the chairs asap. >> >> Gorry, David and James >> (tsvwg co-chairs) >> > From nobody Fri Jul 4 02:10:19 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BA51A030A for ; Fri, 4 Jul 2014 02:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 4oWvje9yD1Lg for ; Fri, 4 Jul 2014 02:10:15 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 567D21A02F1 for ; Fri, 4 Jul 2014 02:10:14 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s649A7ro026679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Jul 2014 04:10:08 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s649A6D2014776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 11:10:06 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.218]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 4 Jul 2014 11:10:06 +0200 From: "Scharf, Michael (Michael)" To: "Huangyihong (Rachel)" Thread-Topic: [tsvwg] TSVWG - Request for Agenda Items for Toronto meetings Thread-Index: AQHPlr7+3pzYLknMG0aJTinZClKqmJuPAfYAgAB44YCAACVVsA== Date: Fri, 4 Jul 2014 09:10:06 +0000 Message-ID: <655C07320163294895BBADA28372AF5D165BEE49@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB861E96E0@nkgeml501-mbs.china.huawei.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/S8NTyQQKM-1DRk-TTvC7RzypQ54 Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" Subject: Re: [tsvwg] TSVWG - Request for Agenda Items for Toronto meetings X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 09:10:17 -0000 If the intention of this document is to discuss a modification of TCP param= eters, the TCPM mailing list might also be an appropriate place to get feed= back (albeit most contributors to TCPM also follow TSVWG). I'd recommend to have a look at RFC 6077 first. Michael > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of > gorry@erg.abdn.ac.uk > Sent: Friday, July 04, 2014 10:50 AM > To: Huangyihong (Rachel) > Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org > Subject: Re: [tsvwg] TSVWG - Request for Agenda Items for Toronto > meetings >=20 > Thanks for submitting this draft. >=20 > This may be an interesting topic, however, we don't normally present > initial drafts until there has been discussion at a WG meeting or on > the > list. >=20 > It is best to start by asking the list comments on the mailing list. If > you haven't already done so - you should probably post a note > separately > to the TAPS group and ask them for feedback on the proposed topics. >=20 > I'll consult my co-chairs about the Agenda, and note your interest in > presenting. >=20 > Gorry >=20 > > Hi Chairs, > > > > I'd like to request a slot for my draft > > http://www.ietf.org/internet-drafts/draft-huang-tsvwg-tr-tcp-ps- > 00.txt. 10 > > minutes would be fine. Thank you so much. > > > > BR, > > Rachel > > > >> -----Original Message----- > >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of > >> gorry@erg.abdn.ac.uk > >> Sent: Thursday, July 03, 2014 9:01 PM > >> To: tsvwg@ietf.org > >> Subject: [tsvwg] TSVWG - Request for Agenda Items for Toronto > meetings > >> > >> > >> Hi tsvwg'ers, > >> > >> This is a request for people to offer presentations on drafts to be > >> presented to > >> the tsvwg working group at the Toronto IETF. > >> > >> I've upload a very initial agenda here: > >> http://www.ietf.org/proceedings/90/agenda/agenda-90-tsvwg > >> > >> Many of the talks are marked TBC (editors please confirm). We do > have > >> space > >> to discuss additional drafts. > >> > >> Please send all requests and any corrections to the chairs asap. > >> > >> Gorry, David and James > >> (tsvwg co-chairs) > >> > > >=20 From nobody Fri Jul 4 02:35:59 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F3B1B27BF for ; Fri, 4 Jul 2014 02:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 uBNk7j8ZNA-Y for ; Fri, 4 Jul 2014 02:35:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE011A0ABF for ; Fri, 4 Jul 2014 02:35:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJP92363; Fri, 04 Jul 2014 09:35:53 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Jul 2014 10:35:47 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.117]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 4 Jul 2014 17:35:43 +0800 From: Weixinpeng To: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] TSVWG - Request for Agenda Items for Toronto meetings Thread-Index: AQHPlr8BpYwW5l7F5kKKeMFBrf7i8ZuPqBig Date: Fri, 4 Jul 2014 09:35:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/_GAu9WZqG-z1mwbWw4t5gn4dNPw Subject: Re: [tsvwg] TSVWG - Request for Agenda Items for Toronto meetings X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 09:35:57 -0000 Hi gorry, I would like to apply a 10min time slot for a presentation of http://tools.= ietf.org/html/draft-wei-tsvwg-tunnel-congestion-feedback-02, since the last meeting we have finished a simulation work for congestion fe= edback mechanism and would like to present it. Thanks. Best Regards, Xinpeng >-----Original Message----- >From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of >gorry@erg.abdn.ac.uk >Sent: Thursday, July 03, 2014 9:01 PM >To: tsvwg@ietf.org >Subject: [tsvwg] TSVWG - Request for Agenda Items for Toronto meetings > > >Hi tsvwg'ers, > >This is a request for people to offer presentations on drafts to be presen= ted to >the tsvwg working group at the Toronto IETF. > >I've upload a very initial agenda here: >http://www.ietf.org/proceedings/90/agenda/agenda-90-tsvwg > >Many of the talks are marked TBC (editors please confirm). We do have spac= e >to discuss additional drafts. > >Please send all requests and any corrections to the chairs asap. > >Gorry, David and James >(tsvwg co-chairs) > From nobody Fri Jul 4 04:41:53 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3438C1B2D24 for ; Fri, 4 Jul 2014 04:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 7tYNpd9CJfYY for ; Fri, 4 Jul 2014 04:41:48 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD8C1B2D15 for ; Fri, 4 Jul 2014 04:41:47 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 04 Jul 2014 13:41:44 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 4 Jul 2014 13:41:43 +0200 From: To: , , Date: Fri, 4 Jul 2014 13:41:42 +0200 Thread-Topic: New Version Notification for draft-geib-tsvwg-diffserv-intercon-06.txt Thread-Index: Ac+Xe2i6+aWQnYTBS46/ag48bQ/wZwAAAftw Message-ID: 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: http://mailarchive.ietf.org/arch/msg/tsvwg/McGY-1fUJQiPX1RCx4qIVgWWVEo Cc: tsvwg@ietf.org, fred@cisco.com Subject: [tsvwg] WG: New Version Notification for draft-geib-tsvwg-diffserv-intercon-06.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 11:41:51 -0000 RGVhciBUU1YgV0csDQoNCmFmdGVyIGEgZGlzY3Vzc2lvbiB3aXRoIEZyZWQgQmFrZXIgYW5kIERh dmlkIEJsYWNrLCBJJ3ZlIHJldmlzZWQgbXkgZHJhZnQuIEkndmUgY2xhcmlmaWVkIHRoYXQgaXQg c3VwcG9ydHMgYSAxOjEgRFNDUCBtYXBwaW5nIGF0IGludGVyY29ubmVjdGlvbiBwb2ludHMgYW5k IHRoYXQgYW4gbjoxIERTQ1AgbWFwcGluZyBpcyBub3Qgc3VwcG9ydGVkLiBGdXJ0aGVyIGl0IGdv ZXMgaW50byBtb3JlIGRldGFpbHMgb24gbGltaXRhdGlvbnMgb24gRFNDUCBtYXBwaW5ncyByZXN1 bHRpbmcgZnJvbSBNUExTIGRlcGxveW1lbnQgKGluIHBhcnRpY3VsYXIgU2hvcnQgUGlwZSBNUExT IG1vZGVsIGZvciBub24gdHVubmVsZWQgSVB2NCB0cmFmZmljKS4NCg0KRGlzY3Vzc2lvbiB3aXRo IEZyZWQgYW5kIERhdmlkIGlzIG9uZ29pbmcsIHBsZWFzZSBkb24ndCBpbnRlcnByZXQgdGhlIGFi b3ZlIGFzICdoYXZpbmcgcmVhY2hlZCBjb25zZW50Jy4gDQoNClJlZ2FyZHMsDQoNClJ1ZWRpZ2Vy DQoNCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KVm9uOiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KR2VzZW5k ZXQ6IEZyZWl0YWcsIDQuIEp1bGkgMjAxNCAxMzozMQ0KQW46IEdlaWIsIFLDvGRpZ2VyOyBHZWli LCBSw7xkaWdlcg0KQmV0cmVmZjogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1n ZWliLXRzdndnLWRpZmZzZXJ2LWludGVyY29uLTA2LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC1nZWliLXRzdndnLWRpZmZzZXJ2LWludGVyY29uLTA2LnR4dA0KaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSdWVkaWdlciBHZWliIGFuZCBwb3N0ZWQgdG8gdGhl IElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWdlaWItdHN2d2ctZGlmZnNlcnYtaW50 ZXJjb24NClJldmlzaW9uOgkwNg0KVGl0bGU6CQlEaWZmU2VydiBpbnRlcmNvbm5lY3Rpb24gY2xh c3NlcyBhbmQgcHJhY3RpY2UNCkRvY3VtZW50IGRhdGU6CTIwMTQtMDctMDQNCkdyb3VwOgkJSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTE2DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZ2VpYi10c3Z3Zy1kaWZmc2Vydi1pbnRl cmNvbi0wNi50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1nZWliLXRzdndnLWRpZmZzZXJ2LWludGVyY29uLw0KSHRtbGl6ZWQ6ICAgICAg IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdlaWItdHN2d2ctZGlmZnNlcnYtaW50 ZXJjb24tMDYNCkRpZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1nZWliLXRzdndnLWRpZmZzZXJ2LWludGVyY29uLTA2DQoNCkFic3RyYWN0Og0KICAg VGhpcyBkb2N1bWVudCBwcm9wb3NlcyBhIGxpbWl0ZWQgYW5kIHdlbGwgZGVmaW5lZCBzZXQgb2Yg UW9TIFBIQnMgYW5kDQogICBQSEIgZ3JvdXBzIHRvIGJlIGFwcGxpZWQgYXQgKGludGVyKWNvbm5l Y3Rpb25zIG9mIHR3byBzZXBhcmF0ZWx5DQogICBhZG1pbmlzdGVyZWQgYW5kIG9wZXJhdGVkIG5l dHdvcmtzLiAgTWFueSBuZXR3b3JrIHByb3ZpZGVycyBvcGVyYXRlDQogICBUcmVhdG1lbnQgQWdn cmVnYXRlIG9mIGRpZmZlcmVudCBEaWZmU2VydiBjbGFzc2VzLiAgVGhpcyBkcmFmdCBvZmZlcnMN CiAgIGEgc2ltcGxlIGFuZCBjb25zdHJhaW5lZCBpbnRlcmNvbm5lY3Rpb24gY29uY2VwdCB3aGlj aCBtYXkgc2ltcGxpZnkNCiAgIG9wZXJhdGlvbiBhbmQgbmVnb3RpYXRpb24gb2YgRGlmZlNlcnYg YXQgaW50ZXJjb25uZWN0aW9uIHBvaW50cy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K DQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJp YXQNCg0K From nobody Fri Jul 4 10:55:17 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EAF1B27F7; Fri, 4 Jul 2014 10:55: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] autolearn=ham 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 QMbeSD2b4NN5; Fri, 4 Jul 2014 10:55:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E40C01B27D5; Fri, 4 Jul 2014 10:55:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704175507.27060.46688.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 10:55:07 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/LM31XfTiXvQufivher6N3v0-tsA Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 17:55:13 -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 Working Group of the IETF. Title : DTLS Encapsulation of SCTP Packets Authors : Michael Tuexen Randall R. Stewart Randell Jesup Salvatore Loreto Filename : draft-ietf-tsvwg-sctp-dtls-encaps-05.txt Pages : 8 Date : 2014-07-04 Abstract: The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocols IPv4 or IPv6. This document specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol. Using the encapsulation method described in this document, SCTP is agnostic about the protocols being used below DTLS, explicit IP addresses can not be used in the SCTP control chunks. As a consequence, the SCTP associations are single homed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-dtls-encaps/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-dtls-encaps-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 Fri Jul 4 12:54:38 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D85E1B2A73; Fri, 4 Jul 2014 12:54:23 -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] autolearn=ham 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 YHBgnyL0Sf-h; Fri, 4 Jul 2014 12:54:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D2B1B2BB0; Fri, 4 Jul 2014 12:54:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704195410.13052.95168.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 12:54:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/lqOdAJmIpk97vyqte4rt7k-hGwc Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-app-id-vv-profiles-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 19:54: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 Working Group of the IETF. Title : Resource Reservation Protocol (RSVP) Application-ID Profiles for Voice and Video Streams Authors : James Polk Subha Dhesikan Filename : draft-ietf-tsvwg-rsvp-app-id-vv-profiles-02.txt Pages : 15 Date : 2014-07-04 Abstract: RFC 2872 defines an Resource Reservation Protocol (RSVP) object for application identifiers. This document uses that App-ID and gives implementers specific guidelines for differing voice and video stream identifications to nodes along a reservation path, creating specific profiles for voice and video session identification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-app-id-vv-profiles/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-app-id-vv-profiles-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rsvp-app-id-vv-profiles-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 13:42:23 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183691B2F80 for ; Fri, 4 Jul 2014 13:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham 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 4KK62LPYG3JI for ; Fri, 4 Jul 2014 13:42:19 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C0B1B2854 for ; Fri, 4 Jul 2014 13:42:19 -0700 (PDT) Received: from [192.168.1.200] (p508F0AD6.dip0.t-ipconnect.de [80.143.10.214]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id B15181C0B4620; Fri, 4 Jul 2014 22:42:16 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <6de6099c3bd0543b17cfa5da84d327ad@mail.gmail.com> Date: Fri, 4 Jul 2014 22:42:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <79B46DEE-529C-4326-8F98-64575C2A880B@lurchi.franken.de> References: <6de6099c3bd0543b17cfa5da84d327ad@mail.gmail.com> To: "Karen E. Egede Nielsen" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/WXZPo4wt5oTJl-rjNw0sqn0WRxM Cc: Randall Stewart , tsvwg@ietf.org Subject: Re: [tsvwg] draft-stewart-tsvwg-sctp-ndata-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 20:42:22 -0000 On 05 Nov 2013, at 00:51, Karen E. Egede Nielsen = wrote: > Hi, > =20 > Please accept the folowing comments to = draft-stewart-tsvwg-sctp-ndata-03.txt. > Please use as fit. Hi Karen, thank you very much for your comments. I'm sorry for not responding = earlier... See my comments in-line. Best regards Michael > =20 > General comments: > ----------------------- > =20 > The draft draft-stewart-tsvwg-sctp-ndata-03.txt, in my opinion, = addresses an important limitation of SCTP message fragmentation The > limitation is important to have removed in order to support large = message transfer by SCTP without detroying concurrent transmission of > data with real-time characteristics. > =20 > The advanced stream scheduling modes, suggested in the draft, also = seems very instrumental in order to instantiate different real time = characteristics on > different streams. > =20 > Title: Given the scheduling aspects included in the draft, one should = consider to adjust the title so that it better accommodate for the = scheduling parts. Actually stream scheduling seems to be main topic of = the draft with the new (or extended) data chunk format just a mean to = support more flexible (interleaved) scheduling of fragments. The is correct. > =20 > Something else: The =93N=94 as =93New=94 in N-DATA seems not so = future-proof. Perhaps E for word =93Extended=94 (E-DATA) would be a = better naming ? Possibly. But we are using N-DATA in several places... Will think about = it. > =20 > It should be clarified in the Introduction that the draft makes use of = the Supported Extension Parameter as defined in RFC5061. Make sense. Done. > =20 > Detailed Comments: > --------------------------- > =20 > Section 1.1: > 1. It should be clarified that the draft defines a new data = chunk option as well as that it defines an advanced stream scheduler = function and that these are independent functions. Correct. I agree. > 2. It could be clarified that the intention is for the new data = chunk to be used for all data transmitted on a particular association = (i.e., not only fragments). Done. > 3. It could be clarified that the usage of the new data chunk = will differentiable on a per association basis and that an SCTP = implementation as such shall support coexistence of associations which = use the existing data chunk format and associations which use the new = data chunk format. Sure. Done. > =20 > Section 3.1: > 1. In the third paragraph that starts with =93Sender side = usage.. =94, it should be clarified that the new data chunk is used for = all data chunks and not for only data chunks that need fragmentation. Fixed. > 2. The situation, when the peer does not support N-DATA but the = user request it, should preferably be elaborated on in this section or = somewhere else in the draft. Presumably then in this situation the SCTP = layer simply uses the legacy data chunk with its in-build limitations. = However this should be described. Fixed. > 3. Information should preferably be provided to UL about whether = peer supports usage of N-DATA. For a socket api compliant implementation = such information could possibly be provided in an extension of = SCTP_STATUS ? I would prefer to signal it in the SCTP_ASSOC_CHANGE indicating = SCTP_COMM_UP or SCTP_RESTART by using SCTP_SUPPORTS_INTERLEAVING similar to SCTP_ASSOC_SUPPORTS_PR, = SCTP_ASSOC_SUPPORTS_AUTH, ... However, this goes into the socket API section. >=20 > Section 4.1 =96 minor/editorial: > =20 > 1. The text could be clarified so that it more clearly refers to = =93one-to-many=94 and to=20 > =93one-to-one=94 sockets. The text could also better describe the = behaviour of the socket option on each type. Could you be more specific where information is missing? > 2. The second paragraph sentence: =93An N-DATA chunk aware = application should also set the fragment interleave level to 2=94 =96 = should refer to appropriate option of RFC6458. > =20 > Section 4.1 =96 substance: > =20 > 1. I would like to press for that the ability to change the = N-DATA setting on current (established) associations is removed. It = looks to open up for a number of complexities both in SCTP layer as well = as in O&M layer; E.g., if N-DATA feature is disabled, what about = retransmissions where original was send as N-DATA. When the O&M = operation is made, then how to control when it takes effect in the SCTP = layer in respect to data already in SND buffer. Further the disabling = only effectively can control the sending side. These details would have = to be described in draft and, secondly, implemented, both of which could = be somewhat of a challenge. Are there some important use-cases that = demands for this =93flexibility=94 ? This functionality isn't there. I agree completely with you. Isn't the = text in 4.1.1 on SCTP_NDATA_ENABLE clear on this? > 2. I believe that one NEED to have the possibility, on a per = association basis, to read whether the peer supports N-DATA or not. This = regardless of whether it be an association belonging Isn't the notification good enough? You can't query ASCONF support, = Stream Reset, and so on. This is currently only done via the notification. I'm open to discuss a = generic method... > to a one-to-many socket or a one-to-one socket. Support for read via = socket api should be described in the draft. This may be provided via an = extension of SCTP_STATUS (?). Optionally one may also prescribe for such = information to be returned as part of an extension of RFC3873, = sctpAssocTable object. Let's talk about MIB stuff in general in a separate document. We are = lacking MIB support for all SCTP extensions. If there is a real need in this, we should think = about updating the MIB RFC. Years ago, when I implemented it for FreeBSD, I had a bunch of = comments. > 3. Situation with association restart on SCTP level should = preferably be described. You get a new notification... > =20 > Section 4.1.2: > =20 > =20 > 1. Would it be reasonable to specify a subset of the listed = scheduling options as something that an implementation that support = N-DATA MUST support and others as MAY or optional. Alternatively one = may specify that at least one of the options need to be supported ? I would just look which constants are defined... We can make a statement = that not all implementation support all. > 2. The SCTP_SS_FAIR_BANDWIDTH could be demanding from an = implementation perspective. As will be the SCTP_SS_WEIGHTED_FAIR_QUEUEING... > 3. It should be clarified that these scheduling options are = applicable for sending normal DATA chunks also when peer does not = support usage of N-DATA. Yepp. I'll work on this while polishing/testing the implementation.. >=20 > =20 > Possible addition to the draft content: (?) > =20 > Possibly one could contemplate to include improvement of the receiver = side operation also. As follows: > =20 > =B7 The SCTP receive operation could be extended to allow for = specification of read stream scheduling - possibly options =96 to start = with (RS: Read Scheduling): > o SCTP_RS_FIRST_COME: The simple first-come, first-serve algorithm > is selected by using this value. It just queues messages that are = readable in the order in which they have been received by the SCTP = layer. > o SCTP_RS_PRIORITY: SCTP operates with a number of receive queues = per association according to a number of priorities set. For each = priority queue simple first-come, first-serve algorithm is used .I.e., = for each priority queue messages are queued as readable in the order in = which they have been received by the SCTP layer .The priority can be = assigned on a per stream basis. Value 0 is default priority, higher = values are higher priority (or lower), lower values are lower priority = (or higher). > Select, poll (BSD) and epoll (Linux) mechanism must be extended to = support specification, and notification, of receiving readable event on = a per priority RCV queue basis. As we discussed, I think this could go into a separate document... >=20 > =20 > Editorial: > =20 > Abstract: which which =E0 which > Section 2: FSN's are unsigned number =E0 FSN's are unsigned numbers Fixed. > =20 > BR, Karen From nobody Fri Jul 4 13:51:48 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5071B2D72; Fri, 4 Jul 2014 13:51:45 -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] autolearn=ham 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 EeQbCRHtjsQ2; Fri, 4 Jul 2014 13:51:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E92991B2A3D; Fri, 4 Jul 2014 13:51:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704205143.21789.24081.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 13:51:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/Zdm1aRCTs3AhqOZXTbr1-ByV1rY Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 20:51:45 -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 Working Group of the IETF. Title : Stream Schedulers and a New Data Chunk for the Stream Control Transmission Protocol Authors : Randall R. Stewart Michael Tuexen Salvatore Loreto Robin Seggelmann Filename : draft-ietf-tsvwg-sctp-ndata-01.txt Pages : 11 Date : 2014-07-04 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. 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: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-ndata-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 23:20:32 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4BC1A0352 for ; Fri, 4 Jul 2014 23:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 3CgzuoppTOqm for ; Fri, 4 Jul 2014 23:20:25 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [142.59.210.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E5E1A0341 for ; Fri, 4 Jul 2014 23:20:24 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s656KM5H011795; Sat, 5 Jul 2014 00:20:22 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s656KMtA001900; Sat, 5 Jul 2014 00:20:22 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id s656KLJt001899; Sat, 5 Jul 2014 00:20:21 -0600 Date: Sat, 5 Jul 2014 00:20:21 -0600 From: "Brian F. G. Bidulock" To: Michael Tuexen Message-ID: <20140705062021.GA30371@openss7.org> Mail-Followup-To: Michael Tuexen , "Karen E. Egede Nielsen" , Randall Stewart , tsvwg@ietf.org References: <6de6099c3bd0543b17cfa5da84d327ad@mail.gmail.com> <79B46DEE-529C-4326-8F98-64575C2A880B@lurchi.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79B46DEE-529C-4326-8F98-64575C2A880B@lurchi.franken.de> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/1VHOYOeHAUFCk9uSraMD7MinJA8 Cc: "Karen E. Egede Nielsen" , Randall Stewart , tsvwg@ietf.org Subject: Re: [tsvwg] draft-stewart-tsvwg-sctp-ndata-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 06:20:27 -0000 Michael, I had some interest in this draft after having identified and discussed this issue so many years ago. I have read this version of your draft and have some comments: | 1. Introduction | | 1.1. Overview | | When SCTP [RFC4960] was initially designed it was mainly envisioned | for transport of small signaling messages. Late in the design stage | it was decided to add support for fragmentation and reassembly of | larger messages with the thought that someday Session Initiation | Protocol (SIP) [RFC3261] style signaling messages may also need to | use SCTP and a single MTU sized message would be too small. | Unfortunately this design decision, though valid at the time, did not | account for other applications which might send very large messages | over SCTP. When such large messages are now sent over SCTP a form of | sender side head of line blocking becomes created within the | protocol. This head of line blocking is caused by the use of the | Transmission Sequence Number (TSN) for two different purposes: | | 1. As an identifier for DATA chunks to provide a reliable transfer. | | 2. As an identifier for the sequence of fragments to allow | reassembly. | | The protocol requires all fragments of a user message to have | consecutive TSNs. Therefore the sender can not interleave different | messages. I think that is a quite fictional rewrite of history. These issues were addressed long before RFC 3960 issued and some even vocally requested the postponement of the RFC until related issues could be resolved (no, not me, that was a different issue). | The protocol requires all fragments of a user message to have | consecutive TSNs. Therefore the sender can not interleave different | messages. The first statement is correct; the inference is false. SCTP places no total ordering constraint on transmission of data chunks. I will say that again: SCTP places no total ordering constraint on transmission of data chunks. Multi-homing would be impractical if it did: it would be impractical in a modern operating system for a sender at the transport level to ensure that a TSN was not emitted from one interface before another. It would be pointless anyway given that the underlying network gives no guarantees of total ordering. Therefore, given that there is no total ordering constraint imposed by SCTP on the transmission of TSNs, the fact that TSNs are assigned in numerical sequence for a message does not prohibit a sender from interleaving data chunks in transmission. Therefore, there is no head of line blocking. So, for example, As a sender, I get an large ordered message that I chunk up into 2000 data chunks. I assign the data chunks TSNs 1 through 2000 and start sending the first few, say 1, 2, 3, until I use up my cwnd. The rest I queue for transmission in a normal queue. I then get a small unordered message. I want to expedite this message (because SIGTRAN uses unordered messages for expedited requests). I assign it TSN 2001 and queue it in an expedited queue for transmission. When the cwnd opens I send TSNs 2001, 4, 5, 6. SCTP does not prohibit me from doing this. Yes, I will likely get a gap ack, but so what? I know I didn't send the messages in the gap yet. Also, creating a situation that could happen at any moment anyway cannot be harmful. Interleaving of transmission was never the issue. The issue was with the interface between SCTP and the ULP and the needs of the ULP with regard to message composition. For the sender to do what I just described, it must be able to sequentially assign all of the large message's TSNs before it can assign a TSN to the small message. To assign TSNs to the large message, it needs to know the total size of the message so it can calculate chunk sizes and determine the total number of data chunks (and TSNs) required. The problem with this is that it places the onus on the ULP to know the total message size before passing any of it to SCTP, requiring it to compose the entire message before writing the first byte. This, of course, hampers stream-based compression, encoding schemes, block cypher and a whole bunch of useful stuff that might want to put the data into a big SCTP message. However, the most direct way around that is to fragment the stream in the ULP and wrap it with an application header giving information like the byte offset within the stream. We discussed this concerning RDDP back in 2000. My annoyance with having to know the total message size was for directly using a standard Sockets (sendmsg) or STREAMS interface (XTI) as an interface to SCTP where the caller just tells the transport that there is "MORE" data making up the record that will be presented later: it precluded me from sending the first part until the later parts arrived and potentially blocking up the write buffer. No other transport had this problem. What I wanted to see happen, and I discussed this back in 2000 and went over it in detail with you and Randal at the 2006 interop was to relax the sequential TSN assignment to simply an ordered TSN assignment. I will use the example again: As a sender, I get the beginning of a large unordered message that I chunk up into 4 data chunks. I add these 4 data chunks to the send queue for the stream. I perform a transmission when cwnd becomes available and assign TSNs 1, 2 and 3, and send the first 3 chunks in a packet and use up my cwnd. I then get the small unordered message which I chunk into one chunk and place on the expedited queue. I then get another portion of the large unordered message which I chunk up into 4 more data chunks. My cwnd opens and I assign TSN 4 to the expedited chunk, and TSNs 5, 6 and 7 to chunks from the large message. Under the relaxed constraint on assigning TSNs, I can easily do what is necessary and even avoid unnecessary gap acks. The relaxed constraint does not require major modifications at the receiver: the receiver cannot deliver the large message past a missing TSN in either case. Besides, a receiver implementation should not attempt to enforce sender requirements, nor unnecessarily rely heavily on sender behaviour. When all of the TSNs are in (between B and E), there is always sufficient information to reassemble messages regardless of whether the sender interleaves TSNs or not. The position where HOL blocking could be reintroduced is where a number of large messages with interleaved TSNs are being transferred and one TSN in the middle of theme is lost, blocking them all until it can be recovered (under some APIs). This is not due to sequential TSN assignment, but comes instead from relaxing the constraint and deficiencies of the receiver API. Your frame sequence number could assist the receiver in determining in the event of a missing TSN, not to which message the missing TSN belongs, but to which it does not belong: allowing the complete parts of the other messages to be released. But because of that, I don't see why the FSN cannot simply be added to the DATA chunk header and let the receiver that doesn't understand it ignore it. | 3.2. Receiver Side Considerations | | Upon reception of an SCTP packet containing a N-DATA chunk if the | message needs to be reassembled, then the receiver MUST use the FSN | for reassembly of the message and not the TSN. Note that a non- | fragmented messages is indicated by the fact that both the 'E' and | 'B' bits are set. An ordered or unordered fragmented message is thus | identified with any message not having both bits set. There is no reason to require the receiver to not use the TSN. If all TSNs have been received, the FSN is not even useful. If the receiver ignores the FSN even when a TSN is missing, it simply might not deliver messages to its ULP as quickly as it might. But there are other considerations on delivery of messages to the ULP and reassembly is not even necessary until the implementation goes to deliver a message. Hey, some API might even reassemble two of three scatter-gather buffers and deliver the two before the missing one even arrives. I think it is an implementation decision. I think this should say "may use the FSN in reassembly of messages". | 3.1. Sender Side Considerations | | A sender MUST NOT use the N-DATA chunk unless the user has requested | that use via the socket API (see Section 4). This constraint is made Please don't tell me I MUST use an INFORMATIONAL section referring to an INFORMATIONAL RFC for anything. End the sentence after "that use". I would consider that a ULP writing a message with the "MORE" bit set is requesting the service, or that is simply using an API where it can set a "MORE" bit as requesting the service, where "setting a MORE bit" means opening any API where the ULP can send the first portion of a message without specifying the total length of the message. | 4. Socket API Considerations | | This section describes how the socket API defined in [RFC6458] is | extended to allow applications to use the extension described in this | document. | | Please note that this section is informational only. Hey, can you put all this non-standard INFORMATIONAL stuff in a different document? It is much longer than the NORMATIVE part and really doesn't contribute anything to the document. Well, that's enough for now. I'm sure some flurry will result from these comments anyway so we can discuss more up the ladder. I have one question (just to check that you actually read this far): what caused you to try to address this issue now, 14 years after the fact? --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From nobody Sun Jul 6 05:16:13 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52CED1A0444 for ; Sun, 6 Jul 2014 05:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham 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 Hk85XZDSyAJo for ; Sun, 6 Jul 2014 05:16:08 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB211A0416 for ; Sun, 6 Jul 2014 05:16:06 -0700 (PDT) Received: from [192.168.1.200] (p54819DC9.dip0.t-ipconnect.de [84.129.157.201]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 8F2CE1C104DDD for ; Sun, 6 Jul 2014 14:16:03 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <20140704175507.27060.46688.idtracker@ietfa.amsl.com> Date: Sun, 6 Jul 2014 14:16:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <399CE093-36F9-4543-B992-E524C80C1B38@lurchi.franken.de> References: <20140704175507.27060.46688.idtracker@ietfa.amsl.com> To: tsvwg WG X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/SvltxIkAzhI05QoCGkGHVmBdT8Y Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 12:16:10 -0000 On 04 Jul 2014, at 19:55, internet-drafts@ietf.org wrote: Dear WG, I just wanted to let you know that this version contain changes based = feedback from the WG chairs and Eric Rescorla regarding DTLS. Eric pointed out that WebRTC at the time of the review only supported = DTLS 1.0, whereas the previous version of the documents required DTLS 1.2 or = higher. We agreed on using DTLS in a consistent way is important. So I brought = the issue up at the rtcweb mailing list and changed the version in the = document to 1.0. However, the discussion on the rtcweb mailing is ongoing and we = might need another revision to get the DTLS version synced. The current state = is to require support for DTLS 1.0 and DTSL 1.2. Best regards Michael >=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 Working = Group of the IETF. >=20 > Title : DTLS Encapsulation of SCTP Packets > Authors : Michael Tuexen > Randall R. Stewart > Randell Jesup > Salvatore Loreto > Filename : draft-ietf-tsvwg-sctp-dtls-encaps-05.txt > Pages : 8 > Date : 2014-07-04 >=20 > Abstract: > The Stream Control Transmission Protocol (SCTP) is a transport > protocol originally defined to run on top of the network protocols > IPv4 or IPv6. This document specifies how SCTP can be used on top = of > the Datagram Transport Layer Security (DTLS) protocol. Using the > encapsulation method described in this document, SCTP is agnostic > about the protocols being used below DTLS, explicit IP addresses can > not be used in the SCTP control chunks. As a consequence, the SCTP > associations are single homed. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-dtls-encaps/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-sctp-dtls-encaps-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/ >=20 >=20 From nobody Sun Jul 6 12:05:19 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21601A0A85 for ; Sun, 6 Jul 2014 12:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham 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 gq6_zOBve0p7 for ; Sun, 6 Jul 2014 12:05:15 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B93671A0A84 for ; Sun, 6 Jul 2014 12:05:14 -0700 (PDT) Received: from [192.168.1.200] (p54819DC9.dip0.t-ipconnect.de [84.129.157.201]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id CC2291C104DA8; Sun, 6 Jul 2014 21:05:11 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <20140704013404.GB11240@openss7.org> Date: Sun, 6 Jul 2014 21:05:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <91A17867-3909-4988-B993-EC214D7B50B0@lurchi.franken.de> References: <53B5183A.7060301@erg.abdn.ac.uk> <20140704013404.GB11240@openss7.org> To: bidulock@openss7.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/Wu7mlryAf64XDOaIiJ7BM3gci2k Cc: tsvwg@ietf.org Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-prpolicies-03 - due to conclude Monday, July 21st, 2014 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 19:05:17 -0000 On 04 Jul 2014, at 03:34, Brian F. G. Bidulock = wrote: > Gorry, >=20 > Please see comments below: >=20 > Gorry Fairhurst wrote: (Thu, 03 Jul 2014 = 09:45:46) >> This is the start of the WGLC on "Additional Policies for the Partial = =20 >> Reliability Extension of the Stream Control Transmission Protocol" = for =20 >> publication intended as a PS. >>=20 >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-prpolicies/ >>=20 >> This WGLC will last until Monday, July 21st, 2014 (longer since this =20= >> includes time prior to an IETF meeting). >>=20 >> Could people please send *any* comments to the list if they think = this =20 >> is ready to publish? >>=20 >> A good note is "I have read this version of the draft, >> and I approve (or support) its progression to RFC". >>=20 >> James/Gorry/David >> TSVWG chairs >=20 >=20 > I have read this version of the draft; however, I have some > comments: Hi Brian, thanks for reading the document and providing feedback. See my comments in-line. Best regards Michael >=20 > It appears that the document only has about 3 (or 4) normative > paragraphs. Of those three (or 4) paragraphs the key word > "REQUIRED" is used once with reference to RFC3758; the key word > "MUST" is used once with regard to abandoning a user message that MUST appears two times... > would exceed a retransmission limit. There are two "MAY" and one > "OPTIONAL" key words. The rest of the document is informational. >=20 > I question the sole "MUST" in section 3.1. The most I think it > should be is a "SHOULD" and it should probably just be a "MAY". There are two MUSTs here. This first one is the one you refer to, I think. The second one needs to be a MUST even if you downgrade the first one to SHOULD. > Other considerations could go into whether to abandon or simply > postpone a retransmission that achieve the same effect. Perhaps > what is attempted here is to say that "after a message has reached > its retransmission limit, the sender SHOULD NOT retransmit the > message again at the exclusion of resources to other messages > available for transmission or retransmission." I do not see why you > would want to abandon retransmissions of messages on otherwise idle > associations: it would unnecessarily lower the reliability of the > association. The user point is what the upper layer expects if he limits the number of retransmissions. Your interpretation would be: * When the number of retransmissions exceeds the threshold, the SCTP implementation is free is abandon the message. The intended semantic used in this document is * When the number of retransmissions exceeds the threshold, the SCTP implementation abandons the message. This is in-tune with the semantic used by the RTCWeb WG. > Also, when the sender is to abandon the message, it should likely > only be on the event of a timer-based retransmission request. A > sender can get all kinds of spurious fast-retransmission requests > resulting in the discard of an excessive number of messages under > the current policy. In fact, abandoning messages _in_itself_ is > likely to cause additional spurious gap reports and > fast-retransmission. However, abandoning on a timer-based > retransmission would make the policy hardly distinguishable on the > wire from the existing lifetimes-based PR policy. I think one of the most important limits is 0. Here the upper layer does not distinguish between timer based or fast retransmissions. >=20 > In summary, it seems to me that the document simply asks us to > implement some loose definition of a sender-side only API that does > not describe anything that "is required for interoperation or to > limit the behavior which has potential for causing harm" as required > by RFC 2119. It seems to abuse the only normative MUST in the > document applied to a sender-side procedure that appears to not to > have been given much careful consideration. The intended status was changed from Informational to PS because * the second MUST as described above. * without normative language you can make sure that the upper gets what he expects. This might not affect interoperability at the SCTP layer, but does influence the upper layer. >=20 > The entire document appears more focused on the INFORMATIONAL > section 4 than on the NORMATIVE section 3. Section 4 is longer, that is right. But the focus is not there. If you don't case about the socket layer, section 4 is not important to you. >=20 > As such, I object to it being published as a PS. I would support > the draft being published as an INFORMATIONAL RFC if the procedure > described in section 3.1 is properly revised. >=20 > --brian >=20 > --=20 > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ >=20 >=20 From nobody Sun Jul 6 19:08:34 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5262C1A00BA for ; Sun, 6 Jul 2014 19:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 fEMzH8T8_KMI for ; Sun, 6 Jul 2014 19:08:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78E191A0089 for ; Sun, 6 Jul 2014 19:08:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJR63261; Mon, 07 Jul 2014 02:08:29 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Jul 2014 03:08:28 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 10:08:22 +0800 From: "Huangyihong (Rachel)" To: "gorry@erg.abdn.ac.uk" Thread-Topic: [tsvwg] TSVWG - Request for Agenda Items for Toronto meetings Thread-Index: AQHPlr8C/3zugp/z0EeJH2BTC37NRJuPIxOA///zL4CABMxREA== Date: Mon, 7 Jul 2014 02:08:21 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB861E9C94@nkgeml501-mbs.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB861E96E0@nkgeml501-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.144] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/nOXZIHmd5oEaV7EMqxj04-rAycA Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] TSVWG - Request for Agenda Items for Toronto meetings X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 02:08:32 -0000 Thank you, Gorry. I will do it. BR, Rachel > -----Original Message----- > From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] > Sent: Friday, July 04, 2014 4:50 PM > To: Huangyihong (Rachel) > Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org > Subject: RE: [tsvwg] TSVWG - Request for Agenda Items for Toronto meeting= s >=20 > Thanks for submitting this draft. >=20 > This may be an interesting topic, however, we don't normally present init= ial > drafts until there has been discussion at a WG meeting or on the list. >=20 > It is best to start by asking the list comments on the mailing list. If y= ou haven't > already done so - you should probably post a note separately to the TAPS > group and ask them for feedback on the proposed topics. >=20 > I'll consult my co-chairs about the Agenda, and note your interest in pre= senting. >=20 > Gorry >=20 > > Hi Chairs, > > > > I'd like to request a slot for my draft > > http://www.ietf.org/internet-drafts/draft-huang-tsvwg-tr-tcp-ps-00.txt > > . 10 minutes would be fine. Thank you so much. > > > > BR, > > Rachel > > > >> -----Original Message----- > >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of > >> gorry@erg.abdn.ac.uk > >> Sent: Thursday, July 03, 2014 9:01 PM > >> To: tsvwg@ietf.org > >> Subject: [tsvwg] TSVWG - Request for Agenda Items for Toronto > >> meetings > >> > >> > >> Hi tsvwg'ers, > >> > >> This is a request for people to offer presentations on drafts to be > >> presented to the tsvwg working group at the Toronto IETF. > >> > >> I've upload a very initial agenda here: > >> http://www.ietf.org/proceedings/90/agenda/agenda-90-tsvwg > >> > >> Many of the talks are marked TBC (editors please confirm). We do have > >> space to discuss additional drafts. > >> > >> Please send all requests and any corrections to the chairs asap. > >> > >> Gorry, David and James > >> (tsvwg co-chairs) > >> > > >=20 From nobody Sun Jul 6 19:51:52 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300561A0ABD for ; Sun, 6 Jul 2014 19:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.056 X-Spam-Level: **** X-Spam-Status: No, score=4.056 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=1.012, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=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 nDbapDtXItDj for ; Sun, 6 Jul 2014 19:51:46 -0700 (PDT) Received: from mail.bit.edu.cn (unknown [202.204.80.7]) by ietfa.amsl.com (Postfix) with SMTP id 53CD01A0ABE for ; Sun, 6 Jul 2014 19:51:44 -0700 (PDT) X-EYOU-SPAMVALUE: 0 X-EMDG-ORIGINAL-FROM: X-EMDG-ORIGINAL-TO: X-EMDG-ORIGINAL-IP: 202.204.94.83 X-EMDG-VER: 4.1.1 X-EMDG-ABROAD: no Received: (eyou anti_spam gateway 4.1.0); Mon, 07 Jul 2014 10:25:40 +0800 X-EMDG-MID: <604699940.28720@mail.bit.edu.cn> Received: from 202.204.94.83 by 202.204.80.83 with SMTP; Mon, 07 Jul 2014 10:25:40 +0800 Received: from localhost ([127.0.0.1]) by bit.edu.cn with sendmail id c4f4946cd1605b4926ace2cbf30d0456; Mon, 07 Jul 2014 10:51:39 +0800 Date: Mon, 07 Jul 2014 10:51:38 +0800 From: "Xiaolin Deng" To: tsvwg@ietf.org, gorry@erg.abdn.ac.uk References: In-Reply-To: Message-Id: <140707105138850772002668@bit.edu.cn> MIME-Version: 1.0 X-Mailer: eYou WebMail 8.1.0.4 X-Eyou-Client: 10.15.10.47 X-Content_type: html Content-Type: multipart/alternative; boundary="c720a68515d37290477ebfafb886ca8b" Content-Transfer-Encoding: 7bit X-Eyou-Sender: Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/cynusQRDIbZ5136pUTXqtBNP0Aw Subject: Re: [tsvwg] TSVWG - Request for Agenda Items for Toronto meetings X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 02:51:51 -0000 --c720a68515d37290477ebfafb886ca8b Content-Type: text/plain; charset="GBK" Content-Transfer-Encoding: base64 SGkgQ2hhaXJzLAoKSSB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgYSAxMCBtaW51dGVzIHBy ZXNlbnRhdGlvbiBmb3IgbXkgZHJhZnQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1kZW5nLXRzdndnLXFvZS1ldmFsdWF0aW9uLWhhcy8uICBUaGFuayB5 b3UhCgpCUiwKWGlhb2xpbiBEZW5nCgotLS0tLS0tLS0tIE9yaWdpbiBtZXNzYWdlIC0t LS0tLS0tLS0KPkZyb22jumdvcnJ5QGVyZy5hYmRuLmFjLnVrCj5Ub6O6dHN2d2dAaWV0 Zi5vcmcKPlN1YmplY3Sjult0c3Z3Z10gVFNWV0cgLSBSZXF1ZXN0IGZvciBBZ2VuZGEg SXRlbXMgZm9yIFRvcm9udG8gbWVldGluZ3MKPkRhdGWjujIwMTQtMDctMDcgMTA6NTE6 MDYKCgpIaSB0c3Z3ZydlcnMsCgpUaGlzIGlzIGEgcmVxdWVzdCBmb3IgcGVvcGxlIHRv IG9mZmVyIHByZXNlbnRhdGlvbnMgb24gZHJhZnRzIHRvIGJlCnByZXNlbnRlZCB0byB0 aGUgdHN2d2cgd29ya2luZyBncm91cCBhdCB0aGUgVG9yb250byBJRVRGLgoKSSd2ZSB1 cGxvYWQgYSB2ZXJ5IGluaXRpYWwgYWdlbmRhIGhlcmU6Cmh0dHA6Ly93d3cuaWV0Zi5v cmcvcHJvY2VlZGluZ3MvOTAvYWdlbmRhL2FnZW5kYS05MC10c3Z3ZwoKTWFueSBvZiB0 aGUgdGFsa3MgYXJlIG1hcmtlZCBUQkMgKGVkaXRvcnMgcGxlYXNlIGNvbmZpcm0pLiBX ZSBkbyBoYXZlCnNwYWNlIHRvIGRpc2N1c3MgYWRkaXRpb25hbCBkcmFmdHMuCgpQbGVh c2Ugc2VuZCBhbGwgcmVxdWVzdHMgYW5kIGFueSBjb3JyZWN0aW9ucyB0byB0aGUgY2hh aXJzIGFzYXAuCgpHb3JyeSwgRGF2aWQgYW5kIEphbWVzCih0c3Z3ZyBjby1jaGFpcnMp CgoKIA== --c720a68515d37290477ebfafb886ca8b Content-Type: text/html; charset="GBK" Content-Transfer-Encoding: base64 PHNwYW4gY2xhc3M9ImVtdGlkeS0xIiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyBsaW5l LWhlaWdodDogMjFweDsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IFNp bXN1bjsiPkhpIENoYWlycyw8L3NwYW4+PGJyIGNsYXNzPSJlbXRpZHktMiIgc3R5bGU9 ImZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDIxcHg7IGNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBTaW1zdW47IiAvPgo8YnIgY2xhc3M9ImVtdGlkeS0y IiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjFweDsgY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IFNpbXN1bjsiIC8+CjxzcGFuIGNsYXNz PSJlbXRpZHktMSIgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDIx cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBTaW1zdW47Ij5JIHdv dWxkIGxpa2UgdG8gcmVxdWVzdCBhIDEwJm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJl bXRpZHktMSBlbXRpZHktMSIgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWln aHQ6IDIxcHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBTaW1zdW47 Ij5taW51dGVzJm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJlbXRpZHktMSIgc3R5bGU9 ImZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDIxcHg7IGNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBTaW1zdW47Ij5wcmVzZW50YXRpb24gZm9yIG15IGRy YWZ0Jm5ic3A7PC9zcGFuPjxhIGNsYXNzPSJlbXRpZHktMyIgaHJlZj0iaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kZW5nLXRzdndnLXFvZS1ldmFsdWF0 aW9uLWhhcy8iIHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyMXB4 OyBmb250LWZhbWlseTogU2ltc3VuOyI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1kZW5nLXRzdndnLXFvZS1ldmFsdWF0aW9uLWhhcy88L2E+PHNwYW4g Y2xhc3M9ImVtdGlkeS0xIiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdo dDogMjFweDsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IFNpbXN1bjsi Pi4gJm5ic3A7VGhhbmsgeW91ITwvc3Bhbj48YnIgY2xhc3M9ImVtdGlkeS0yIiBzdHls ZT0iZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjFweDsgY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IFNpbXN1bjsiIC8+CjxiciBjbGFzcz0iZW10aWR5 LTIiIHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyMXB4OyBjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogU2ltc3VuOyIgLz4KPHNwYW4gY2xh c3M9ImVtdGlkeS0xIiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDog MjFweDsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IFNpbXN1bjsiPkJS LDwvc3Bhbj48YnIgY2xhc3M9ImVtdGlkeS0yIiBzdHlsZT0iZm9udC1zaXplOiAxNHB4 OyBsaW5lLWhlaWdodDogMjFweDsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IFNpbXN1bjsiIC8+CjxzcGFuIGNsYXNzPSJlbXRpZHktMSIgc3R5bGU9ImZvbnQt c2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDIxcHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBTaW1zdW47Ij5YaWFvbGluIERlbmc8L3NwYW4+PGJyIC8+Cjxi ciAvPgotLS0tLS0tLS0tIE9yaWdpbiBtZXNzYWdlIC0tLS0tLS0tLS08YnIgLz4KJmd0 O0Zyb22jumdvcnJ5QGVyZy5hYmRuLmFjLnVrPGJyIC8+CiZndDtUb6O6dHN2d2dAaWV0 Zi5vcmc8YnIgLz4KJmd0O1N1YmplY3Sjult0c3Z3Z10gVFNWV0cgLSBSZXF1ZXN0IGZv ciBBZ2VuZGEgSXRlbXMgZm9yIFRvcm9udG8gbWVldGluZ3M8YnIgLz4KJmd0O0RhdGWj ujIwMTQtMDctMDcgMTA6NTE6MDY8YnIgLz4KPGJyIC8+CjxiciAvPgpIaSB0c3Z3ZyYj Mzk7ZXJzLDxiciAvPgo8YnIgLz4KVGhpcyBpcyBhIHJlcXVlc3QgZm9yIHBlb3BsZSB0 byBvZmZlciBwcmVzZW50YXRpb25zIG9uIGRyYWZ0cyB0byBiZTxiciAvPgpwcmVzZW50 ZWQgdG8gdGhlIHRzdndnIHdvcmtpbmcgZ3JvdXAgYXQgdGhlIFRvcm9udG8gSUVURi48 YnIgLz4KPGJyIC8+CkkmIzM5O3ZlIHVwbG9hZCBhIHZlcnkgaW5pdGlhbCBhZ2VuZGEg aGVyZTo8YnIgLz4KaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85MC9hZ2Vu ZGEvYWdlbmRhLTkwLXRzdndnPGJyIC8+CjxiciAvPgpNYW55IG9mIHRoZSB0YWxrcyBh cmUgbWFya2VkIFRCQyAoZWRpdG9ycyBwbGVhc2UgY29uZmlybSkuIFdlIGRvIGhhdmU8 YnIgLz4Kc3BhY2UgdG8gZGlzY3VzcyBhZGRpdGlvbmFsIGRyYWZ0cy48YnIgLz4KPGJy IC8+ClBsZWFzZSBzZW5kIGFsbCByZXF1ZXN0cyBhbmQgYW55IGNvcnJlY3Rpb25zIHRv IHRoZSBjaGFpcnMgYXNhcC48YnIgLz4KPGJyIC8+CkdvcnJ5LCBEYXZpZCBhbmQgSmFt ZXM8YnIgLz4KKHRzdndnIGNvLWNoYWlycyk8YnIgLz4KPGJyIC8+CjxiciAvPgombmJz cDs= --c720a68515d37290477ebfafb886ca8b-- From nobody Sun Jul 6 20:04:12 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B211A0AD0 for ; Sun, 6 Jul 2014 20:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 3nh2IvQfRUwo for ; Sun, 6 Jul 2014 20:04:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3050E1A0ACF for ; Sun, 6 Jul 2014 20:04:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGV88874; Mon, 07 Jul 2014 03:04:07 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Jul 2014 04:04:07 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 11:04:02 +0800 From: "Huangyihong (Rachel)" To: "Scharf, Michael (Michael)" Thread-Topic: [tsvwg] TSVWG - Request for Agenda Items for Toronto meetings Thread-Index: AQHPlr8C/3zugp/z0EeJH2BTC37NRJuPIxOA///zL4CAAAWhAIAEySgg Date: Mon, 7 Jul 2014 03:04:01 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB861E9CFC@nkgeml501-mbs.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB861E96E0@nkgeml501-mbs.china.huawei.com> <655C07320163294895BBADA28372AF5D165BEE49@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D165BEE49@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.144] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/Xnse0eF6D85DksBgOQzRF_0OKKY Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" Subject: Re: [tsvwg] TSVWG - Request for Agenda Items for Toronto meetings X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 03:04:11 -0000 Hi Michael, Thanks for the suggestion. I'll do it.=20 Our motivation is to discuss the problems when traditional TCP meets some s= cenarios, e.g., different use cases may need different requirements to TCP = (different congestion control algorithms, different TCP parameters). Tradit= ional TCP is not flexible enough to deal with these problems. For example, = some congestion control algorithms are application layer, some parameters a= re fixed which can't be changes easily. Maybe a new method/solution is help= ful. We have an OPEN TCP solution that tries to open TCP enough so that dif= ferent applications can choose their different parameters or proper congest= ion control algorithms in transport layer. Currently, we just want to discu= ss with the people in IETF to make sure that such problems do exist and we = do have the requirements to change them. Thanks for pointing out RFC 6077. I'm not familiar with it. But I'll read i= t immediately ^^. BR, Rachel > -----Original Message----- > From: Scharf, Michael (Michael) [mailto:michael.scharf@alcatel-lucent.com= ] > Sent: Friday, July 04, 2014 5:10 PM > To: Huangyihong (Rachel) > Cc: tsvwg@ietf.org; gorry@erg.abdn.ac.uk > Subject: RE: [tsvwg] TSVWG - Request for Agenda Items for Toronto meeting= s >=20 > If the intention of this document is to discuss a modification of TCP par= ameters, > the TCPM mailing list might also be an appropriate place to get feedback = (albeit > most contributors to TCPM also follow TSVWG). >=20 > I'd recommend to have a look at RFC 6077 first. >=20 > Michael >=20 >=20 > > -----Original Message----- > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of > > gorry@erg.abdn.ac.uk > > Sent: Friday, July 04, 2014 10:50 AM > > To: Huangyihong (Rachel) > > Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org > > Subject: Re: [tsvwg] TSVWG - Request for Agenda Items for Toronto > > meetings > > > > Thanks for submitting this draft. > > > > This may be an interesting topic, however, we don't normally present > > initial drafts until there has been discussion at a WG meeting or on > > the list. > > > > It is best to start by asking the list comments on the mailing list. > > If you haven't already done so - you should probably post a note > > separately to the TAPS group and ask them for feedback on the proposed > > topics. > > > > I'll consult my co-chairs about the Agenda, and note your interest in > > presenting. > > > > Gorry > > > > > Hi Chairs, > > > > > > I'd like to request a slot for my draft > > > http://www.ietf.org/internet-drafts/draft-huang-tsvwg-tr-tcp-ps- > > 00.txt. 10 > > > minutes would be fine. Thank you so much. > > > > > > BR, > > > Rachel > > > > > >> -----Original Message----- > > >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of > > >> gorry@erg.abdn.ac.uk > > >> Sent: Thursday, July 03, 2014 9:01 PM > > >> To: tsvwg@ietf.org > > >> Subject: [tsvwg] TSVWG - Request for Agenda Items for Toronto > > meetings > > >> > > >> > > >> Hi tsvwg'ers, > > >> > > >> This is a request for people to offer presentations on drafts to be > > >> presented to the tsvwg working group at the Toronto IETF. > > >> > > >> I've upload a very initial agenda here: > > >> http://www.ietf.org/proceedings/90/agenda/agenda-90-tsvwg > > >> > > >> Many of the talks are marked TBC (editors please confirm). We do > > have > > >> space > > >> to discuss additional drafts. > > >> > > >> Please send all requests and any corrections to the chairs asap. > > >> > > >> Gorry, David and James > > >> (tsvwg co-chairs) > > >> > > > > > From nobody Mon Jul 7 12:46:53 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADDAB1B28AB for ; Mon, 7 Jul 2014 12:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham 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 J-qVXXOQ3XyQ for ; Mon, 7 Jul 2014 12:46:37 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF521B28BC for ; Mon, 7 Jul 2014 12:46:36 -0700 (PDT) Received: from [192.168.1.200] (p54819C6D.dip0.t-ipconnect.de [84.129.156.109]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id E2AB41C104925; Mon, 7 Jul 2014 21:46:32 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <20140705062021.GA30371@openss7.org> Date: Mon, 7 Jul 2014 21:46:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <952FFA8E-3D67-4CC3-9D82-BDA2DD1FA9ED@lurchi.franken.de> References: <6de6099c3bd0543b17cfa5da84d327ad@mail.gmail.com> <79B46DEE-529C-4326-8F98-64575C2A880B@lurchi.franken.de> <20140705062021.GA30371@openss7.org> To: bidulock@openss7.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/ryuFcLWKhvA-IZhjssceM1mVNXI Cc: "Karen E. Egede Nielsen" , Randall Stewart , tsvwg@ietf.org Subject: Re: [tsvwg] draft-stewart-tsvwg-sctp-ndata-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 19:46:43 -0000 On 05 Jul 2014, at 08:20, Brian F. G. Bidulock = wrote: > Michael, >=20 > I had some interest in this draft after having identified and > discussed this issue so many years ago. I have read this version > of your draft and have some comments: Hi Brian, thanks for reading it and providing feedback. See my comments in-line. Best regards Michael >=20 > | 1. Introduction > |=20 > | 1.1. Overview > |=20 > | When SCTP [RFC4960] was initially designed it was mainly = envisioned > | for transport of small signaling messages. Late in the design = stage > | it was decided to add support for fragmentation and reassembly of > | larger messages with the thought that someday Session Initiation > | Protocol (SIP) [RFC3261] style signaling messages may also need = to > | use SCTP and a single MTU sized message would be too small. > | Unfortunately this design decision, though valid at the time, did = not > | account for other applications which might send very large = messages > | over SCTP. When such large messages are now sent over SCTP a = form of > | sender side head of line blocking becomes created within the > | protocol. This head of line blocking is caused by the use of the > | Transmission Sequence Number (TSN) for two different purposes: > |=20 > | 1. As an identifier for DATA chunks to provide a reliable = transfer. > |=20 > | 2. As an identifier for the sequence of fragments to allow > | reassembly. > |=20 > | The protocol requires all fragments of a user message to have > | consecutive TSNs. Therefore the sender can not interleave = different > | messages. >=20 > I think that is a quite fictional rewrite of history. These issues > were addressed long before RFC 3960 issued and some even vocally > requested the postponement of the RFC until related issues could be > resolved (no, not me, that was a different issue). As far as I remember, the focus was on support for small message, not for large ones. The limitation was know at the time of RFC 2960, but the decision at that time was to live with the limitation... For SIGTRAN is was not a real issue. >=20 > | The protocol requires all fragments of a user message to have > | consecutive TSNs. Therefore the sender can not interleave = different > | messages. >=20 > The first statement is correct; the inference is false. SCTP places > no total ordering constraint on transmission of data chunks. Formally you are right in the sense that SCTP will work as long no matter in which sequence the DATA chunks will arrive at the receiver. They can be reordered by the network or even be sent by the sender in any order. This can't be distinguished by the receiver. However: * You can't assign a TSN for a DATA chunk of message before knowing how many TSNs you need for the messages already started to send (and assigned a TSN). * The receiver will report TSNs not received in order, so you will get lot's of gap reports which might or might not trigger fast retransmissions and therefore having an impact on performance. >=20 > I will say that again: SCTP places no total ordering constraint on > transmission of data chunks. Multi-homing would be impractical if > it did: it would be impractical in a modern operating system for a > sender at the transport level to ensure that a TSN was not emitted > from one interface before another. It would be pointless anyway > given that the underlying network gives no guarantees of total > ordering. >=20 > Therefore, given that there is no total ordering constraint imposed > by SCTP on the transmission of TSNs, the fact that TSNs are assigned > in numerical sequence for a message does not prohibit a sender from > interleaving data chunks in transmission. Therefore, there is no > head of line blocking. Really? Think about sending a 1 GB message on stream 0, having = transferred 100MB of it. Now you send a 10 byte message on stream 1. What if you don't know the size of the big messages yet (using the explicit EOR = mode)? >=20 > So, for example, As a sender, I get an large ordered message that I > chunk up into 2000 data chunks. I assign the data chunks TSNs 1 > through 2000 and start sending the first few, say 1, 2, 3, until I So you do early TSN assignment. This means that if the MTU decreases during sending TSN up to 2000, you need to rely on IP-fragmentation. This also only works, if you know how many chunks you need in total. This does not work if you use the explicit EOR mode, so you can't send messages larger than your send buffer. > use up my cwnd. The rest I queue for transmission in a normal > queue. I then get a small unordered message. I want to expedite > this message (because SIGTRAN uses unordered messages for expedited > requests). I assign it TSN 2001 and queue it in an expedited queue > for transmission. When the cwnd opens I send TSNs 2001, 4, 5, 6. > SCTP does not prohibit me from doing this. Yes, I will likely get a > gap ack, but so what? I know I didn't send the messages in the gap > yet. Also, creating a situation that could happen at any moment > anyway cannot be harmful. It depends on harmful. You are right, all messages will be delivered within the ordering constraints of the sender. However, there can be performance penalties if you can't differentiate anymore between never send or probably lost. >=20 > Interleaving of transmission was never the issue. >=20 > The issue was with the interface between SCTP and the ULP and the > needs of the ULP with regard to message composition. For the sender > to do what I just described, it must be able to sequentially assign > all of the large message's TSNs before it can assign a TSN to the > small message. To assign TSNs to the large message, it needs to > know the total size of the message so it can calculate chunk sizes > and determine the total number of data chunks (and TSNs) required. It also needs the PMTU, which can change over time... > The problem with this is that it places the onus on the ULP to know > the total message size before passing any of it to SCTP, requiring > it to compose the entire message before writing the first byte. ... and the assumption that the MTU doesn't change while sending the message. > This, of course, hampers stream-based compression, encoding schemes, > block cypher and a whole bunch of useful stuff that might want to > put the data into a big SCTP message. However, the most direct way Not sure. If you run DTLS over SCTP, for example, the message size limited anyway to about 16KB. However, RTCWeb uses SCTP over DTLS and therefore the "upper layer" is the JS layer. > around that is to fragment the stream in the ULP and wrap it with an > application header giving information like the byte offset within > the stream. We discussed this concerning RDDP back in 2000. >=20 > My annoyance with having to know the total message size was for > directly using a standard Sockets (sendmsg) or STREAMS interface > (XTI) as an interface to SCTP where the caller just tells the > transport that there is "MORE" data making up the record that will > be presented later: it precluded me from sending the first part > until the later parts arrived and potentially blocking up the write > buffer. No other transport had this problem. >=20 > What I wanted to see happen, and I discussed this back in 2000 and > went over it in detail with you and Randal at the 2006 interop was > to relax the sequential TSN assignment to simply an ordered TSN > assignment. I will use the example again: I have to say that I can't remember. Sorry. So we need to go through it again... >=20 > As a sender, I get the beginning of a large unordered message that > I chunk up into 4 data chunks. I add these 4 data chunks to the > send queue for the stream. I perform a transmission when cwnd > becomes available and assign TSNs 1, 2 and 3, and send the first 3 > chunks in a packet and use up my cwnd. I then get the small > unordered message which I chunk into one chunk and place on the > expedited queue. I then get another portion of the large unordered > message which I chunk up into 4 more data chunks. My cwnd opens > and I assign TSN 4 to the expedited chunk, and TSNs 5, 6 and 7 to > chunks from the large message. >=20 > Under the relaxed constraint on assigning TSNs, I can easily do what > is necessary and even avoid unnecessary gap acks. You are focussing on the "handle small unordered as expedited" issue. The problem addressed here is the generic one: You might even have a large message on stream 0, and a higher priority smaller message, which still needs fragmentation, on a different stream. I agree that you probably can come up with a solution for sending smaller unordered messages "within" larger ordered ones, but this doesn't solve the general problem. I think the base problem is that the TSN is used for two things. Decoupling these will get clean solution. >=20 > The relaxed constraint does not require major modifications at the > receiver: the receiver cannot deliver the large message past a > missing TSN in either case. Besides, a receiver implementation > should not attempt to enforce sender requirements, nor unnecessarily > rely heavily on sender behaviour. When all of the TSNs are in > (between B and E), there is always sufficient information to > reassemble messages regardless of whether the sender interleaves > TSNs or not. >=20 >=20 > The position where HOL blocking could be reintroduced is where a > number of large messages with interleaved TSNs are being transferred > and one TSN in the middle of theme is lost, blocking them all until > it can be recovered (under some APIs). This is not due to sequential > TSN assignment, but comes instead from relaxing the constraint and > deficiencies of the receiver API. >=20 > Your frame sequence number could assist the receiver in determining > in the event of a missing TSN, not to which message the missing TSN > belongs, but to which it does not belong: allowing the complete parts > of the other messages to be released. But because of that, I don't > see why the FSN cannot simply be added to the DATA chunk header and > let the receiver that doesn't understand it ignore it. How can you add something to the DATA chunk header and get a receiver to ignore it in case it doesn't support the extension? >=20 > | 3.2. Receiver Side Considerations > |=20 > | Upon reception of an SCTP packet containing a N-DATA chunk if the > | message needs to be reassembled, then the receiver MUST use the = FSN > | for reassembly of the message and not the TSN. Note that a non- > | fragmented messages is indicated by the fact that both the 'E' = and > | 'B' bits are set. An ordered or unordered fragmented message is = thus > | identified with any message not having both bits set. >=20 > There is no reason to require the receiver to not use the TSN. If all > TSNs have been received, the FSN is not even useful. If the > receiver ignores the FSN even when a TSN is missing, it simply might > not deliver messages to its ULP as quickly as it might. But there > are other considerations on delivery of messages to the ULP and > reassembly is not even necessary until the implementation goes to > deliver a message. Hey, some API might even reassemble two of three > scatter-gather buffers and deliver the two before the missing one > even arrives. I think it is an implementation decision. >=20 > I think this should say "may use the FSN in reassembly of messages". I'm not sure what you are arguing here... A receiver supporting the = N-DATA chunk but not using the FSN for reassembly? So you want to reuse the old code, but use the new packet format? >=20 > | 3.1. Sender Side Considerations > |=20 > | A sender MUST NOT use the N-DATA chunk unless the user has = requested > | that use via the socket API (see Section 4). This constraint is = made >=20 > Please don't tell me I MUST use an INFORMATIONAL section referring > to an INFORMATIONAL RFC for anything. End the sentence after "that > use". No, this is not intended. Good point. Changed to A sender MUST NOT use the N-DATA chunk unless the user has requested that use (e.g. via the socket API, see ). It is the upper layer which has to say "use interleaving" since it also must handle the higher interleaving level on the receiving side. See http://tools.ietf.org/html/rfc6458#section-8.1.20 >=20 > I would consider that a ULP writing a message with the "MORE" bit > set is requesting the service, or that is simply using an API where > it can set a "MORE" bit as requesting the service, where "setting > a MORE bit" means opening any API where the ULP can send the first > portion of a message without specifying the total length of the > message. This is possible with the socket API: http://tools.ietf.org/html/rfc6458#section-8.1.26 >=20 > | 4. Socket API Considerations > |=20 > | This section describes how the socket API defined in [RFC6458] is > | extended to allow applications to use the extension described in = this > | document. > |=20 > | Please note that this section is informational only. >=20 > Hey, can you put all this non-standard INFORMATIONAL stuff in a > different document? It is much longer than the NORMATIVE part and > really doesn't contribute anything to the document. After RFC 6458 was published, we started to added a socket API section to the documents describing extensions, which describe how you could implement an API for the extension based on the socket API. I wasn't to bad to have both in one document. However, the API section is always purely informational (similar to = http://tools.ietf.org/html/rfc4960#section-10), so if you don't implement the socket API, you don't need to care. If you implement it, you can even do it differently. However, up to now, the SCTP Linux Kernel implementation, the Solaris implementation and the FreeBSD implementation use this API. >=20 > Well, that's enough for now. I'm sure some flurry will result from > these comments anyway so we can discuss more up the ladder. Sure. I know that the document is not done yet and I hope that we can improve it based on the discussion on the list. >=20 > I have one question (just to check that you actually read this far): So I passed that test, at least... > what caused you to try to address this issue now, 14 years after the > fact? RTCWeb is using SCTP for potentially large messages and needs support for interleaving. >=20 > --brian >=20 > --=20 > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ >=20 >=20 From nobody Tue Jul 8 08:38:08 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A81E1B2826 for ; Tue, 8 Jul 2014 08:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 8ckcYLeb7E-d for ; Tue, 8 Jul 2014 08:38:04 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 358971A020B for ; Tue, 8 Jul 2014 08:38:04 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 6C2DE2B43C1; Tue, 8 Jul 2014 16:38:03 +0100 (BST) Received: from ERG-research.local (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 991DB2B43C0; Tue, 8 Jul 2014 16:38:01 +0100 (BST) Message-ID: <53BC1059.4000905@erg.abdn.ac.uk> Date: Tue, 08 Jul 2014 16:38:01 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "draft-ietf-tsvwg-gre-in-udp-encap@tools.ietf.org" , tsvwg WG References: <2691CE0099834E4A9C5044EEC662BB9D453B0EFA@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453B0EFA@dfweml701-chm.china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/RtxpL65ERUipA7lO3uNeOQ6t2Es Subject: Re: [tsvwg] FW: I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 08 Jul 2014 15:38:06 -0000 I have some comments on this draft as an individual, please see below: * First, I think the new revision helps explain some of the questions that were highlighted, thanks for preparing the update. * section 3 "randomly selected constant value, e.g. zero," - I don't understand this in two ways: (1) I don't think it should be zero, I think you could find a hash of some internal state to generate a ramdom number. For instance this is used in the PIM routing (RFC4601) to specify the genID which is simply a unique number each time the system reboots or the session is restarted (this has the advantage of reseting state after a reboot). (2) setting it to zero means you wont have any entropy for ECMP, so why is this mode specified in this draft - or is for more general use? * Section 3 para 3 - "packets destined to this assigned UDP destination port [TBD] MAY have their UDP checksum set to zero." I think the first specification here applies only to IPv4, sicne IPv6 rules are stated later, could you insert "IPv4" before "packets" ? * Section 3 para 3, says SHOULD use IPv6 UDP Checksum, which is fine, but then it leaves open the possibility that an implementation may not (i.es.this is more than the base IPv6 sepcification). I think if you choose SHOULD rather MUST there should at least be some statement that points to RFC6936 (e.g. section 2 explains the function of this check, and section 5 decsribes the additional functions that would need to be defined to allow this encapsulation to use a zero IPv6 UDP Checksum.) * Section 3 para 5, The Congestion Control statement is true if the IP traffic implements Congestion Control, so I'm not sure I buy "no need to apply", and would prefer the statement in RFC 5405, which carefully says: "IP-based traffic is generally assumed to be congestion-controlled, i.e., it is assumed that the transport protocols generating IP-based traffic at the sender already employ mechanisms that are sufficient to address congestion on the path. Consequently, a tunnel carrying IP-based traffic should already interact appropriately with other traffic sharing the path, and specific congestion control mechanisms for the tunnel are not necessary." - Citing RFC 5405 (or successor) may help clarify this. * The current revision syas: " In the absence of either, a congestion control mechanism SHOULD be implemented at the tunnel ingress and egress." - The "Circuit-Breaker" draft is not really a form of congestion control, as currently written. A circuit-breaker is intended primarily to terminate traffic that is persistently thought to cause congestion. I think this is actually what is intended. * I am dubious whether it is sufficient to say you need to do "something", personally I'd much rather see something that says you MUST implement XXXX, and you SHOULD use it under YYY conditions. It would be fine to explain that well-provisioned or controlled environments...etc... provide other equivalent mechanisms that would allow an operator to not use this. I don't see the point in writing a spec that says you need to invent another mechanism to deploy it. - How hard can it be to identify the best type of circuit breaker for this case and require the sender and receiver implementers counters per source address/source port pair? * Section 4. / Tunnel ingress SHOULD/ ^ Insert "the" * SHOULD perform fragmentation ... and if it does not, then what happens, please specify what happens when the recommendation is not applied. * "impact network performance and user experience." - true, but I think you should be more precise, e.g. refer to section 1.3 of RFC6936, where various limitations were explained. * Section 5 "Upon receiving this ICMP message, the tunnel ingress MUST NOT continue to use GRE-in-UDP encapsulation toward this tunnel egress without management intervention." - but also the ingress MUST validate the IP address originating the ICMP message is an address of an active tunnel and MUST evaluate the packet header returned in the ICMP payload to ensure the source port is the one used for this tunnel. The draft should also note that how to handle tunnels carrying other tunnels :-) Gorry On 02/07/2014 14:32, Lucy yong wrote: > Hello, > > The new version is uploaded. It addresses the comments in London's meeting, i.e. congestion control, checksum, etc. Please let us know if the description is sufficient in this version. Other comments are welcome. > > Thanks, > Lucy > > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Tuesday, July 01, 2014 2:26 PM > To: i-d-announce@ietf.org > Cc: tsvwg@ietf.org > Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-02.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 Working Group of the IETF. > > Title : Generic UDP Encapsulation for IP Tunneling > Authors : Edward Crabbe > Lucy Yong > Xiaohu Xu > Filename : draft-ietf-tsvwg-gre-in-udp-encap-02.txt > Pages : 13 > Date : 2014-07-01 > > Abstract: > This document describes a method of encapsulating arbitrary > protocols within GRE and UDP headers. In this encapsulation, the > source UDP port may be used as an entropy field for purposes of load > balancing while the payload protocol may be identified by the GRE > Protocol Type. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-gre-in-udp-encap-02 > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > From nobody Tue Jul 8 10:45:42 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0738F1A036D for ; Tue, 8 Jul 2014 10:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 pTGKb2umSt-F for ; Tue, 8 Jul 2014 10:45:34 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF0F21A03D6 for ; Tue, 8 Jul 2014 10:45:33 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id k14so6299046wgh.27 for ; Tue, 08 Jul 2014 10:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CC0Gmxc+EtdccdzwKC9BqHWhJcIfATlTrxHXs69e2YY=; b=TQFoFYCf6CG4OMwZZ2Y2h3SEz10j42BgW7j03WnWvVjGKVbErV29Q4/WbE7zieLSiU 3WgPrK67CTyEmSEI+5A50k5K7MqlxF6mXE0Zk47VKx4ugvWbFbP9Y77fXezjhm/hdTxo e7OfupcmUXVLNNdw8NsUFyJa/pSGo9/5ntt48vaELHeHeAZhoSKu36+evG/V/jtpxfz+ dOyvOj0/gqhHPiawXoYJf4PUoCTY0LW8FFGHHUw9lP+J6zF9+CPdWDCec4a39wH1CAqY VfIB5YXQTQIeYQVwmAJ9qTDGwJ12tc0xMESZxuffZLIPPhm6dcT4wvIrcXbzdcABrGDG 8K3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CC0Gmxc+EtdccdzwKC9BqHWhJcIfATlTrxHXs69e2YY=; b=a84mFA8S7FgYda553Kz7hoJKuaafJJPX4SkmAUmJZ4FwIvqY6GrrhHPWBd+vqoEl+d iVYsyuYg9/i6iy4Sji2B2E2Scjb9gxRzf84/XyK+A6FhWYNGXGG6Byup2wISHBcVoJbp agrXmP1lTuaqwCWdRL+Q5AmwGRZXZzghDldDyw45RgVQsC14kwYSVXHYL/nAp7YwTqEO AA9BeH5kiuW1nY6wm+uV3dYPubVU1a1n/DnTU2+hoc8KEkL5+L7bConfmrXH+m1mcPbh 1KVPwZwbnX73iIvVRc2u0YRpUOCFM7fA0JtAY3LIwUYJutkcqmXyCw610JWLHip/oOL9 vu1Q== X-Gm-Message-State: ALoCoQnwuhlqLFhOMv7h6swEyvkvZTQ9CfzBylG2eFVI7sa3jNuBvqFVPlr8eBtfO7DaZAURdsq5 X-Received: by 10.194.133.1 with SMTP id oy1mr41838068wjb.87.1404841532396; Tue, 08 Jul 2014 10:45:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.120.228 with HTTP; Tue, 8 Jul 2014 10:44:52 -0700 (PDT) In-Reply-To: <53BC1059.4000905@erg.abdn.ac.uk> References: <2691CE0099834E4A9C5044EEC662BB9D453B0EFA@dfweml701-chm.china.huawei.com> <53BC1059.4000905@erg.abdn.ac.uk> From: Edward Crabbe Date: Tue, 8 Jul 2014 10:44:52 -0700 Message-ID: To: Gorry Fairhurst Content-Type: multipart/alternative; boundary=089e01228d46813a6904fdb22828 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/Y82Kv-vZnvMkf6EaHb5arOIW-lY Cc: "draft-ietf-tsvwg-gre-in-udp-encap@tools.ietf.org" , tsvwg WG Subject: Re: [tsvwg] FW: I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 17:45:38 -0000 --089e01228d46813a6904fdb22828 Content-Type: text/plain; charset=ISO-8859-1 Gorry, thank you for the comments. Implicit agreement where not noted, with explicit disagreements inline: On Tue, Jul 8, 2014 at 8:38 AM, Gorry Fairhurst wrote: > I have some comments on this draft as an individual, please see below: > > * First, I think the new revision helps explain some of the questions that > were highlighted, thanks for preparing the update. > > * section 3 > "randomly selected constant value, e.g. zero," > - I don't understand this in two ways: > (1) I don't think it should be zero, I think you could find a hash of some > internal state to generate a ramdom number. For instance this is used in > the PIM routing (RFC4601) to specify the genID which is simply a unique > number each time the system reboots or the session is restarted (this has > the advantage of reseting state after a reboot). > (2) setting it to zero means you wont have any entropy for ECMP, so why is > this mode specified in this draft - or is for more general use? > > * Section 3 para 3 - "packets destined > to this assigned UDP destination port [TBD] MAY have their UDP > checksum set to zero." > I think the first specification here applies only to IPv4, sicne IPv6 > rules are stated later, could you insert "IPv4" before "packets" ? > > * Section 3 para 3, says SHOULD use IPv6 UDP Checksum, which is fine, but > then it leaves open the possibility that an implementation may not > (i.es.this is more than the base IPv6 sepcification). I think if you choose > SHOULD rather MUST there should at least be some statement that points to > RFC6936 (e.g. section 2 explains the function of this check, and section 5 > decsribes the additional functions that would need to be defined to allow > this encapsulation to use a zero IPv6 UDP Checksum.) > > * Section 3 para 5, The Congestion Control statement is true if the IP > traffic implements Congestion Control, so I'm not sure I buy "no need to > apply", and would prefer the statement in RFC 5405, which carefully says: > > "IP-based traffic is generally assumed to be congestion-controlled, > i.e., it is assumed that the transport protocols generating IP-based > traffic at the sender already employ mechanisms that are sufficient > to address congestion on the path. Consequently, a tunnel carrying > IP-based traffic should already interact appropriately with other > traffic sharing the path, and specific congestion control mechanisms > for the tunnel are not necessary." > > - Citing RFC 5405 (or successor) may help clarify this. > > * The current revision syas: " In the absence of either, a congestion > control mechanism SHOULD be implemented at the tunnel ingress and > egress." > - The "Circuit-Breaker" draft is not really a form of congestion control, > as currently written. A circuit-breaker is intended primarily to terminate > traffic that is persistently thought to cause congestion. I think this is > actually what is intended. > > * I am dubious whether it is sufficient to say you need to do "something", > personally I'd much rather see something that says you MUST implement XXXX, > and you SHOULD use it under YYY conditions. It would be fine to explain > that well-provisioned or controlled environments...etc... provide other > equivalent mechanisms that would allow an operator to not use this. I don't > see the point in writing a spec that says you need to invent another > mechanism to deploy it. > > [ed] we had discussed this in reference to the as the transport area meeting and come to the agreement that SHOULD was sufficient. Specifically: if someone is operating this only on an intradomain basis without interdomain traversal, they should not have to implement 'the circuit breaker'. Regardless, is it sufficient to say that for an interdomain use case where the traffic is not congestion controlled at the source, a circuitbreaker MUST be implemented? > - How hard can it be to identify the best type of circuit breaker for this > case and require the sender and receiver implementers counters per source > address/source port pair? > > * Section 4. > / Tunnel ingress SHOULD/ > ^ Insert "the" > > * SHOULD perform fragmentation ... and if it does not, then what happens, > please specify what happens when the recommendation is not applied. > > * "impact network performance and user experience." > - true, but I think you should be more precise, e.g. refer to section 1.3 > of RFC6936, where various limitations were explained. > > * Section 5 > "Upon receiving this ICMP message, the tunnel > ingress MUST NOT continue to use GRE-in-UDP encapsulation toward > this tunnel egress without management intervention." > - but also the ingress MUST validate the IP address originating the ICMP > message is an address of an active tunnel and MUST evaluate the packet > header returned in the ICMP payload to ensure the source port is the one > used for this tunnel. The draft should also note that how to handle tunnels > carrying other tunnels :-) > > Gorry > > > On 02/07/2014 14:32, Lucy yong wrote: > >> Hello, >> >> The new version is uploaded. It addresses the comments in London's >> meeting, i.e. congestion control, checksum, etc. Please let us know if the >> description is sufficient in this version. Other comments are welcome. >> >> Thanks, >> Lucy >> >> -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Tuesday, July 01, 2014 2:26 PM >> To: i-d-announce@ietf.org >> Cc: tsvwg@ietf.org >> Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-02.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 Working >> Group of the IETF. >> >> Title : Generic UDP Encapsulation for IP Tunneling >> Authors : Edward Crabbe >> Lucy Yong >> Xiaohu Xu >> Filename : draft-ietf-tsvwg-gre-in-udp-encap-02.txt >> Pages : 13 >> Date : 2014-07-01 >> >> Abstract: >> This document describes a method of encapsulating arbitrary >> protocols within GRE and UDP headers. In this encapsulation, the >> source UDP port may be used as an entropy field for purposes of load >> balancing while the payload protocol may be identified by the GRE >> Protocol Type. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-gre-in-udp-encap-02 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> > --089e01228d46813a6904fdb22828 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Gorry, thank you for the comments. =A0Implicit agreement w= here not noted, with explicit disagreements inline:


On Tue, Jul 8, 2014 at 8:38 AM, Gorry= Fairhurst <gorry@erg.abdn.ac.uk> wrote:
I have some comments on this draft as an ind= ividual, please see below:

* First, I think the new revision helps explain some of the questions that = were highlighted, thanks for preparing the update.

* section 3
"randomly selected constant value, e.g. zero,"
- I don't understand this in two ways:
(1) I don't think it should be zero, I think you could find a hash of s= ome internal state to generate a ramdom number. For instance this is used i= n the PIM routing (RFC4601) to specify the genID which is simply a unique n= umber each time the system reboots or the session is restarted (this has th= e advantage of reseting state after a reboot).
(2) setting it to zero means you wont have any entropy for ECMP, so why is = this mode specified in this draft - or is for more general use?

* Section 3 para 3 - "packets destined
=A0 =A0to this assigned UDP destination port [TBD] MAY have their UDP
=A0 =A0checksum set to zero."
I think the first specification here applies only to IPv4, sicne IPv6 rules= are stated later, could you insert "IPv4" before "packets&q= uot; ?

* Section 3 para 3, says SHOULD use IPv6 UDP Checksum, which is fine, but t= hen it leaves open the possibility that an implementation may not (i.es.thi= s is more than the base IPv6 sepcification). I think if you choose SHOULD r= ather MUST there should at least be some statement that points to RFC6936 (= e.g. section 2 explains the function of this check, and section 5 decsribes= the additional functions that would need to be defined to allow this encap= sulation to use a zero IPv6 UDP Checksum.)

* Section 3 para 5, The Congestion Control statement is true if the IP traf= fic implements Congestion Control, so I'm not sure I buy "no need = to apply", and would prefer the statement in RFC 5405, which carefully= says:

=A0 "IP-based traffic is generally assumed to be congestion-controlled= ,
=A0 =A0i.e., it is assumed that the transport protocols generating IP-based=
=A0 =A0traffic at the sender already employ mechanisms that are sufficient<= br> =A0 =A0to address congestion on the path. =A0Consequently, a tunnel carryin= g
=A0 =A0IP-based traffic should already interact appropriately with other =A0 =A0traffic sharing the path, and specific congestion control mechanisms=
=A0 =A0for the tunnel are not necessary."

- Citing RFC 5405 (or successor) may help clarify this.

* The current revision syas: " In the absence of either, a congestion = =A0
control mechanism SHOULD be implemented at the tunnel ingress and =A0 =A0 = =A0
egress."
- The "Circuit-Breaker" draft is not really a form of congestion = control, as currently written. A circuit-breaker is intended primarily to t= erminate traffic that is persistently thought to cause congestion. I think = this is actually what is intended.

* I am dubious whether it is sufficient to say you need to do "somethi= ng", personally I'd much rather see something that says you MUST i= mplement XXXX, and you SHOULD use it under YYY conditions. It would be fine= to explain that well-provisioned or controlled environments...etc... provi= de other equivalent mechanisms that would allow an operator to not use this= . I don't see the point in writing a spec that says you need to invent = another mechanism to deploy it.


[ed] we had discussed this in referenc= e to the as the transport area meeting and come to the agreement that SHOUL= D was sufficient. =A0Specifically: =A0if someone is operating this only on = an intradomain basis without interdomain traversal, they should not have to= implement 'the circuit breaker'. =A0
=A0
Regardless, is it sufficient to say that for an inte= rdomain use case where the traffic is not congestion controlled at the sour= ce, a circuitbreaker MUST be implemented?

=A0
- How hard can it be to identify the best type of circuit breaker for this = case and require the sender and receiver implementers counters per source a= ddress/source port pair?

* Section 4.
/ Tunnel ingress SHOULD/
^ Insert "the"

* SHOULD perform fragmentation ... and if it does not, then what happens, p= lease specify what happens when the recommendation is not applied.

* "impact network performance and user experience."
- true, but I think you should be more precise, e.g. refer to section 1.3 o= f RFC6936, where various limitations were explained.

* Section 5
=A0 =A0"Upon receiving this ICMP message, the tunnel
=A0 =A0ingress MUST NOT continue to use GRE-in-UDP encapsulation toward
=A0 =A0this tunnel egress without management intervention."
- but also the ingress MUST validate the IP address originating the ICMP me= ssage is an address of an active tunnel and MUST evaluate the packet header= returned in the ICMP payload to ensure the source port is the one used for= this tunnel. The draft should also note that how to handle tunnels carryin= g other tunnels :-)

Gorry


On 02/07/2014 14:32, Lucy yong wrote:
Hello,

The new version is uploaded. It addresses the comments in London's meet= ing, i.e. congestion control, checksum, etc. Please let us know if the desc= ription is sufficient in this version. Other comments are welcome.

Thanks,
Lucy

-----Original Message-----
From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
Sent: Tuesday, July 01, 2014 2:26 PM
To: i-d-announce= @ietf.org
Cc: tsvwg@ietf.org<= br> Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-02.tx= t


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0 This draft is a work item of the Transport Area Working Group Working G= roup of the IETF.

=A0 =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Generic UDP Encapsulation fo= r IP Tunneling
=A0 =A0 =A0 =A0 =A0Authors =A0 =A0 =A0 =A0 : Edward Crabbe
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Lucy Yong
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Xiaohu Xu
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-tsvwg-gre-in-udp-encap-02.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 13
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-07-01

Abstract:
=A0 =A0 This document describes a method of encapsulating arbitrary
=A0 =A0 protocols within GRE and UDP headers. =A0In this encapsulation, the=
=A0 =A0 source UDP port may be used as an entropy field for purposes of loa= d
=A0 =A0 balancing while the payload protocol may be identified by the GRE =A0 =A0 Protocol Type.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-t= svwg-gre-in-udp-encap/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-gre-i= n-udp-encap-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-= ietf-tsvwg-gre-in-udp-encap-02


Please note that it may take a couple of minutes from the time of submissio= n 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/



--089e01228d46813a6904fdb22828-- From nobody Tue Jul 8 11:43:36 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4751A0409 for ; Tue, 8 Jul 2014 11:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 pitbMIFbnz84 for ; Tue, 8 Jul 2014 11:43:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F6D91A0403 for ; Tue, 8 Jul 2014 11:43:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJT48265; Tue, 08 Jul 2014 18:43:26 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Jul 2014 19:43:26 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml704-chm.china.huawei.com ([169.254.6.218]) with mapi id 14.03.0158.001; Tue, 8 Jul 2014 11:43:15 -0700 From: Lucy yong To: Edward Crabbe , Gorry Fairhurst Thread-Topic: [tsvwg] FW: I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-02.txt Thread-Index: AQHPmtR6mQ9n4xDD9EK1t0Kmgp/n/ZuWdong Date: Tue, 8 Jul 2014 18:43:14 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453BD8E3@dfweml701-chm.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D453B0EFA@dfweml701-chm.china.huawei.com> <53BC1059.4000905@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.127] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D453BD8E3dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/wrUxLttrN6CrZjx4K2ZyHJPnfuE Cc: "draft-ietf-tsvwg-gre-in-udp-encap@tools.ietf.org" , tsvwg WG Subject: Re: [tsvwg] FW: I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 18:43:34 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D453BD8E3dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gorry, Yes, thank you for the review and comments. Please see inline. From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Edward Crabbe Sent: Tuesday, July 08, 2014 12:45 PM To: Gorry Fairhurst Cc: draft-ietf-tsvwg-gre-in-udp-encap@tools.ietf.org; tsvwg WG Subject: Re: [tsvwg] FW: I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-02.t= xt Gorry, thank you for the comments. Implicit agreement where not noted, wit= h explicit disagreements inline: On Tue, Jul 8, 2014 at 8:38 AM, Gorry Fairhurst > wrote: I have some comments on this draft as an individual, please see below: * First, I think the new revision helps explain some of the questions that = were highlighted, thanks for preparing the update. * section 3 "randomly selected constant value, e.g. zero," - I don't understand this in two ways: (1) I don't think it should be zero, I think you could find a hash of some = internal state to generate a random number. For instance this is used in th= e PIM routing (RFC4601) to specify the genID which is simply a unique numbe= r each time the system reboots or the session is restarted (this has the ad= vantage of reseting state after a reboot). (2) setting it to zero means you wont have any entropy for ECMP, so why is = this mode specified in this draft - or is for more general use? [Lucy] how about "a randomly selected constant value"? The reason we mentio= n this method here is to address the case when ingress is unable to differe= ntiate the flows from the received packets. In this case, the ingress sets = a same value for all the packets. If ingress is able to generate the entrop= y value from the flows, the entropy value is used at source UDP. Regarding the method for selecting the value, it simply can use the time va= lue at boot up time. However I prefer to leave the algorithm for selecting = the value outside scope of the draft. Will that be acceptable? * Section 3 para 3 - "packets destined to this assigned UDP destination port [TBD] MAY have their UDP checksum set to zero." I think the first specification here applies only to IPv4, sicne IPv6 rules= are stated later, could you insert "IPv4" before "packets" ? [Lucy] OK. * Section 3 para 3, says SHOULD use IPv6 UDP Checksum, which is fine, but t= hen it leaves open the possibility that an implementation may not (i.es.thi= s is more than the base IPv6 sepcification). I think if you choose SHOULD r= ather MUST there should at least be some statement that points to RFC6936 (= e.g. section 2 explains the function of this check, and section 5 decsribes= the additional functions that would need to be defined to allow this encap= sulation to use a zero IPv6 UDP Checksum.) [Lucy] will use "MUST" here. Thus no need to refer to RFC6936. * Section 3 para 5, The Congestion Control statement is true if the IP traf= fic implements Congestion Control, so I'm not sure I buy "no need to apply"= , and would prefer the statement in RFC 5405, which carefully says: "IP-based traffic is generally assumed to be congestion-controlled, i.e., it is assumed that the transport protocols generating IP-based traffic at the sender already employ mechanisms that are sufficient to address congestion on the path. Consequently, a tunnel carrying IP-based traffic should already interact appropriately with other traffic sharing the path, and specific congestion control mechanisms for the tunnel are not necessary." - Citing RFC 5405 (or successor) may help clarify this. [Lucy] Thanks for the suggestion. We will take your suggestion. * The current revision syas: " In the absence of either, a congestion control mechanism SHOULD be implemented at the tunnel ingress and egress." - The "Circuit-Breaker" draft is not really a form of congestion control, a= s currently written. A circuit-breaker is intended primarily to terminate t= raffic that is persistently thought to cause congestion. I think this is ac= tually what is intended. [Lucy] We will not describe Circuit-breaker in this draft but cite the CB d= raft. Terminating traffic is one way to reduce the congestion. Will "conges= tion handling mechanism" is acceptable? Lucy * I am dubious whether it is sufficient to say you need to do "something", = personally I'd much rather see something that says you MUST implement XXXX,= and you SHOULD use it under YYY conditions. It would be fine to explain th= at well-provisioned or controlled environments...etc... provide other equiv= alent mechanisms that would allow an operator to not use this. I don't see = the point in writing a spec that says you need to invent another mechanism = to deploy it. [ed] we had discussed this in reference to the as the transport area meetin= g and come to the agreement that SHOULD was sufficient. Specifically: if = someone is operating this only on an intradomain basis without interdomain = traversal, they should not have to implement 'the circuit breaker'. Regardless, is it sufficient to say that for an interdomain use case where = the traffic is not congestion controlled at the source, a circuitbreaker MU= ST be implemented? - How hard can it be to identify the best type of circuit breaker for this = case and require the sender and receiver implementers counters per source a= ddress/source port pair? * Section 4. / Tunnel ingress SHOULD/ ^ Insert "the" * SHOULD perform fragmentation ... and if it does not, then what happens, p= lease specify what happens when the recommendation is not applied. * "impact network performance and user experience." - true, but I think you should be more precise, e.g. refer to section 1.3 o= f RFC6936, where various limitations were explained. * Section 5 "Upon receiving this ICMP message, the tunnel ingress MUST NOT continue to use GRE-in-UDP encapsulation toward this tunnel egress without management intervention." - but also the ingress MUST validate the IP address originating the ICMP me= ssage is an address of an active tunnel and MUST evaluate the packet header= returned in the ICMP payload to ensure the source port is the one used for= this tunnel. The draft should also note that how to handle tunnels carryin= g other tunnels :-) Gorry On 02/07/2014 14:32, Lucy yong wrote: Hello, The new version is uploaded. It addresses the comments in London's meeting,= i.e. congestion control, checksum, etc. Please let us know if the descript= ion is sufficient in this version. Other comments are welcome. Thanks, Lucy -----Original Message----- From: tsvwg [mailto:tsvwg-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Tuesday, July 01, 2014 2:26 PM To: i-d-announce@ietf.org Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Gro= up of the IETF. Title : Generic UDP Encapsulation for IP Tunneling Authors : Edward Crabbe Lucy Yong Xiaohu Xu Filename : draft-ietf-tsvwg-gre-in-udp-encap-02.txt Pages : 13 Date : 2014-07-01 Abstract: This document describes a method of encapsulating arbitrary protocols within GRE and UDP headers. In this encapsulation, the source UDP port may be used as an entropy field for purposes of load balancing while the payload protocol may be identified by the GRE Protocol Type. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-gre-in-udp-encap-02 Please note that it may take a couple of minutes from the time of submissio= n 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/ --_000_2691CE0099834E4A9C5044EEC662BB9D453BD8E3dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Gorry,

 <= /p>

Yes, thank you for the re= view and comments. Please see inline.

 <= /p>

From: tsvwg [m= ailto:tsvwg-bounces@ietf.org] On Behalf Of Edward Crabbe
Sent: Tuesday, July 08, 2014 12:45 PM
To: Gorry Fairhurst
Cc: draft-ietf-tsvwg-gre-in-udp-encap@tools.ietf.org; tsvwg WG
Subject: Re: [tsvwg] FW: I-D Action: draft-ietf-tsvwg-gre-in-udp-enc= ap-02.txt

 

Gorry, thank you for the comments.  Implicit ag= reement where not noted, with explicit disagreements inline:

 

On Tue, Jul 8, 2014 at 8:38 AM, Gorry Fairhurst <= gorry@erg.abdn.ac= .uk> wrote:

I have some comments = on this draft as an individual, please see below:

* First, I think the new revision helps explain some of the questions that = were highlighted, thanks for preparing the update.

* section 3
"randomly selected constant value, e.g. zero,"
- I don't understand this in two ways:
(1) I don't think it should be zero, I think you could find a hash of some = internal state to generate a random number. For instance this is used in th= e PIM routing (RFC4601) to specify the genID which is simply a unique numbe= r each time the system reboots or the session is restarted (this has the advantage of reseting state after a= reboot).
(2) setting it to zero means you wont have any entropy for ECMP, so why is = this mode specified in this draft - or is for more general use?

[Lucy] how about “a randomly selected constant value̶= 1;? The reason we mention this method here is to address the case when ingress is unable to differentiate the flows from the received packets. In= this case, the ingress sets a same value for all the packets. If ingress i= s able to generate the entropy value from the flows, the entropy value is u= sed at source UDP.

Regarding the method for selecting the value, it simply can use= the time value at boot up time. However I prefer to leave the algorithm for selecting the value outside scope of the draft. Will tha= t be acceptable?



* Section 3 para 3 - "packets destined
   to this assigned UDP destination port [TBD] MAY have their UDP=
   checksum set to zero."
I think the first specification here applies only to IPv4, sicne IPv6 rules= are stated later, could you insert "IPv4" before "packets&q= uot; ?

[Lucy] OK.



* Section 3 para 3, says SHOULD use IPv6 UDP Checksum, which is fine, but t= hen it leaves open the possibility that an implementation may not (i.es.thi= s is more than the base IPv6 sepcification). I think if you choose SHOULD r= ather MUST there should at least be some statement that points to RFC6936 (e.g. section 2 explains the func= tion of this check, and section 5 decsribes the additional functions that w= ould need to be defined to allow this encapsulation to use a zero IPv6 UDP = Checksum.)

[Lucy] will use “MUST” here. Thus no need to refer = to RFC6936.



* Section 3 para 5, The Congestion Control statement is true if the IP traf= fic implements Congestion Control, so I'm not sure I buy "no need to a= pply", and would prefer the statement in RFC 5405, which carefully say= s:

  "IP-based traffic is generally assumed to be congestion-control= led,
   i.e., it is assumed that the transport protocols generating IP= -based
   traffic at the sender already employ mechanisms that are suffi= cient
   to address congestion on the path.  Consequently, a tunne= l carrying
   IP-based traffic should already interact appropriately with ot= her
   traffic sharing the path, and specific congestion control mech= anisms
   for the tunnel are not necessary."



- Citing RFC 5405 (or successor) may help clarify this.

[Lucy] Thanks for the suggestion. We will take your suggestion.=

 



* The current revision syas: " In the absence of either, a congestion =  
control mechanism SHOULD be implemented at the tunnel ingress and   &n= bsp;  
egress."
- The "Circuit-Breaker" draft is not really a form of congestion = control, as currently written. A circuit-breaker is intended primarily to t= erminate traffic that is persistently thought to cause congestion. I think = this is actually what is intended.=

[Lucy] We will not describe Circuit-breaker in this draft but c= ite the CB draft. Terminating traffic is one way to reduce the congestion. Will “congestion handling mechanism” is accept= able?  

Lucy



* I am dubious whether it is sufficient to say you need to do "somethi= ng", personally I'd much rather see something that says you MUST imple= ment XXXX, and you SHOULD use it under YYY conditions. It would be fine to = explain that well-provisioned or controlled environments...etc... provide other equivalent mechanisms that would allow= an operator to not use this. I don't see the point in writing a spec that = says you need to invent another mechanism to deploy it.

 

[ed] we had discussed this in reference to the as th= e transport area meeting and come to the agreement that SHOULD was sufficie= nt.  Specifically:  if someone is operating this only on an intra= domain basis without interdomain traversal, they should not have to implement 'the circuit breaker'.  =

 

Regardless, is it sufficient to say that for an inte= rdomain use case where the traffic is not congestion controlled at the sour= ce, a circuitbreaker MUST be implemented?

 

 

- How hard can it be to identify the best type of ci= rcuit breaker for this case and require the sender and receiver implementer= s counters per source address/source port pair?

* Section 4.
/ Tunnel ingress SHOULD/
^ Insert "the"

* SHOULD perform fragmentation ... and if it does not, then what happens, p= lease specify what happens when the recommendation is not applied.

* "impact network performance and user experience."
- true, but I think you should be more precise, e.g. refer to section 1.3 o= f RFC6936, where various limitations were explained.

* Section 5
   "Upon receiving this ICMP message, the tunnel
   ingress MUST NOT continue to use GRE-in-UDP encapsulation towa= rd
   this tunnel egress without management intervention."
- but also the ingress MUST validate the IP address originating the ICMP me= ssage is an address of an active tunnel and MUST evaluate the packet header= returned in the ICMP payload to ensure the source port is the one used for= this tunnel. The draft should also note that how to handle tunnels carrying other tunnels :-)

Gorry



On 02/07/2014 14:32, Lucy yong wrote:

Hello,

The new version is uploaded. It addresses the comments in London's meeting,= i.e. congestion control, checksum, etc. Please let us know if the descript= ion is sufficient in this version. Other comments are welcome.

Thanks,
Lucy

-----Original Message-----
From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of internet-draf= ts@ietf.org
Sent: Tuesday, July 01, 2014 2:26 PM
To: i-d-announce= @ietf.org
Cc: tsvwg@ietf.org<= br> Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
  This draft is a work item of the Transport Area Working Group Workin= g Group of the IETF.

         Title           = : Generic UDP Encapsulation for IP Tunneling
         Authors         : Edw= ard Crabbe
                     = ;      Lucy Yong
                     = ;      Xiaohu Xu
        Filename        : draft-iet= f-tsvwg-gre-in-udp-encap-02.txt
        Pages           : 13         Date            := 2014-07-01

Abstract:
    This document describes a method of encapsulating arbitrary     protocols within GRE and UDP headers.  In this encapsula= tion, the
    source UDP port may be used as an entropy field for purposes = of load
    balancing while the payload protocol may be identified by the= GRE
    Protocol Type.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gr= e-in-udp-encap/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-e= ncap-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ts= vwg-gre-in-udp-encap-02


Please note that it may take a couple of minutes from the time of submissio= n 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/

 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D453BD8E3dfweml701chmchi_-- From nobody Tue Jul 8 12:56:37 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5A61A0004 for ; Tue, 8 Jul 2014 12:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 DrSvrJ8wlJUP for ; Tue, 8 Jul 2014 12:56:33 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id ECC4A1A0002 for ; Tue, 8 Jul 2014 12:56:32 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id AF7042B43C0; Tue, 8 Jul 2014 20:56:31 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Tue, 8 Jul 2014 20:56:31 +0100 Message-ID: <8dad8c10db7dc5241eedf1f8f06d2e8e.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453BD8E3@dfweml701-chm.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D453B0EFA@dfweml701-chm.china.huawei.com> <53BC1059.4000905@erg.abdn.ac.uk> <2691CE0099834E4A9C5044EEC662BB9D453BD8E3@dfweml701-chm.china.huawei.com> Date: Tue, 8 Jul 2014 20:56:31 +0100 From: gorry@erg.abdn.ac.uk To: "Lucy yong" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/nHVDq1jdM-Roq1hTWBGmi5-PXYg Cc: Gorry Fairhurst , "draft-ietf-tsvwg-gre-in-udp-encap@tools.ietf.org" , tsvwg WG Subject: Re: [tsvwg] FW: I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 19:56:36 -0000 Thanks, See some responses in-line, Gorry > Hi Gorry, > > Yes, thank you for the review and comments. Please see inline. > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Edward Crabbe > Sent: Tuesday, July 08, 2014 12:45 PM > To: Gorry Fairhurst > Cc: draft-ietf-tsvwg-gre-in-udp-encap@tools.ietf.org; tsvwg WG > Subject: Re: [tsvwg] FW: I-D Action: > draft-ietf-tsvwg-gre-in-udp-encap-02.txt > > Gorry, thank you for the comments. Implicit agreement where not noted, > with explicit disagreements inline: > > On Tue, Jul 8, 2014 at 8:38 AM, Gorry Fairhurst > > wrote: > I have some comments on this draft as an individual, please see below: > > * First, I think the new revision helps explain some of the questions that > were highlighted, thanks for preparing the update. > > * section 3 > "randomly selected constant value, e.g. zero," > - I don't understand this in two ways: > (1) I don't think it should be zero, I think you could find a hash of some > internal state to generate a random number. For instance this is used in > the PIM routing (RFC4601) to specify the genID which is simply a unique > number each time the system reboots or the session is restarted (this has > the advantage of reseting state after a reboot). > (2) setting it to zero means you wont have any entropy for ECMP, so why is > this mode specified in this draft - or is for more general use? > [Lucy] how about "a randomly selected constant value"? The reason we > mention this method here is to address the case when ingress is unable to > differentiate the flows from the received packets. In this case, the > ingress sets a same value for all the packets. If ingress is able to > generate the entropy value from the flows, the entropy value is used at > source UDP. > Regarding the method for selecting the value, it simply can use the time > value at boot up time. However I prefer to leave the algorithm for > selecting the value outside scope of the draft. Will that be acceptable? > GF: That makes sense - I agree, you could give an example, but I wouldn't expect the ID to specify the algorithm for initialising the value. > > * Section 3 para 3 - "packets destined > to this assigned UDP destination port [TBD] MAY have their UDP > checksum set to zero." > I think the first specification here applies only to IPv4, sicne IPv6 > rules are stated later, could you insert "IPv4" before "packets" ? > [Lucy] OK. > > > * Section 3 para 3, says SHOULD use IPv6 UDP Checksum, which is fine, but > then it leaves open the possibility that an implementation may not > (i.es.this is more than the base IPv6 sepcification). I think if you > choose SHOULD rather MUST there should at least be some statement that > points to RFC6936 (e.g. section 2 explains the function of this check, and > section 5 decsribes the additional functions that would need to be defined > to allow this encapsulation to use a zero IPv6 UDP Checksum.) > [Lucy] will use "MUST" here. Thus no need to refer to RFC6936. > GF: Either way works for me. MUST for IPv6 is obviously easy to get agreement upon. > > * Section 3 para 5, The Congestion Control statement is true if the IP > traffic implements Congestion Control, so I'm not sure I buy "no need to > apply", and would prefer the statement in RFC 5405, which carefully says: > > "IP-based traffic is generally assumed to be congestion-controlled, > i.e., it is assumed that the transport protocols generating IP-based > traffic at the sender already employ mechanisms that are sufficient > to address congestion on the path. Consequently, a tunnel carrying > IP-based traffic should already interact appropriately with other > traffic sharing the path, and specific congestion control mechanisms > for the tunnel are not necessary." > > > - Citing RFC 5405 (or successor) may help clarify this. > [Lucy] Thanks for the suggestion. We will take your suggestion. > > > > * The current revision syas: " In the absence of either, a congestion > control mechanism SHOULD be implemented at the tunnel ingress and > egress." > - The "Circuit-Breaker" draft is not really a form of congestion control, > as currently written. A circuit-breaker is intended primarily to terminate > traffic that is persistently thought to cause congestion. I think this is > actually what is intended. > > [Lucy] We will not describe Circuit-breaker in this draft but cite the CB > draft. Terminating traffic is one way to reduce the congestion. > Will "congestion handling mechanism" be acceptable? > GF: I think that is better. > > > * I am dubious whether it is sufficient to say you need to do "something", > personally I'd much rather see something that says you MUST implement > XXXX, and you SHOULD use it under YYY conditions. It would be fine to > explain that well-provisioned or controlled environments...etc... provide > other equivalent mechanisms that would allow an operator to not use this. > I don't see the point in writing a spec that says you need to invent > another mechanism to deploy it. > > [ed] we had discussed this in reference to the as the transport area > meeting and come to the agreement that SHOULD was sufficient. > Specifically: if someone is operating this only on an intradomain basis > without interdomain traversal, they should not have to implement 'the > circuit breaker'. > GF: That's where we differ, but we need to be precise - I'm not saying an operator MUST use the Circuit breaker, because clearly there are operational characteristics of a network that may mean the operator already has mechanisms to deal with overload. However. the question is whether the implementor needs to provides the mechanism, to allow the operator to enable or disable the feature. This is about what needs to be specified to conform - assuming that a lightweight circuit breaker is possible at design time, but we know from other experience is really hard to introduce afterwards to a deployed protocol. > Regardless, is it sufficient to say that for an interdomain use case where > the traffic is not congestion controlled at the source, a circuitbreaker > MUST be implemented? > GF: Probably correct. But see above. It is possible to use words such as MUST be supported and SHOULD be enabled by default. > > - How hard can it be to identify the best type of circuit breaker for this > case and require the sender and receiver implementers counters per source > address/source port pair? > > * Section 4. > / Tunnel ingress SHOULD/ > ^ Insert "the" > > * SHOULD perform fragmentation ... and if it does not, then what happens, > please specify what happens when the recommendation is not applied. > > * "impact network performance and user experience." > - true, but I think you should be more precise, e.g. refer to section 1.3 > of RFC6936, where various limitations were explained. > > * Section 5 > "Upon receiving this ICMP message, the tunnel > ingress MUST NOT continue to use GRE-in-UDP encapsulation toward > this tunnel egress without management intervention." > - but also the ingress MUST validate the IP address originating the ICMP > message is an address of an active tunnel and MUST evaluate the packet > header returned in the ICMP payload to ensure the source port is the one > used for this tunnel. The draft should also note that how to handle > tunnels carrying other tunnels :-) > > Gorry > > > On 02/07/2014 14:32, Lucy yong wrote: > Hello, > > The new version is uploaded. It addresses the comments in London's > meeting, i.e. congestion control, checksum, etc. Please let us know if the > description is sufficient in this version. Other comments are welcome. > > Thanks, > Lucy > > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] > On Behalf Of internet-drafts@ietf.org > Sent: Tuesday, July 01, 2014 2:26 PM > To: i-d-announce@ietf.org > Cc: tsvwg@ietf.org > Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-02.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 Working > Group of the IETF. > > Title : Generic UDP Encapsulation for IP Tunneling > Authors : Edward Crabbe > Lucy Yong > Xiaohu Xu > Filename : draft-ietf-tsvwg-gre-in-udp-encap-02.txt > Pages : 13 > Date : 2014-07-01 > > Abstract: > This document describes a method of encapsulating arbitrary > protocols within GRE and UDP headers. In this encapsulation, the > source UDP port may be used as an entropy field for purposes of load > balancing while the payload protocol may be identified by the GRE > Protocol Type. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-gre-in-udp-encap-02 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > From nobody Sun Jul 13 15:15:22 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2B31A0199 for ; Sun, 13 Jul 2014 15:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 0X5cgYhmHex6 for ; Sun, 13 Jul 2014 15:15:17 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 4D0271A0197 for ; Sun, 13 Jul 2014 15:15:16 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1X6S38-0002ME-LO for tsvwg@ietf.org; Mon, 14 Jul 2014 00:15:14 +0200 Received: from 089144238029.atnat0047.highway.bob.at ([89.144.238.29] helo=[192.168.0.102]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1X6S37-0000s6-Px for tsvwg@ietf.org; Mon, 14 Jul 2014 00:15:14 +0200 From: Michael Welzl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <1C46064E-81CD-4050-8229-478B6D5CC002@ifi.uio.no> Date: Mon, 14 Jul 2014 00:15:10 +0200 To: tsvwg IETF list Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 3 sum rcpts/h 5 sum msgs/h 3 total rcpts 18318 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 7F3C84AF3468CB6E31F320B7E55F15A6C92E8260 X-UiO-SPAM-Test: remote_host: 89.144.238.29 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 2 max/h 2 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/jqG5srync1J4CZyclbL44Fch5V8 Subject: [tsvwg] =?utf-8?b?ZHJhZnTigJB3ZWx6bOKAkGVjbuKAkGJlbmVmaXRzLTAx?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 22:15:19 -0000 Hi, This is just a heads-up, that Gorry & I will briefly present = draft=E2=80=90welzl=E2=80=90ecn=E2=80=90benefits-01 at TSVWG. Cheers, Michael From nobody Sun Jul 20 06:54:25 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6181B2C46 for ; Sun, 20 Jul 2014 06:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 1pDDYjzNQmad for ; Sun, 20 Jul 2014 06:54:20 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03AD1B2C43 for ; Sun, 20 Jul 2014 06:54:19 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id k48so5203282wev.41 for ; Sun, 20 Jul 2014 06:54:17 -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:content-type; bh=cefnZQ2Rxzi3TnNiMfXXTdZw1m1+4LHgeSuZePbUiQY=; b=CDC0UCUfIiS3XHER3SP2X4tedtfj8PRtFKYXkvFSkNpX5QuxNUuyJLLpygAkNS9aAn og1uFwrDwdT+aeI5qc6m2XcgYpF2Mt5AVQ8QF4xir4Ae6M0AM1T1Ahpbm69uYzDifepB s16z9hGgwaIX5Dl9pqYp2s9ukZ3B2FDAukaWM= 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:content-type; bh=cefnZQ2Rxzi3TnNiMfXXTdZw1m1+4LHgeSuZePbUiQY=; b=Js1NHhHFB5TyrtYhonuFgXYy7Ru659s3OFuMa8Xccs294Tu6IoJH4G+t3LYCxBtli1 IYcw8mh5FDAmFkCPxEpS2+opwHnK5MRGtZelz9+s7MNoqmEId1Jlk659wnuKCDeYzzoH unJcsnUFxp8iX5IJoxzLpX/Zy89zQSKPXErwKio+h98TFkpUvcMRDYk6GUYLzoWelo9l HflAJaCszWsp9MaInmyozFjgSTwN4OmsrGYZsDhxQgrROH94AOUEcCTtgEaxZ1sxiFy9 Mt4B9j6els4Pfphg51qjAavFIc2bYC0AipKzcQSKhB8+Ro6oNDACWdUCKd5mqkWCu97R rPFg== X-Gm-Message-State: ALoCoQmHuAtErQ2Wqooi8BSN2sMqVKyEKCxQMqQq0sKbjI72peMt4LjCOLp+4fsZ+hYr/jI3fouIrTjN1o2/x4IigQm3lnAftQ== X-Received: by 10.180.75.17 with SMTP id y17mr8974321wiv.3.1405864457667; Sun, 20 Jul 2014 06:54:17 -0700 (PDT) From: "Karen E. Egede Nielsen" References: <53B5183A.7060301@erg.abdn.ac.uk> In-Reply-To: <53B5183A.7060301@erg.abdn.ac.uk> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHwV3Bvsfu+NnniT1eiLuUntQkfx5tnj+uw Date: Sun, 20 Jul 2014 15:54:22 +0200 Message-ID: <70e7a15985a5f9f07d6d1ad42b081822@mail.gmail.com> To: gorry@erg.abdn.ac.uk, tsvwg-chairs@ietf.org, tsvwg@ietf.org Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/yFqQ1j3_5zPDIHXyc-XUCKnIWSI Cc: Michael Tuexen Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-prpolicies-03 - due to conclude Monday, July 21st, 2014 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 13:54:22 -0000 HI, I support the extensions of the PR function as defined in the document. I support the work as moving forward as PS. RFC3758 is PS and I do not see that the new policies defined pose any new issues compared to the policy already defined in RFC3758. (I actually do have some petty issues with the text of RFC3758, but these issues are equally applicable to the existing policy of RFC3758 as to the new proposed ones. I will send these comments later.) In respect to the technical scope presently in the document, then I think that the text of the document is in a state ready to publish. I have the following 2 comments to the scope of function as it is right now. #1: Given that we now have multiple PR policies, potentially applicable within the same SCTP association (but likely same policy on all messages within same stream, e.g., media stream/data channel), then I think that it would be relevant to have the stats in the sctp_prstatus be reported on a per policy basis. Meaning that the socket option sctp_prstatus should be extended to make this differentiation. #2: I note that the socket api handing specified in the document for control of whether to attempt to negotiate the function or not, does not adequately handle how to control the operation during restarts (INIT from remote side) of an existing association. However this is a general issue of the socket api as specified in RFC6458 and as it is not particular to the PR function, but general to all negotiable features. I thus recognize that be better addresses in an possible follow up of RFC6458. Whether it be handled as a special purpose function to control the operation via-a-vis negotiable features generally at remote restart of existing association or whether it comes in as a general extension of all the particular functions controlling a negotiable feature. The issue is relevant for SCTP implementations in deployment and is today addressed (at least by some implementations I know of) by proprietary means outside of (but somewhat in interworking with) the socket api. BR, Karen > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Gorry Fairhurst > Sent: 3. juli 2014 10:46 > To: tsvwg-chairs@ietf.org; tsvwg@ietf.org > Subject: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-prpolicies-03 - due to > conclude Monday, July 21st, 2014 > > This is the start of the WGLC on "Additional Policies for the Partial Reliability > Extension of the Stream Control Transmission Protocol" for publication > intended as a PS. > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-prpolicies/ > > This WGLC will last until Monday, July 21st, 2014 (longer since this includes > time prior to an IETF meeting). > > Could people please send *any* comments to the list if they think this is > ready to publish? > > A good note is "I have read this version of the draft, and I approve (or > support) its progression to RFC". > > James/Gorry/David > TSVWG chairs From nobody Sun Jul 20 07:18:58 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F141B280B; Sun, 20 Jul 2014 07:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=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 EuOdR6APjVaU; Sun, 20 Jul 2014 07:18:55 -0700 (PDT) Received: from mailoutzim.uni-due.de (mailoutzim.uni-due.de [132.252.185.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F31A41B2C53; Sun, 20 Jul 2014 07:18:54 -0700 (PDT) Received: from HT02.win.uni-due.de ([132.252.185.215]) by mailoutzim.uni-due.de (8.13.1/8.13.1) with ESMTP id s6KEIpRE022732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 20 Jul 2014 16:18:51 +0200 Received: from ccr02.win.uni-due.de ([169.254.2.187]) by HT02.win.uni-due.de ([132.252.190.234]) with mapi id 14.03.0158.001; Sun, 20 Jul 2014 16:18:51 +0200 From: "Becke, Martin" To: "tsvwg-chairs@ietf.org" , tsvwg WG Thread-Topic: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-prpolicies-03 - due to conclude Monday, July 21st, 2014 Thread-Index: AQHPlps3zRvMRHfUqku7E7//EvqOsJuo9XoAgAAG1IA= Date: Sun, 20 Jul 2014 14:18:49 +0000 Message-ID: <820E555B-152B-4315-B013-2902ADBD41B8@uni-due.de> References: <53B5183A.7060301@erg.abdn.ac.uk> <70e7a15985a5f9f07d6d1ad42b081822@mail.gmail.com> In-Reply-To: <70e7a15985a5f9f07d6d1ad42b081822@mail.gmail.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.252.185.216] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.16 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/Yq6R7ms6wTEidxGcyQ8qgDbUf2o Cc: "" , Michael Tuexen , "Karen E. Egede Nielsen" Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-prpolicies-03 - due to conclude Monday, July 21st, 2014 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 14:18:57 -0000 Am 20.07.2014 um 15:54 schrieb Karen E. Egede Nielsen : > HI, >=20 > I support the extensions of the PR function as defined in the document. +1 Best,=20 Martin From nobody Sun Jul 20 07:34:10 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216871B2819 for ; Sun, 20 Jul 2014 07:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 kzxbsAAZRNXp for ; Sun, 20 Jul 2014 07:34:07 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31AD01A0AE7 for ; Sun, 20 Jul 2014 07:34:07 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id x48so6534944wes.31 for ; Sun, 20 Jul 2014 07:34:05 -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 :content-type; bh=LlSflh1T3EiRgzU+PZXrUSPG4enhws85AOP496e0GA4=; b=qc+PI5qVgHfNlP5BFqKm3Bac2FBIqYe5O5bhH4KpeGmKLU3eygnCM+SemMqKGFYOY4 OPIDfXkWjKiyk4gzVeguq/+gUtkQUpqyeE5RIzwwwz9cRkriDrlYuWHeD6hs6nz0YRFq Dbn/oU8pZTXEVDQDsz2dGMT3X02UJjoRJY88Y= 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:content-type; bh=LlSflh1T3EiRgzU+PZXrUSPG4enhws85AOP496e0GA4=; b=N1VL3UXXZ3w+8QyAvRMI7NWLj8QoVQgrRbbULUV/wC8Q+Cd2Qc10njTgMYUBXIqEs6 RF5aFW9SNFQkqGloEWbtboNO82zdicKR/pJ8Vpk/zY9PyVfi1g9rp+l2LmntInkz7zvo DVpBecSnnqQpiaK8THU2Yy00Dhc0Qz8ejnl/3LNa0QDNVgKsiucxuZpUtjHNyjzXvdQM 5sSjqSvyHFAZaRdrOUlfcLYZCYAkNpXRjpFKnRdi7bi1cfU32g4qRymfK+X/eTaFpp+o DeOu7UWav7GLvM/8pnva0xMR0UPvFhybwRzLTwgG1gNeM7CTvwdmZPc81D4GvFC7pXzc YH3A== X-Gm-Message-State: ALoCoQnLGKTJmGi9z8f2IlH0zVOq/qBZOZe4i5DRhBuJbx1i+Kb17JmIlOKq79UqcN2xKPESzyvD10jtnHxOqzc8AoQqU9FS/A== X-Received: by 10.180.75.17 with SMTP id y17mr9275566wiv.3.1405866845770; Sun, 20 Jul 2014 07:34:05 -0700 (PDT) From: "Karen E. Egede Nielsen" MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+kJ6fPdcDGscL4Q3O0Lp+gpmRHrw== Date: Sun, 20 Jul 2014 16:34:06 +0200 Message-ID: <3e766b0d446e695da4315465b6a3595a@mail.gmail.com> To: tsvwg@ietf.org Content-Type: multipart/alternative; boundary=f46d043c7c4cf1aedb04fea0e1c3 X-DomainID: tieto.com Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/ZNLKDZz6cV7uz_0OEqwEN6thSkg Subject: [tsvwg] comments to RFC3758 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 14:34:09 -0000 --f46d043c7c4cf1aedb04fea0e1c3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable HI, Having studied RFC3758 in a little detail (in connection with draft-ietf-tsvwg-sctp-prpolicies) then there is an issue with the present document text, which I think deserves clarification. Or at least I am not sure about how to interpret the text. I hope that the wg may help guide on what the right clarification/understanding is. The issue relate to handling of the flightsize and the calculated receiver window rwnd when abandoning a message and/or receiving a (S)ACK of the Forward TSN, respectively. The rule A2) (section 3.5) says: When a data chunk is "abandoned", the sender MUST treat the data chunk as being finally acked and no longer outstanding. This MUST clearly must not be taken literally as it indeed is being disclaimed by a number of following recommendations given: Section 3,5, A2) The sender MUST NOT credit an "abandoned" data chunk to the partial_bytes_acked as defined in Section 7.2.2 of RFC 2960 [2], and MUST NOT advance the cwnd based on this "abandoned" data chunk. Section 3,5 F5) If the decision to "abandon" a chunk is made, no matter how such a decision is made, the appropriate congestion adjustment MUST be made as specified in RFC 2960 if the chunk would have been marked for retransmission later (e.g., either by T3-Timeout or by Fast Retransmit). What I would have like to see, however, would be some disclaimers and/or more explicit descriptions of what to do/or not do with with the flight-size and the calculated rwnd when a message is abandoned. Here there are clearly 2 options in terms of how to interpret the =E2=80=9C= MUST treat as no longer outstanding=E2=80=9D: >From a conservative congestion control perspective then I would opt for that the data chunk should not be taken out of the flightsize and sliding window protocol variables before a SACK of the TSN/respectively of the FORWARD TSN has been received (conditional to F5). Alternatively if the intend of RFC3758 is to have an abandoned TSN be taken out of flight-size immediately, then I first and foremost think that the implication via-a-vis congestion control should be explicitly described in the document (if the message is in-flight one is in fact overshooting the cwnd) and secondly then for the sender not to send outside of rwnd, one would then want to more stringently specify that a delayed FORWARD TSN MUST be sent no later than with the first data chunk after the abandon of a message. This may be the intend of C3) and F2) of the document, but it is not written explicitly. Thanks in advance. BR, Karen --f46d043c7c4cf1aedb04fea0e1c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

HI,

= =C2=A0

Having studied RFC375= 8 in a little detail (in connection with draft-ietf-tsvwg-sctp-prpolicies) =

then there is an issue with the= present document text, which I think deserves

clarification. Or at least I am not sure about h= ow to interpret the text.

=C2=A0

I hope that the wg may help guide on what the= right clarification/understanding is.

=C2=A0

The issue relate to handling of= the flightsize and the calculated

receiver window rwnd when abandoning a message and/or receiv= ing a (S)ACK of the Forward TSN, respectively.

=C2=A0

The rule A2) (section 3.5) says:

=C2=A0

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When a data chunk is= "abandoned", the sender MUST treat the data
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 chunk as being finally acked and no longer outstandin= g.

=C2=A0

This MUST clearly must not be taken literally= as it indeed is being disclaimed by a number of following

recommendations given:

=C2=A0

Section 3,5, A2)

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The sender MUST NOT = credit an "abandoned" data chunk to the
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 partial_bytes_acked as defined in Section 7.2.2 of RFC 2960= [2],
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and MUST NOT advance the cwnd based on= this "abandoned" data
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ch= unk.

=C2=A0

Section = 3,5 F5)

=C2=A0

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0If the decision to "abandon" a = chunk is made, no matter how such
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a decision is made, the appropriate co= ngestion adjustment MUST be
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 made as= specified in RFC 2960 if the chunk would have been marked
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 for retransmission later (e.g., either by T3-Timeo= ut or by Fast
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Retransmit).

=C2=A0

=C2=A0

What I would have like to see, however,= would be some disclaimers and/or more explicit descriptions of what

to do/or not do with with the f= light-size and the calculated rwnd when a message is abandoned.

<= p class=3D"MsoNormal">=C2=A0

Here there are clearly 2 options in terms of h= ow to interpret the =E2=80=9CMUST treat as no longer outstanding=E2=80=9D:<= /span>

=C2=A0

From a conservative congestion control perspe= ctive then I would opt for that the data chunk should not be taken out of t= he flightsize and sliding window protocol variables before a SACK of the TS= N/respectively of the FORWARD TSN has been received (conditional to F5).

=C2=A0

Alternatively if the intend of RFC3758 is to = have an abandoned TSN be taken out of flight-size immediately, then I first= and foremost think that

the implication via-a-vis conge= stion control should be explicitly described in the document (if the messag= e is in-flight one is in fact overshooting the cwnd) and secondly then for = the sender not to send outside of rwnd, one would then want to more stringe= ntly specify that a delayed FORWARD TSN MUST be sent no later than with the= first data chunk after the abandon of a message. This may be the intend of= C3) and F2) of the document, but it is not written explicitly.

=C2=A0

Thanks in advance.

=C2=A0

BR, Karen

=C2=A0

=C2=A0

=C2=A0

=C2=A0

--f46d043c7c4cf1aedb04fea0e1c3-- From nobody Sun Jul 20 09:00:17 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC901B2C6D for ; Sun, 20 Jul 2014 09:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 9_81RTJZlsug for ; Sun, 20 Jul 2014 09:00:04 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D5AB1B2C56 for ; Sun, 20 Jul 2014 09:00:02 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so5467262wgh.22 for ; Sun, 20 Jul 2014 09:00: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:content-type; bh=TY8KKhVLkiXfUDfZ6B1Pcn1uG8uSv7DNwt/HGHte4no=; b=lTIQl47jsDxW8VPLjw9aJIUO+oWdsVsiifhgsi6jzLZZ2HXaEZkXBrcSngt2gkAaBY b7j0gdqTk53L/fbgMDaQfFDSf5LPW6QDy/OsQYvL/zYHcwQAve3sMVKVwkiugaZ5jjVC Lg12mitglUtQWXnLUhC/A0tbRensC3ZilIuhA= 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:content-type; bh=TY8KKhVLkiXfUDfZ6B1Pcn1uG8uSv7DNwt/HGHte4no=; b=PTIYrSUxgTEDh3lK4EiORS+KWEv3eIiJsZvFw9e8V4rdGNNhD5PqimZ9tttrYzDMl5 3FNSDVv1honnNjf6+OdsuhPCC/2X7wO1d1rjXF538Zx/eyXSRnoj+oLHUYrSChbUUqTc G1P67AuOn0TN4yRylXUnHLvULS17Q/W4GS2abD02CaS8B8LLldnokcgsAdAOIJr02Af8 rsnN7wRelU0VFlYnCXTVjgMhH/Lv2ClCNVMQ2fdgFOtxVM8isGu/XNYZXeb7RD3dTTFC 6nZroXoxN5lhhIzoTMBt9pnxWTB8RiPmlR0DvpeK68xxxs9iZ8gehnmBQ5NuF9kyTbLZ tdAw== X-Gm-Message-State: ALoCoQmHSL9V6gA9d6MDYwaF9teKMawvPnX7TD79ch9zmat1kFWa7z5hSf65XfPVtLMrCQXHjshP4lkdknQy9jn5UDzfDb2OsA== X-Received: by 10.194.63.77 with SMTP id e13mr14117531wjs.104.1405872000758; Sun, 20 Jul 2014 09:00:00 -0700 (PDT) From: "Karen E. Egede Nielsen" References: <20140704205143.21789.24081.idtracker@ietfa.amsl.com> In-Reply-To: <20140704205143.21789.24081.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFdG7ewSAEd2yOE1GV51HEI2KFDOJyOLGow Date: Sun, 20 Jul 2014 18:00:06 +0200 Message-ID: To: tsvwg@ietf.org Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/_zf-9Ou-lrKKpRmI5Y10vMsIP0c Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 16:00:08 -0000 HI, I have read this draft version. I think that the draft still requires more work. Most importantly: I think that the stream scheduling functions proposed need to be described in the core parts of the document. Right now they are only described in the socket api consideration part off the document. Furthermore I think that the draft should single out the subset of stream scheduling policies that an implementation following this work must support and the subset that it could support. I think that the title of the document (as well as the abstract) should be altered to better reflect that this document does not only define a new data chunk format to amend some issues with head of line blocking by large messages, but indeed prescribes for more general head-of-line controlling functions such as the stream scheduling functions. A number of the detailed comments given to a previous version of this draft still applies as far as I can see. Please refer to http://www.ietf.org/mail-archive/web/tsvwg/current/msg12303.html. BR, Karen > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: 4. juli 2014 22:52 > To: i-d-announce@ietf.org > Cc: tsvwg@ietf.org > Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-01.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 Working > Group of the IETF. > > Title : Stream Schedulers and a New Data Chunk for the > Stream > Control Transmission Protocol > Authors : Randall R. Stewart > Michael Tuexen > Salvatore Loreto > Robin Seggelmann > Filename : draft-ietf-tsvwg-sctp-ndata-01.txt > Pages : 11 > Date : 2014-07-04 > > 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. > > > 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: > http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-ndata-01 > > > 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 Sun Jul 20 12:22:30 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420411B29BB for ; Sun, 20 Jul 2014 12:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 3bfHjtCWTxLm for ; Sun, 20 Jul 2014 12:22:14 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D16B1B296C for ; Sun, 20 Jul 2014 12:22:14 -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.0/Sentrion-MTA-4.3.0) with ESMTP id s6KJMCGI001006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 20 Jul 2014 15:22:13 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s6KJMCGI001006 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1405884133; bh=NMzeTatRTxpVDZN25pXeO5Ml6e0=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=VQRrx8DEsPliJ8zbmn+tpsVTaEfOUwARkh9jgg29/5LAcwdOHz1hPByFkU/l5SiCe YUAX7eqMvWWx1zVJJW2ksIGMCqhNY5nF3B2xSW98sgPlzXA2/iKQnrxbKbNmLFRgFH O/FkNn9v1gsSCoan91fEStIGYKtLBZR71oX8v4KQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s6KJMCGI001006 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd03.lss.emc.com (RSA Interceptor) for ; Sun, 20 Jul 2014 15:22:08 -0400 Received: from mxhub14.corp.emc.com (mxhub14.corp.emc.com [128.222.70.235]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s6KJM78g011363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 20 Jul 2014 15:22:08 -0400 Received: from mx15a.corp.emc.com ([169.254.1.186]) by mxhub14.corp.emc.com ([128.222.70.235]) with mapi; Sun, 20 Jul 2014 15:22:07 -0400 From: "Black, David" To: "tsvwg@ietf.org" Importance: high X-Priority: 1 Date: Sun, 20 Jul 2014 15:19:07 -0400 Thread-Topic: Toronto Tue agenda posted, send slides!! Thread-Index: Ac+kT3oZ4HkNz0OkQE+cJv7v+3U4Ig== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71207783F636C@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/pdQxA0Pn8mXzDpVxieSBy2xgppo Subject: [tsvwg] Toronto Tue agenda posted, send slides!! X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 19:22:19 -0000 The tsvwg agenda for Tuesday (both sessions) was posted a while back: https://datatracker.ietf.org/meeting/90/agenda/tsvwg/ Those presenters who haven't already sent slides (thank you to those who have) should send slides ASAP, by mid-day Monday at the latest please. If the tsvwg meeting starts on Tuesday w/o slides for an agenda item, the chairs may impose a 3-5min time limit for a brief verbal summary + Q&A. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Sun Jul 20 13:49:15 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76E21B2CA2 for ; Sun, 20 Jul 2014 13:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 dv6bBnTNWImB for ; Sun, 20 Jul 2014 13:49:11 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 185361B29B3 for ; Sun, 20 Jul 2014 13:49:09 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id z12so5628258wgg.0 for ; Sun, 20 Jul 2014 13:49:08 -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:content-type; bh=bjGdpLa5EMjiV1cfvZf51tRlfzaYLUGoT3ySyvxZX3g=; b=NbArzXRklGBFjiPydndfeiHQPdj/q1dO5TFumZFH+fwHV8PbE6LbCRtV6apdl4WyM3 DOTYXPM+nEinE8mKL5bonbB9yJ8kd4gUy1rNYhqG/I32cUvve0llU/0QDnDwqRv4nD9k c6iA0d4agNBVQA4HFyiJTxRsRM+tpQ5pGgys8= 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:content-type; bh=bjGdpLa5EMjiV1cfvZf51tRlfzaYLUGoT3ySyvxZX3g=; b=Hg8YU9uTOg4VnosNrjBPAYWDdzaqM46IS4mhJDM5ilA7+dEqIYsVi2vYXuZnK1HYW1 WzR9hLx5C3kbuGRoJUBcVwFpU8RQiEGLp0hs/8qdCDzNm6vlWYWxmBEotRkBZhKV2xAu ClXavjU+hkzOVMwBuswRy+bcxslXfOJtscLZk37Ke1KLu9F+6JJTANfBS85NXWE7CL69 /rSeyJHMSqFKMe88JyUSriskTvypRNbwEp/ymYQ+qi1X8QLj0bE+QPqU5C2CL8lPFH08 0TM1jlRRrh5zpTBHvFJD+tOmkZq1k/+qhKx3nYuvcFAnjGHdLK+NvwF+CsMx18a8oBd6 UVQQ== X-Gm-Message-State: ALoCoQnB0xmEKe5azWKfo1929Me9cZqsoNwGWyBCx8y19eWbv++674UpEyqJhM6k0WETHIJMOUHZmiWrAZUOQHLTkzsLDRhQXA== X-Received: by 10.180.12.38 with SMTP id v6mr7173588wib.31.1405889348485; Sun, 20 Jul 2014 13:49:08 -0700 (PDT) From: "Karen E. Egede Nielsen" References: <20140623191132.21904.23978.idtracker@ietfa.amsl.com> In-Reply-To: <20140623191132.21904.23978.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLxFDM79VKa65qAlrEeSSnrsrTmeZlmc0rg Date: Sun, 20 Jul 2014 22:49:13 +0200 Message-ID: <1373b5f3f2f88c06aafc0deb45287f61@mail.gmail.com> To: tsvwg@ietf.org Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/IuxCX2VLKlBSMQMTDisF5GNKnC4 Cc: rmcat WG Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 20:49:13 -0000 Hi, Please accept the following comments: I wonder if the recommendations of this document should not relate to the viability (or rather the opposite) of handling different RTCWEB data channels individually from a DSCP markings perspective. Or more generally relate to the fact that media streams within the same congestion control context cannot be handled individually. Right now such considerations are not in the document. If the intention is for such consideration to come in documents from the dart wg, then it would be very important to have a reference to this dependency - or ? Something else: Right now the document stipulates that packets within the same media stream may be marked with different DSCP codepoints, i.e., it is said: One may select difference drop precedences for the different packets in the media flow. Therefore, all packets in the stream SHOULD be marked with the same priority but can have difference drop precedences. which indeed is in compliance with the recommendations put forward in draft-york-dart-dscp-rtp-00 in that it ensures that the DSCP markings do not result in re-ordering within the media flow, but has it been ascertained, from a CC perspective that usage of different drop precedence within the same CC context is viable ? >From the RTCWEB data channel perspective this certainly isn't viable (being SCTP based), whether it is viable from an RMCAT CC perspective is something that we in the RMCAT wg would need to make more clear. BR, Karen > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: 23. juni 2014 21:12 > To: i-d-announce@ietf.org > Cc: tsvwg@ietf.org > Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.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 Working > Group of the IETF. > > Title : DSCP and other packet markings for RTCWeb QoS > Authors : Subha Dhesikan > Cullen Jennings > Dan Druta > Paul Jones > James Polk > Filename : draft-ietf-tsvwg-rtcweb-qos-02.txt > Pages : 7 > Date : 2014-06-23 > > Abstract: > Many networks, such as service provider and enterprise networks, can > provide per packet treatments based on Differentiated Services Code > Points (DSCP) on a per-hop basis. This document provides the > recommended DSCP values for browsers to use for various classes of > traffic. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rtcweb-qos-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 20 14:38:28 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDCD1B2CC5 for ; Sun, 20 Jul 2014 14:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 C4ax7sbfw-UD for ; Sun, 20 Jul 2014 14:38:26 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [142.59.210.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 892B21B2988 for ; Sun, 20 Jul 2014 14:38:26 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s6KLcOWC019019; Sun, 20 Jul 2014 15:38:24 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s6KLcOgR014265; Sun, 20 Jul 2014 15:38:24 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id s6KLcNjh014263; Sun, 20 Jul 2014 15:38:23 -0600 Date: Sun, 20 Jul 2014 15:38:23 -0600 From: "Brian F. G. Bidulock" To: "Karen E. Egede Nielsen" Message-ID: <20140720213823.GA14062@openss7.org> Mail-Followup-To: "Karen E. Egede Nielsen" , tsvwg@ietf.org References: <3e766b0d446e695da4315465b6a3595a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3e766b0d446e695da4315465b6a3595a@mail.gmail.com> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/ShvJ_EgrqeH6I0_4r0W12fiN4ss Cc: tsvwg@ietf.org Subject: Re: [tsvwg] comments to RFC3758 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 21:38:28 -0000 Karen, Please see comments below... Karen E. Egede Nielsen wrote: (Sun, 20 Jul 2014 16:34:06) > (1) > When a data chunk is "abandoned", the sender MUST treat the data > chunk as being finally acked and no longer outstanding. > This pertains to acknowledgement only: the packet is acked; plain and simple. Do not read more into it than that. The other passages are explicit on how to treat congestion. (2) > The sender MUST NOT credit an "abandoned" data chunk to the > partial_bytes_acked as defined in Section 7.2.2 of RFC 2960 [2], > and MUST NOT advance the cwnd based on this "abandoned" data chunk. (3) > If the decision to "abandon" a chunk is made, no matter how such a > decision is made, the appropriate congestion adjustment MUST be > made as specified in RFC 2960 if the chunk would have been marked > for retransmission later (e.g., either by T3-Timeout or by Fast > Retransmit). > What I would have like to see, however, would be some disclaimers > and/or more explicit descriptions of what to do/or not do with with > the flight-size and the calculated rwnd when a message is > abandoned. I think all three passages are quite clear. > Here there are clearly 2 options in terms of how to interpret the > MUST treat as no longer outstandingâ: > > From a conservative congestion control perspective then I would opt > for that the data chunk should not be taken out of the flightsize > and sliding window protocol variables before a SACK of the > TSN/respectively of the FORWARD TSN has been received (conditional > to F5). That is what is said in (3) above. > Alternatively if the intend of RFC3758 is to have an abandoned TSN > be taken out of flight-size immediately, then I first and foremost > think that the implication via-a-vis congestion control should be > explicitly described in the document (if the message is in-flight > one is in fact overshooting the cwnd) and secondly then for the > sender not to send outside of rwnd, one would then want to more > stringently specify that a delayed FORWARD TSN MUST be sent no > later than with the first data chunk after the abandon of a > message. This may be the intend of C3) and F2) of the document, but > it is not written explicitly. No, (2) says it cannot contribute to partially acked bytes and (3) says it cannot be removed from flight size until a T3-timeout or acknowledgement. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From nobody Sun Jul 20 16:04:10 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC72D1B2A36 for ; Sun, 20 Jul 2014 16:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 SnBHDiq7wn0S for ; Sun, 20 Jul 2014 16:04:07 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C75191B27AB for ; Sun, 20 Jul 2014 16:04:04 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hi2so3242543wib.4 for ; Sun, 20 Jul 2014 16:04:03 -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:content-type; bh=vsloTlK1w2BsE14CwMls/8KZ/582KGCkOFOxCVu2WRk=; b=UEDjh2RbQb8/4fGK+0g1YPjyUGj3TGKtIA/OqQAkcFAA4edG5/pT3f1UHfNVdmpf4B UU3BO6qlcssPuzFpQCBBVwHCTo/SAsxk3XhkkPh29QC7Wknko0DhcSUwxTpsStucEzaC QVP9UelR3QJt8yRKz72v7cm4cV0OSDo9i6XUU= 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:content-type; bh=vsloTlK1w2BsE14CwMls/8KZ/582KGCkOFOxCVu2WRk=; b=V2C+Jbwbo30iAzjspMfho+/hWAGkh1YmCW3eBq6BAgKCi7oN8Z8EPfLhELKGsWMmrF Y8w6R2Yf3qsPJHKL1Q0iwU/yV2BNLMtPwC+wHIS8EOw1tcOS0sq9UsGORJjtnhAjT8oi gc7jFGAWr7v4qeMhNIXJO2jemLn4UeVaLnn+yAJBcP1V6pUpIjBxs2tmMKrlERd5yNmf ARCB39hjXEcREQkaAd5sMzsM7aSuHwAWQRk+MnKvlsE5sYabyp/iK/goOWXJL1hwbl0c kP7geUomYTB/MHcQ1CFTuSRdRV3KxuwmJSWmBFzNjtzEqMGhncgirphh9xyUcrfFjF5a D22A== X-Gm-Message-State: ALoCoQl4h8/MQfgfGa21/wHcQQoOV0SJ15PY6eMqnFmNavlXJ7KTRgQACBEy8jSn7GSY/sGh/bqufCPMxZOigSzuxu19xvV5AQ== X-Received: by 10.180.7.230 with SMTP id m6mr27562039wia.3.1405897443724; Sun, 20 Jul 2014 16:04:03 -0700 (PDT) From: "Karen E. Egede Nielsen" References: <3e766b0d446e695da4315465b6a3595a@mail.gmail.com> <20140720213823.GA14062@openss7.org> In-Reply-To: <20140720213823.GA14062@openss7.org> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHYhL2MPOQvTWGH1KwzgcmhhasqJQFPZKdkm41YGMA= Date: Mon, 21 Jul 2014 01:03:59 +0200 Message-ID: To: bidulock@openss7.org Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/NlB9i93ErRO-JNAOZAw_DNfhztk Cc: tsvwg@ietf.org Subject: Re: [tsvwg] comments to RFC3758 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 23:04:09 -0000 Hi, > > (1) > > When a data chunk is "abandoned", the sender MUST treat the data > > chunk as being finally acked and no longer outstanding. > > > > This pertains to acknowledgement only: the packet is acked; plain and > simple. Do not read more into it than that. > > The other passages are explicit on how to treat congestion. > > (2) > > The sender MUST NOT credit an "abandoned" data chunk to the > > partial_bytes_acked as defined in Section 7.2.2 of RFC 2960 [2], > > and MUST NOT advance the cwnd based on this "abandoned" data chunk. > > (3) > > If the decision to "abandon" a chunk is made, no matter how such a > > decision is made, the appropriate congestion adjustment MUST be > > made as specified in RFC 2960 if the chunk would have been marked > > for retransmission later (e.g., either by T3-Timeout or by Fast > > Retransmit). > > > > What I would have like to see, however, would be some disclaimers > > and/or more explicit descriptions of what to do/or not do with with > > the flight-size and the calculated rwnd when a message is > > abandoned. > > I think all three passages are quite clear. > > > Here there are clearly 2 options in terms of how to interpret the > > MUST treat as no longer outstanding : > > > > From a conservative congestion control perspective then I would opt > > for that the data chunk should not be taken out of the flightsize > > and sliding window protocol variables before a SACK of the > > TSN/respectively of the FORWARD TSN has been received (conditional > > to F5). > > That is what is said in (3) above. > > > Alternatively if the intend of RFC3758 is to have an abandoned TSN > > be taken out of flight-size immediately, then I first and foremost > > think that the implication via-a-vis congestion control should be > > explicitly described in the document (if the message is in-flight > > one is in fact overshooting the cwnd) and secondly then for the > > sender not to send outside of rwnd, one would then want to more > > stringently specify that a delayed FORWARD TSN MUST be sent no > > later than with the first data chunk after the abandon of a > > message. This may be the intend of C3) and F2) of the document, but > > it is not written explicitly. > > No, (2) says it cannot contribute to partially acked bytes and (3) says it > cannot > be removed from flight size until a T3-timeout or acknowledgement. > [Karen] I cannot see that 3 says this. Such an interpretation of (3) presumes that a message is only abandoned at a T3 or when marked for fast retransmission. Furthermore 3 speaks about congestion control adjustments not about inflight or rwnd. BR, Karen The document does not presume that > --brian > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ From nobody Sun Jul 20 17:51:33 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3741B2A70; Sun, 20 Jul 2014 17:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 57ZS7kBKMGWK; Sun, 20 Jul 2014 17:51:28 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 015891B2A68; Sun, 20 Jul 2014 17:51:27 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s6L0pPFL027100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jul 2014 20:51:26 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s6L0pPFL027100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1405903886; bh=SVxmqDBMJhw8MNqyAIwU+C/X6xI=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Zjwtj2BxbKoWPlK4SjQpSWbFFftWKq3gVw1QVXnlC+YS+fAaJzQezapIzC+yPSiTJ JtQc5BnDqpkgOGXwFeH//xv4waMDrn3Qj1cM2ifZyKxiFh4DRRUO7buyTG/Av5iPyw ee24S4YX/bB8GWHh6DqAZa2ATzMrebKta2cQQAGs= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s6L0pPFL027100 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd55.lss.emc.com (RSA Interceptor); Sun, 20 Jul 2014 20:51:15 -0400 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s6L0pEEA001721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Jul 2014 20:51:14 -0400 Received: from mx15a.corp.emc.com ([169.254.1.186]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Sun, 20 Jul 2014 20:51:14 -0400 From: "Black, David" To: "Karen E. Egede Nielsen" , "tsvwg@ietf.org" Date: Sun, 20 Jul 2014 20:51:12 -0400 Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt Thread-Index: AQLxFDM79VKa65qAlrEeSSnrsrTmeZlmc0rggABeiUA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE71207783F6386@MX15A.corp.emc.com> References: <20140623191132.21904.23978.idtracker@ietfa.amsl.com> <1373b5f3f2f88c06aafc0deb45287f61@mail.gmail.com> In-Reply-To: <1373b5f3f2f88c06aafc0deb45287f61@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/mm8kzgRpN59FdlLyM75FYsKmrx4 Cc: rmcat WG , "dart@ietf.org" Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 00:51:30 -0000 S2FyZW4sDQoNCjxXRyBjaGFpciBoYXQgb2ZmPiwgWytkYXJ0IGxpc3RdDQoNCj4gSSB3b25kZXIg aWYgdGhlIHJlY29tbWVuZGF0aW9ucyBvZiB0aGlzIGRvY3VtZW50IHNob3VsZCBub3QgcmVsYXRl IHRvIHRoZQ0KPiB2aWFiaWxpdHkgKG9yIHJhdGhlciB0aGUgb3Bwb3NpdGUpIG9mDQo+IGhhbmRs aW5nIGRpZmZlcmVudCBSVENXRUIgZGF0YSBjaGFubmVscyBpbmRpdmlkdWFsbHkgZnJvbSBhIERT Q1AgbWFya2luZ3MNCj4gcGVyc3BlY3RpdmUuIE9yIG1vcmUgZ2VuZXJhbGx5DQo+IHJlbGF0ZSB0 byB0aGUgZmFjdCB0aGF0IG1lZGlhIHN0cmVhbXMgd2l0aGluIHRoZSBzYW1lIGNvbmdlc3Rpb24g Y29udHJvbA0KPiBjb250ZXh0IGNhbm5vdCBiZSBoYW5kbGVkIGluZGl2aWR1YWxseS4NCj4gUmln aHQgbm93IHN1Y2ggY29uc2lkZXJhdGlvbnMgYXJlIG5vdCBpbiB0aGUgZG9jdW1lbnQuIElmIHRo ZSBpbnRlbnRpb24gaXMNCj4gZm9yIHN1Y2ggY29uc2lkZXJhdGlvbiB0byBjb21lDQo+IGluIGRv Y3VtZW50cyBmcm9tIHRoZSBkYXJ0IHdnLCB0aGVuIGl0IHdvdWxkIGJlIHZlcnkgaW1wb3J0YW50 IHRvICBoYXZlIGENCj4gcmVmZXJlbmNlIHRvIHRoaXMgZGVwZW5kZW5jeSAtIG9yID8NCg0KSU1I Tywgc3VjaCBhIHJlZmVyZW5jZSBpcyBuZWNlc3NhcnksIGFsdGhvdWdoIHRoZSBkYXJ0IFdHIGRy YWZ0IHdpbGwgYmUNCmluZm9ybWF0aW9uYWwuICBUaGUgcmVmZXJlbmNlIHNob3VsZCBiZSBhZGRl ZCBvbmNlIHRoZXJlIGlzIGFuIG9mZmljaWFsIGRhcnQNCldHIGRyYWZ0IChsaWtlbHkgdG8gaGFw cGVuIHRoaXMgd2VlaykuDQoNCj4gU29tZXRoaW5nIGVsc2U6DQo+DQo+IFJpZ2h0IG5vdyB0aGUg ZG9jdW1lbnQgc3RpcHVsYXRlcyB0aGF0IHBhY2tldHMgd2l0aGluIHRoZSBzYW1lIG1lZGlhIHN0 cmVhbQ0KPiBtYXkgYmUgbWFya2VkIHdpdGggZGlmZmVyZW50IERTQ1AgY29kZXBvaW50cywgaS5l LiwNCj4gaXQgaXMgc2FpZDoNCj4gDQo+ICAgIE9uZSBtYXkgc2VsZWN0IGRpZmZlcmVuY2UgZHJv cCBwcmVjZWRlbmNlcyBmb3IgdGhlDQo+ICAgIGRpZmZlcmVudCBwYWNrZXRzIGluIHRoZSBtZWRp YSBmbG93LiAgVGhlcmVmb3JlLCBhbGwgcGFja2V0cyBpbiB0aGUNCj4gICAgc3RyZWFtIFNIT1VM RCBiZSBtYXJrZWQgd2l0aCB0aGUgc2FtZSBwcmlvcml0eSBidXQgY2FuIGhhdmUNCj4gICAgZGlm ZmVyZW5jZSBkcm9wIHByZWNlZGVuY2VzLg0KPiANCj4gd2hpY2ggaW5kZWVkIGlzIGluIGNvbXBs aWFuY2Ugd2l0aCB0aGUgcmVjb21tZW5kYXRpb25zIHB1dCBmb3J3YXJkIGluDQo+IGRyYWZ0LXlv cmstZGFydC1kc2NwLXJ0cC0wMCBpbiB0aGF0DQo+IGl0IGVuc3VyZXMgdGhhdCB0aGUgRFNDUCBt YXJraW5ncyAgZG8gbm90IHJlc3VsdCBpbiByZS1vcmRlcmluZyAgd2l0aGluIHRoZQ0KPiBtZWRp YSBmbG93LCBidXQgaGFzIGl0IGJlZW4gYXNjZXJ0YWluZWQsIGZyb20gYSBDQw0KPiBwZXJzcGVj dGl2ZSB0aGF0IHVzYWdlIG9mIGRpZmZlcmVudCBkcm9wIHByZWNlZGVuY2Ugd2l0aGluIHRoZSBz YW1lIENDDQo+IGNvbnRleHQgaXMgdmlhYmxlID8NCg0KR29vZCBxdWVzdGlvbiAtIEkgd2lsbCBp bmNsdWRlIHRoYXQgaW4gbXkgc2xpZGVzIGZvciB0aGUgZGFydCBXRyBtZWV0aW5nLg0KDQo+ID5G cm9tIHRoZSBSVENXRUIgZGF0YSBjaGFubmVsIHBlcnNwZWN0aXZlIHRoaXMgY2VydGFpbmx5IGlz bid0IHZpYWJsZSAoYmVpbmcNCj4gU0NUUCBiYXNlZCksDQo+IHdoZXRoZXIgaXQgaXMgdmlhYmxl IGZyb20gYW4gUk1DQVQgQ0MgcGVyc3BlY3RpdmUgaXMgc29tZXRoaW5nIHRoYXQgd2UgaW4NCj4g dGhlIFJNQ0FUIHdnIHdvdWxkIG5lZWQgdG8NCj4gbWFrZSBtb3JlIGNsZWFyLg0KDQpXaGF0J3Mg dGhlIHJhdGlvbmFsZSBmb3IgImNlcnRhaW5seSBpc24ndCB2aWFibGUiIHJlZ2FyZGluZyBkaWZm ZXJlbnQgZHJvcA0KcHJlY2VkZW5jZXMgd2l0aGluIGEgc2luZ2xlIFNDVFAgc2Vzc2lvbj8NCg0K VGhhbmtzLA0KLS1EYXZpZCAoYXMgYW4gZWRpdG9yIG9mIGRyYWZ0LXlvcmssICpub3QqIGFzIGEg dHN2d2cgV0cgY2hhaXIpDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog dHN2d2cgW21haWx0bzp0c3Z3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2FyZW4g RS4gRWdlZGUNCj4gTmllbHNlbg0KPiBTZW50OiBTdW5kYXksIEp1bHkgMjAsIDIwMTQgNDo0OSBQ TQ0KPiBUbzogdHN2d2dAaWV0Zi5vcmcNCj4gQ2M6IHJtY2F0IFdHDQo+IFN1YmplY3Q6IFJlOiBb dHN2d2ddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcy0wMi50eHQNCj4g DQo+IEhpLA0KPiANCj4gUGxlYXNlIGFjY2VwdCB0aGUgZm9sbG93aW5nIGNvbW1lbnRzOg0KPiAN Cj4gSSB3b25kZXIgaWYgdGhlIHJlY29tbWVuZGF0aW9ucyBvZiB0aGlzIGRvY3VtZW50IHNob3Vs ZCBub3QgcmVsYXRlIHRvIHRoZQ0KPiB2aWFiaWxpdHkgKG9yIHJhdGhlciB0aGUgb3Bwb3NpdGUp IG9mDQo+IGhhbmRsaW5nIGRpZmZlcmVudCBSVENXRUIgZGF0YSBjaGFubmVscyBpbmRpdmlkdWFs bHkgZnJvbSBhIERTQ1AgbWFya2luZ3MNCj4gcGVyc3BlY3RpdmUuIE9yIG1vcmUgZ2VuZXJhbGx5 DQo+IHJlbGF0ZSB0byB0aGUgZmFjdCB0aGF0IG1lZGlhIHN0cmVhbXMgd2l0aGluIHRoZSBzYW1l IGNvbmdlc3Rpb24gY29udHJvbA0KPiBjb250ZXh0IGNhbm5vdCBiZSBoYW5kbGVkIGluZGl2aWR1 YWxseS4NCj4gUmlnaHQgbm93IHN1Y2ggY29uc2lkZXJhdGlvbnMgYXJlIG5vdCBpbiB0aGUgZG9j dW1lbnQuIElmIHRoZSBpbnRlbnRpb24gaXMNCj4gZm9yIHN1Y2ggY29uc2lkZXJhdGlvbiB0byBj b21lDQo+IGluIGRvY3VtZW50cyBmcm9tIHRoZSBkYXJ0IHdnLCB0aGVuIGl0IHdvdWxkIGJlIHZl cnkgaW1wb3J0YW50IHRvICBoYXZlIGENCj4gcmVmZXJlbmNlIHRvIHRoaXMgZGVwZW5kZW5jeSAt IG9yID8NCj4gDQo+IFNvbWV0aGluZyBlbHNlOg0KPiANCj4gUmlnaHQgbm93IHRoZSBkb2N1bWVu dCBzdGlwdWxhdGVzIHRoYXQgcGFja2V0cyB3aXRoaW4gdGhlIHNhbWUgbWVkaWEgc3RyZWFtDQo+ IG1heSBiZSBtYXJrZWQgd2l0aCBkaWZmZXJlbnQgRFNDUCBjb2RlcG9pbnRzLCBpLmUuLA0KPiBp dCBpcyBzYWlkOg0KPiANCj4gICAgT25lIG1heSBzZWxlY3QgZGlmZmVyZW5jZSBkcm9wIHByZWNl ZGVuY2VzIGZvciB0aGUNCj4gICAgZGlmZmVyZW50IHBhY2tldHMgaW4gdGhlIG1lZGlhIGZsb3cu ICBUaGVyZWZvcmUsIGFsbCBwYWNrZXRzIGluIHRoZQ0KPiAgICBzdHJlYW0gU0hPVUxEIGJlIG1h cmtlZCB3aXRoIHRoZSBzYW1lIHByaW9yaXR5IGJ1dCBjYW4gaGF2ZQ0KPiAgICBkaWZmZXJlbmNl IGRyb3AgcHJlY2VkZW5jZXMuDQo+IA0KPiB3aGljaCBpbmRlZWQgaXMgaW4gY29tcGxpYW5jZSB3 aXRoIHRoZSByZWNvbW1lbmRhdGlvbnMgcHV0IGZvcndhcmQgaW4NCj4gZHJhZnQteW9yay1kYXJ0 LWRzY3AtcnRwLTAwIGluIHRoYXQNCj4gaXQgZW5zdXJlcyB0aGF0IHRoZSBEU0NQIG1hcmtpbmdz ICBkbyBub3QgcmVzdWx0IGluIHJlLW9yZGVyaW5nICB3aXRoaW4gdGhlDQo+IG1lZGlhIGZsb3cs IGJ1dCBoYXMgaXQgYmVlbiBhc2NlcnRhaW5lZCwgZnJvbSBhIENDDQo+IHBlcnNwZWN0aXZlIHRo YXQgdXNhZ2Ugb2YgZGlmZmVyZW50IGRyb3AgcHJlY2VkZW5jZSB3aXRoaW4gdGhlIHNhbWUgQ0MN Cj4gY29udGV4dCBpcyB2aWFibGUgPw0KPiANCj4gPkZyb20gdGhlIFJUQ1dFQiBkYXRhIGNoYW5u ZWwgcGVyc3BlY3RpdmUgdGhpcyBjZXJ0YWlubHkgaXNuJ3QgdmlhYmxlIChiZWluZw0KPiBTQ1RQ IGJhc2VkKSwNCj4gd2hldGhlciBpdCBpcyB2aWFibGUgZnJvbSBhbiBSTUNBVCBDQyBwZXJzcGVj dGl2ZSBpcyBzb21ldGhpbmcgdGhhdCB3ZSBpbg0KPiB0aGUgUk1DQVQgd2cgd291bGQgbmVlZCB0 bw0KPiBtYWtlIG1vcmUgY2xlYXIuDQo+IA0KPiBCUiwgS2FyZW4NCj4gDQo+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBpbnRlcm5ldC0NCj4gPiBkcmFmdHNAaWV0Zi5vcmcNCj4g PiBTZW50OiAyMy4ganVuaSAyMDE0IDIxOjEyDQo+ID4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9y Zw0KPiA+IENjOiB0c3Z3Z0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFt0c3Z3Z10gSS1EIEFjdGlv bjogZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zLTAyLnR4dA0KPiA+DQo+ID4NCj4gPiBBIE5l dyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1E cmFmdHMNCj4gPiBkaXJlY3Rvcmllcy4NCj4gPiAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBv ZiB0aGUgVHJhbnNwb3J0IEFyZWEgV29ya2luZyBHcm91cCBXb3JraW5nDQo+ID4gR3JvdXAgb2Yg dGhlIElFVEYuDQo+ID4NCj4gPiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IERTQ1AgYW5kIG90 aGVyIHBhY2tldCBtYXJraW5ncyBmb3IgUlRDV2ViIFFvUw0KPiA+ICAgICAgICAgQXV0aG9ycyAg ICAgICAgIDogU3ViaGEgRGhlc2lrYW4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEN1 bGxlbiBKZW5uaW5ncw0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgRGFuIERydXRhDQo+ ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBQYXVsIEpvbmVzDQo+ID4gICAgICAgICAgICAg ICAgICAgICAgICAgICBKYW1lcyBQb2xrDQo+ID4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWll dGYtdHN2d2ctcnRjd2ViLXFvcy0wMi50eHQNCj4gPiAJUGFnZXMgICAgICAgICAgIDogNw0KPiA+ IAlEYXRlICAgICAgICAgICAgOiAyMDE0LTA2LTIzDQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiAg ICBNYW55IG5ldHdvcmtzLCBzdWNoIGFzIHNlcnZpY2UgcHJvdmlkZXIgYW5kIGVudGVycHJpc2Ug bmV0d29ya3MsIGNhbg0KPiA+ICAgIHByb3ZpZGUgcGVyIHBhY2tldCB0cmVhdG1lbnRzIGJhc2Vk IG9uIERpZmZlcmVudGlhdGVkIFNlcnZpY2VzIENvZGUNCj4gPiAgICBQb2ludHMgKERTQ1ApIG9u IGEgcGVyLWhvcCBiYXNpcy4gIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgdGhlDQo+ID4gICAgcmVj b21tZW5kZWQgRFNDUCB2YWx1ZXMgZm9yIGJyb3dzZXJzIHRvIHVzZSBmb3IgdmFyaW91cyBjbGFz c2VzIG9mDQo+ID4gICAgdHJhZmZpYy4NCj4gPg0KPiA+DQo+ID4gVGhlIElFVEYgZGF0YXRyYWNr ZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zLw0KPiA+DQo+ID4gVGhl cmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+ID4gaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zLTAyDQo+ID4NCj4g PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+ID4g aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWIt cW9zLTAyDQo+ID4NCj4gPg0KPiA+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4gc3VibWlzc2lvbg0KPiA+IHVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmcuDQo+ID4NCj4gPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFu b255bW91cyBGVFAgYXQ6DQo+ID4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8N Cg0K From nobody Sun Jul 20 18:22:38 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832E41B2A66 for ; Sun, 20 Jul 2014 18:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 TZ73OQfwBUft for ; Sun, 20 Jul 2014 18:22:34 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D7E1B2AB2 for ; Sun, 20 Jul 2014 18:22:33 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so5786321wgh.22 for ; Sun, 20 Jul 2014 18:22:32 -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:content-type; bh=2uca0xtQTSvcVwGuCu2GzTY4S+XwcHnUNg8PVJD8SrI=; b=A5UCdKq4jG/19/WHE3e4cmgKGX0cnChFFuJDZW9zKQpfYYTiDVYWV/+aSgBw7iDBRF pYmA06wrtN17Z5O6qRCbMzxzjp+Va5YWdKo+0Z3ffUDJnQsTTkbdukilg0hCNwu7Vdxw u3qRkMAP5BTRfJBCQwVNaP8dfFCWG0Ux8BbVw= 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:content-type; bh=2uca0xtQTSvcVwGuCu2GzTY4S+XwcHnUNg8PVJD8SrI=; b=dTM184dEkZw9yGdn/XUSG2MzRe7Q6qZltb/GwOgqapDYJbaJiU9xPly8OOcB229YZk SSB7uyWifMdLTO+z3gJj+kQj/lqukMzWzmT4NjbOCoxibYkTVKczxqUZ7Asv7LYSuF3g ADPohI6tNbF71Th2HepJn0LonL3fowP3fmYwogyE6yHbfY5M4o5L2i8eAwDu7ve0Uvvu /4lMHZFlhSGWHioZHwrq9SeolFT7UNM1OS/hSMWa4EvVvzyuhW2axK0S3qNY2Lc+khvv F323DqCk10ZsDcbEsenGfE3R2jliwO7UGyKs5mm6K6Br10koN8o1zpIUYpSs1YXC4A8i cWlw== X-Gm-Message-State: ALoCoQlSPCcCiOmdq7KsOKUNkExD+9ClYAhV9902hq2wCViCcXZSHEVF33iIMga/0PSU0XXMvk5bBYtmPMGy2my6Gh8hOD0PiQ== X-Received: by 10.180.24.225 with SMTP id x1mr4127258wif.14.1405905752331; Sun, 20 Jul 2014 18:22:32 -0700 (PDT) From: "Karen E. Egede Nielsen" References: <20140623191132.21904.23978.idtracker@ietfa.amsl.com> <1373b5f3f2f88c06aafc0deb45287f61@mail.gmail.com> <8D3D17ACE214DC429325B2B98F3AE71207783F6386@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71207783F6386@MX15A.corp.emc.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLxFDM79VKa65qAlrEeSSnrsrTmeQI8PUdIAZ7WDh+ZR/+qsA== Date: Mon, 21 Jul 2014 03:20:16 +0200 Message-ID: To: "Black, David" , tsvwg@ietf.org Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/ZbVZuValC9f568PuoS9qitmYcQ4 Cc: rmcat WG , dart@ietf.org Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 01:22:36 -0000 Hi, > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: 21. juli 2014 02:51 > To: Karen E. Egede Nielsen; tsvwg@ietf.org > Cc: rmcat WG; dart@ietf.org; Black, David > Subject: RE: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt > > Karen, > > , [+dart list] > > > I wonder if the recommendations of this document should not relate to > > the viability (or rather the opposite) of handling different RTCWEB > > data channels individually from a DSCP markings perspective. Or more > > generally relate to the fact that media streams within the same > > congestion control context cannot be handled individually. > > Right now such considerations are not in the document. If the > > intention is for such consideration to come in documents from the dart > > wg, then it would be very important to have a reference to this > > dependency - or ? > > IMHO, such a reference is necessary, although the dart WG draft will be > informational. The reference should be added once there is an official > dart > WG draft (likely to happen this week). > > > Something else: > > > > Right now the document stipulates that packets within the same media > > stream may be marked with different DSCP codepoints, i.e., it is said: > > > > One may select difference drop precedences for the > > different packets in the media flow. Therefore, all packets in the > > stream SHOULD be marked with the same priority but can have > > difference drop precedences. > > > > which indeed is in compliance with the recommendations put forward in > > draft-york-dart-dscp-rtp-00 in that > > it ensures that the DSCP markings do not result in re-ordering > > within the media flow, but has it been ascertained, from a CC > > perspective that usage of different drop precedence within the same CC > > context is viable ? > > Good question - I will include that in my slides for the dart WG meeting. > > > >From the RTCWEB data channel perspective this certainly isn't viable > > >(being > > SCTP based), > > whether it is viable from an RMCAT CC perspective is something that we > > in the RMCAT wg would need to make more clear. > > What's the rationale for "certainly isn't viable" regarding different drop > precedences within a single SCTP session? [Karen] Ok - "certainly not viable" is too strong formulation. Having different drop precedences within the same SCTP CC context would, given that SCTP CC presently is drop driven only, results in that the whole data channel is impacted, from a CC perspective, by the highest drop precedence. But I realize that whether this is acceptable is a question indeed. > > Thanks, > --David (as an editor of draft-york, *not* as a tsvwg WG chair) > > > -----Original Message----- > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Karen E. > > Egede Nielsen > > Sent: Sunday, July 20, 2014 4:49 PM > > To: tsvwg@ietf.org > > Cc: rmcat WG > > Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt > > > > Hi, > > > > Please accept the following comments: > > > > I wonder if the recommendations of this document should not relate to > > the viability (or rather the opposite) of handling different RTCWEB > > data channels individually from a DSCP markings perspective. Or more > > generally relate to the fact that media streams within the same > > congestion control context cannot be handled individually. > > Right now such considerations are not in the document. If the > > intention is for such consideration to come in documents from the dart > > wg, then it would be very important to have a reference to this > > dependency - or ? > > > > Something else: > > > > Right now the document stipulates that packets within the same media > > stream may be marked with different DSCP codepoints, i.e., it is said: > > > > One may select difference drop precedences for the > > different packets in the media flow. Therefore, all packets in the > > stream SHOULD be marked with the same priority but can have > > difference drop precedences. > > > > which indeed is in compliance with the recommendations put forward in > > draft-york-dart-dscp-rtp-00 in that > > it ensures that the DSCP markings do not result in re-ordering > > within the media flow, but has it been ascertained, from a CC > > perspective that usage of different drop precedence within the same CC > > context is viable ? > > > > >From the RTCWEB data channel perspective this certainly isn't viable > > >(being > > SCTP based), > > whether it is viable from an RMCAT CC perspective is something that we > > in the RMCAT wg would need to make more clear. > > > > BR, Karen > > > > > -----Original Message----- > > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of internet- > > > drafts@ietf.org > > > Sent: 23. juni 2014 21:12 > > > To: i-d-announce@ietf.org > > > Cc: tsvwg@ietf.org > > > Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.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 > > > Working Group of the IETF. > > > > > > Title : DSCP and other packet markings for RTCWeb > > > QoS > > > Authors : Subha Dhesikan > > > Cullen Jennings > > > Dan Druta > > > Paul Jones > > > James Polk > > > Filename : draft-ietf-tsvwg-rtcweb-qos-02.txt > > > Pages : 7 > > > Date : 2014-06-23 > > > > > > Abstract: > > > Many networks, such as service provider and enterprise networks, > > > can > > > provide per packet treatments based on Differentiated Services Code > > > Points (DSCP) on a per-hop basis. This document provides the > > > recommended DSCP values for browsers to use for various classes of > > > traffic. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/ > > > > > > There's also a htmlized version available at: > > > http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-02 > > > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rtcweb-qos-02 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > > > tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 20 19:00:46 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7950B1B2ACD; Sun, 20 Jul 2014 19:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 vhepvacBtDEZ; Sun, 20 Jul 2014 19:00:38 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87B11B2ABE; Sun, 20 Jul 2014 19:00:38 -0700 (PDT) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s6L20ZD3026482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jul 2014 22:00:36 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s6L20ZD3026482 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1405908036; bh=8Y2vgoH3+QCRJ+gE/BAbliv8Szw=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ElZeyQ1KlcqfGe230DeYSlIV3YXM1RKMrjwfl0X8fKeCirt7QoEclmzNhYs3IXaut wR4j3A/Cl5AAx19w4PXVFvPjzwWL+oXDOwvnABXV9ydFgUNaIjGf9J51T7xhrLQwZm 54RAQ9t1Y+8q0eqeuzOuuKF4eNzIxM6+kxE3SXss= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s6L20ZD3026482 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd05.lss.emc.com (RSA Interceptor); Sun, 20 Jul 2014 22:00:30 -0400 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s6L20Tud015443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Jul 2014 22:00:30 -0400 Received: from mx15a.corp.emc.com ([169.254.1.186]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Sun, 20 Jul 2014 22:00:29 -0400 From: "Black, David" To: "Karen E. Egede Nielsen" , "tsvwg@ietf.org" Date: Sun, 20 Jul 2014 22:00:28 -0400 Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt Thread-Index: AQLxFDM79VKa65qAlrEeSSnrsrTmeQI8PUdIAZ7WDh+ZR/+qsIAAC7Xw Message-ID: <8D3D17ACE214DC429325B2B98F3AE71207783F6399@MX15A.corp.emc.com> References: <20140623191132.21904.23978.idtracker@ietfa.amsl.com> <1373b5f3f2f88c06aafc0deb45287f61@mail.gmail.com> <8D3D17ACE214DC429325B2B98F3AE71207783F6386@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/ve9wfhUXmAVfCICfkitaod58Gxk Cc: rmcat WG , "dart@ietf.org" Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 02:00:41 -0000 S2FyZW4sDQoNCj4gPiBXaGF0J3MgdGhlIHJhdGlvbmFsZSBmb3IgImNlcnRhaW5seSBpc24ndCB2 aWFibGUiIHJlZ2FyZGluZyBkaWZmZXJlbnQgZHJvcA0KPiA+IHByZWNlZGVuY2VzIHdpdGhpbiBh IHNpbmdsZSBTQ1RQIHNlc3Npb24/DQo+DQo+IFtLYXJlbl0gT2sgLSAiY2VydGFpbmx5IG5vdCB2 aWFibGUiIGlzIHRvbyBzdHJvbmcgZm9ybXVsYXRpb24uDQo+IEhhdmluZyBkaWZmZXJlbnQgZHJv cCBwcmVjZWRlbmNlcyB3aXRoaW4gdGhlIHNhbWUgU0NUUCBDQyBjb250ZXh0IHdvdWxkLA0KPiBn aXZlbiB0aGF0IFNDVFAgQ0MgcHJlc2VudGx5IGlzIGRyb3AgZHJpdmVuIG9ubHksDQo+IHJlc3Vs dHMgaW4gdGhhdCB0aGUgd2hvbGUgZGF0YSBjaGFubmVsIGlzIGltcGFjdGVkLCBmcm9tIGEgQ0Mg cGVyc3BlY3RpdmUsDQo+IGJ5IHRoZSBoaWdoZXN0IGRyb3AgcHJlY2VkZW5jZS4gQnV0IEkgcmVh bGl6ZSB0aGF0IHdoZXRoZXIgdGhpcyBpcw0KPiBhY2NlcHRhYmxlIGlzIGEgcXVlc3Rpb24gaW5k ZWVkLg0KDQpJIHRoaW5rIHlvdSdyZSBvbiB0byBzb21ldGhpbmcgaGVyZS4gIElmIHRoZSBkcm9w IHByZWNlZGVuY2VzIG9ubHkgY2FtZSBpbnRvDQpwbGF5IGFmdGVyIHRoZSBkZWNpc2lvbiB0byBk cm9wIGEgcGFja2V0IGhhZCBiZWVuIG1hZGUsIHRoZWlyIGVmZmVjdCB3b3VsZA0KcHJvYmFibHkg YmUgbWluaW1hbCwgYXMgdGhleSB3b3VsZCBvbmx5IGFmZmVjdCB3aGF0IHRvIGRyb3AgaW4gYSBz ZXNzaW9uLCBub3QNCmhvdyBtdWNoIHRvIGRyb3AuICBPVE9ILCBEaWZmU2VydiBBRiBpcyBub3Qg aW50ZW5kZWQgdG8gb3BlcmF0ZSBpbiB0aGF0IGZhc2hpb24NCi0gdGhlIHJhdGlvbmFsZSBmb3Ig dGhlIDMgZHJvcCBwcmVjZWRlbmNlcyBwZXIgQUYgY2xhc3Mgd2FzIGJhc2VkIG9uIGVudmlzaW9u aW5nDQp0aGUgb3V0cHV0IG9mIHR3by10aHJlc2hvbGQgcmF0ZSBzaGFwZXI6DQoJQUZ4MSAtIFdp dGhpbiBiYXNlIG9yIGNvbW1pdHRlZCB0cmFmZmljIHByb2ZpbGUNCglBRngyIC0gQmV5b25kIGJh c2UvY29tbWl0dGVkLCBidXQgd2l0aGluIGV4Y2VzcyBvciBidXJzdCB0cmFmZmljIHByb2ZpbGUN CglBRngzIC0gQ29tcGxldGVseSBvdXQgb2YgcHJvZmlsZQ0KDQpIZW5jZSB0aGUgcmVsYXRpdmUg bWl4IG9mIHRob3NlIGRyb3AgcHJlY2VkZW5jZXMgY2FuIGJlIGV4cGVjdGVkIHRvIGFmZmVjdA0K dGhlIG92ZXJhbGwgZHJvcCByYXRlL3Byb2JhYmlsaXR5IHNlZW4gaW4gYSBzZXNzaW9uIHdoZXJl IHRob3NlIHByZWNlZGVuY2VzDQphcmUgbWl4ZWQuDQoNClRoYW5rcywNCi0tRGF2aWQNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBLYXJlbiBFLiBFZ2VkZSBOaWVsc2Vu IFttYWlsdG86a2FyZW4ubmllbHNlbkB0aWV0by5jb21dDQo+IFNlbnQ6IFN1bmRheSwgSnVseSAy MCwgMjAxNCA5OjIwIFBNDQo+IFRvOiBCbGFjaywgRGF2aWQ7IHRzdndnQGlldGYub3JnDQo+IENj OiBybWNhdCBXRzsgZGFydEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW3RzdndnXSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3MtMDIudHh0DQo+IA0KPiBIaSwNCj4gDQo+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBCbGFjaywgRGF2aWQgW21h aWx0bzpkYXZpZC5ibGFja0BlbWMuY29tXQ0KPiA+IFNlbnQ6IDIxLiBqdWxpIDIwMTQgMDI6NTEN Cj4gPiBUbzogS2FyZW4gRS4gRWdlZGUgTmllbHNlbjsgdHN2d2dAaWV0Zi5vcmcNCj4gPiBDYzog cm1jYXQgV0c7IGRhcnRAaWV0Zi5vcmc7IEJsYWNrLCBEYXZpZA0KPiA+IFN1YmplY3Q6IFJFOiBb dHN2d2ddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcy0wMi50eHQNCj4g Pg0KPiA+IEthcmVuLA0KPiA+DQo+ID4gPFdHIGNoYWlyIGhhdCBvZmY+LCBbK2RhcnQgbGlzdF0N Cj4gPg0KPiA+ID4gSSB3b25kZXIgaWYgdGhlIHJlY29tbWVuZGF0aW9ucyBvZiB0aGlzIGRvY3Vt ZW50IHNob3VsZCBub3QgcmVsYXRlIHRvDQo+ID4gPiB0aGUgdmlhYmlsaXR5IChvciByYXRoZXIg dGhlIG9wcG9zaXRlKSBvZiBoYW5kbGluZyBkaWZmZXJlbnQgUlRDV0VCDQo+ID4gPiBkYXRhIGNo YW5uZWxzIGluZGl2aWR1YWxseSBmcm9tIGEgRFNDUCBtYXJraW5ncyBwZXJzcGVjdGl2ZS4gT3Ig bW9yZQ0KPiA+ID4gZ2VuZXJhbGx5IHJlbGF0ZSB0byB0aGUgZmFjdCB0aGF0IG1lZGlhIHN0cmVh bXMgd2l0aGluIHRoZSBzYW1lDQo+ID4gPiBjb25nZXN0aW9uIGNvbnRyb2wgY29udGV4dCBjYW5u b3QgYmUgaGFuZGxlZCBpbmRpdmlkdWFsbHkuDQo+ID4gPiBSaWdodCBub3cgc3VjaCBjb25zaWRl cmF0aW9ucyBhcmUgbm90IGluIHRoZSBkb2N1bWVudC4gSWYgdGhlDQo+ID4gPiBpbnRlbnRpb24g aXMgZm9yIHN1Y2ggY29uc2lkZXJhdGlvbiB0byBjb21lIGluIGRvY3VtZW50cyBmcm9tIHRoZSBk YXJ0DQo+ID4gPiB3ZywgdGhlbiBpdCB3b3VsZCBiZSB2ZXJ5IGltcG9ydGFudCB0byAgaGF2ZSBh IHJlZmVyZW5jZSB0byB0aGlzDQo+ID4gPiBkZXBlbmRlbmN5IC0gb3IgPw0KPiA+DQo+ID4gSU1I Tywgc3VjaCBhIHJlZmVyZW5jZSBpcyBuZWNlc3NhcnksIGFsdGhvdWdoIHRoZSBkYXJ0IFdHIGRy YWZ0IHdpbGwgYmUNCj4gPiBpbmZvcm1hdGlvbmFsLiAgVGhlIHJlZmVyZW5jZSBzaG91bGQgYmUg YWRkZWQgb25jZSB0aGVyZSBpcyBhbiBvZmZpY2lhbA0KPiA+IGRhcnQNCj4gPiBXRyBkcmFmdCAo bGlrZWx5IHRvIGhhcHBlbiB0aGlzIHdlZWspLg0KPiA+DQo+ID4gPiBTb21ldGhpbmcgZWxzZToN Cj4gPiA+DQo+ID4gPiBSaWdodCBub3cgdGhlIGRvY3VtZW50IHN0aXB1bGF0ZXMgdGhhdCBwYWNr ZXRzIHdpdGhpbiB0aGUgc2FtZSBtZWRpYQ0KPiA+ID4gc3RyZWFtIG1heSBiZSBtYXJrZWQgd2l0 aCBkaWZmZXJlbnQgRFNDUCBjb2RlcG9pbnRzLCBpLmUuLCBpdCBpcyBzYWlkOg0KPiA+ID4NCj4g PiA+ICAgIE9uZSBtYXkgc2VsZWN0IGRpZmZlcmVuY2UgZHJvcCBwcmVjZWRlbmNlcyBmb3IgdGhl DQo+ID4gPiAgICBkaWZmZXJlbnQgcGFja2V0cyBpbiB0aGUgbWVkaWEgZmxvdy4gIFRoZXJlZm9y ZSwgYWxsIHBhY2tldHMgaW4gdGhlDQo+ID4gPiAgICBzdHJlYW0gU0hPVUxEIGJlIG1hcmtlZCB3 aXRoIHRoZSBzYW1lIHByaW9yaXR5IGJ1dCBjYW4gaGF2ZQ0KPiA+ID4gICAgZGlmZmVyZW5jZSBk cm9wIHByZWNlZGVuY2VzLg0KPiA+ID4NCj4gPiA+IHdoaWNoIGluZGVlZCBpcyBpbiBjb21wbGlh bmNlIHdpdGggdGhlIHJlY29tbWVuZGF0aW9ucyBwdXQgZm9yd2FyZCBpbg0KPiA+ID4gZHJhZnQt eW9yay1kYXJ0LWRzY3AtcnRwLTAwIGluIHRoYXQNCj4gPiA+IGl0IGVuc3VyZXMgdGhhdCB0aGUg RFNDUCBtYXJraW5ncyAgZG8gbm90IHJlc3VsdCBpbiByZS1vcmRlcmluZw0KPiA+ID4gd2l0aGlu IHRoZSBtZWRpYSBmbG93LCBidXQgaGFzIGl0IGJlZW4gYXNjZXJ0YWluZWQsIGZyb20gYSBDQw0K PiA+ID4gcGVyc3BlY3RpdmUgdGhhdCB1c2FnZSBvZiBkaWZmZXJlbnQgZHJvcCBwcmVjZWRlbmNl IHdpdGhpbiB0aGUgc2FtZSBDQw0KPiA+ID4gY29udGV4dCBpcyB2aWFibGUgPw0KPiA+DQo+ID4g R29vZCBxdWVzdGlvbiAtIEkgd2lsbCBpbmNsdWRlIHRoYXQgaW4gbXkgc2xpZGVzIGZvciB0aGUg ZGFydCBXRyBtZWV0aW5nLg0KPiA+DQo+ID4gPiA+RnJvbSB0aGUgUlRDV0VCIGRhdGEgY2hhbm5l bCBwZXJzcGVjdGl2ZSB0aGlzIGNlcnRhaW5seSBpc24ndCB2aWFibGUNCj4gPiA+ID4oYmVpbmcN Cj4gPiA+IFNDVFAgYmFzZWQpLA0KPiA+ID4gd2hldGhlciBpdCBpcyB2aWFibGUgZnJvbSBhbiBS TUNBVCBDQyBwZXJzcGVjdGl2ZSBpcyBzb21ldGhpbmcgdGhhdCB3ZQ0KPiA+ID4gaW4gdGhlIFJN Q0FUIHdnIHdvdWxkIG5lZWQgdG8gbWFrZSBtb3JlIGNsZWFyLg0KPiA+DQo+ID4gV2hhdCdzIHRo ZSByYXRpb25hbGUgZm9yICJjZXJ0YWlubHkgaXNuJ3QgdmlhYmxlIiByZWdhcmRpbmcgZGlmZmVy ZW50IGRyb3ANCj4gPiBwcmVjZWRlbmNlcyB3aXRoaW4gYSBzaW5nbGUgU0NUUCBzZXNzaW9uPw0K PiBbS2FyZW5dIE9rIC0gImNlcnRhaW5seSBub3QgdmlhYmxlIiBpcyB0b28gc3Ryb25nIGZvcm11 bGF0aW9uLg0KPiBIYXZpbmcgZGlmZmVyZW50IGRyb3AgcHJlY2VkZW5jZXMgd2l0aGluIHRoZSBz YW1lIFNDVFAgQ0MgY29udGV4dCB3b3VsZCwNCj4gZ2l2ZW4gdGhhdCBTQ1RQIENDIHByZXNlbnRs eSBpcyBkcm9wIGRyaXZlbiBvbmx5LA0KPiByZXN1bHRzIGluIHRoYXQgdGhlIHdob2xlIGRhdGEg Y2hhbm5lbCBpcyBpbXBhY3RlZCwgZnJvbSBhIENDIHBlcnNwZWN0aXZlLA0KPiBieSB0aGUgaGln aGVzdCBkcm9wIHByZWNlZGVuY2UuIEJ1dCBJIHJlYWxpemUgdGhhdCB3aGV0aGVyIHRoaXMgaXMN Cj4gYWNjZXB0YWJsZSBpcyBhIHF1ZXN0aW9uIGluZGVlZC4NCj4gDQo+ID4NCj4gPiBUaGFua3Ms DQo+ID4gLS1EYXZpZCAoYXMgYW4gZWRpdG9yIG9mIGRyYWZ0LXlvcmssICpub3QqIGFzIGEgdHN2 d2cgV0cgY2hhaXIpDQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g PiBGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBLYXJlbiBFLg0KPiA+ID4gRWdlZGUgTmllbHNlbg0KPiA+ID4gU2VudDogU3VuZGF5LCBKdWx5 IDIwLCAyMDE0IDQ6NDkgUE0NCj4gPiA+IFRvOiB0c3Z3Z0BpZXRmLm9yZw0KPiA+ID4gQ2M6IHJt Y2F0IFdHDQo+ID4gPiBTdWJqZWN0OiBSZTogW3RzdndnXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm LXRzdndnLXJ0Y3dlYi1xb3MtMDIudHh0DQo+ID4gPg0KPiA+ID4gSGksDQo+ID4gPg0KPiA+ID4g UGxlYXNlIGFjY2VwdCB0aGUgZm9sbG93aW5nIGNvbW1lbnRzOg0KPiA+ID4NCj4gPiA+IEkgd29u ZGVyIGlmIHRoZSByZWNvbW1lbmRhdGlvbnMgb2YgdGhpcyBkb2N1bWVudCBzaG91bGQgbm90IHJl bGF0ZSB0bw0KPiA+ID4gdGhlIHZpYWJpbGl0eSAob3IgcmF0aGVyIHRoZSBvcHBvc2l0ZSkgb2Yg aGFuZGxpbmcgZGlmZmVyZW50IFJUQ1dFQg0KPiA+ID4gZGF0YSBjaGFubmVscyBpbmRpdmlkdWFs bHkgZnJvbSBhIERTQ1AgbWFya2luZ3MgcGVyc3BlY3RpdmUuIE9yIG1vcmUNCj4gPiA+IGdlbmVy YWxseSByZWxhdGUgdG8gdGhlIGZhY3QgdGhhdCBtZWRpYSBzdHJlYW1zIHdpdGhpbiB0aGUgc2Ft ZQ0KPiA+ID4gY29uZ2VzdGlvbiBjb250cm9sIGNvbnRleHQgY2Fubm90IGJlIGhhbmRsZWQgaW5k aXZpZHVhbGx5Lg0KPiA+ID4gUmlnaHQgbm93IHN1Y2ggY29uc2lkZXJhdGlvbnMgYXJlIG5vdCBp biB0aGUgZG9jdW1lbnQuIElmIHRoZQ0KPiA+ID4gaW50ZW50aW9uIGlzIGZvciBzdWNoIGNvbnNp ZGVyYXRpb24gdG8gY29tZSBpbiBkb2N1bWVudHMgZnJvbSB0aGUgZGFydA0KPiA+ID4gd2csIHRo ZW4gaXQgd291bGQgYmUgdmVyeSBpbXBvcnRhbnQgdG8gIGhhdmUgYSByZWZlcmVuY2UgdG8gdGhp cw0KPiA+ID4gZGVwZW5kZW5jeSAtIG9yID8NCj4gPiA+DQo+ID4gPiBTb21ldGhpbmcgZWxzZToN Cj4gPiA+DQo+ID4gPiBSaWdodCBub3cgdGhlIGRvY3VtZW50IHN0aXB1bGF0ZXMgdGhhdCBwYWNr ZXRzIHdpdGhpbiB0aGUgc2FtZSBtZWRpYQ0KPiA+ID4gc3RyZWFtIG1heSBiZSBtYXJrZWQgd2l0 aCBkaWZmZXJlbnQgRFNDUCBjb2RlcG9pbnRzLCBpLmUuLCBpdCBpcyBzYWlkOg0KPiA+ID4NCj4g PiA+ICAgIE9uZSBtYXkgc2VsZWN0IGRpZmZlcmVuY2UgZHJvcCBwcmVjZWRlbmNlcyBmb3IgdGhl DQo+ID4gPiAgICBkaWZmZXJlbnQgcGFja2V0cyBpbiB0aGUgbWVkaWEgZmxvdy4gIFRoZXJlZm9y ZSwgYWxsIHBhY2tldHMgaW4gdGhlDQo+ID4gPiAgICBzdHJlYW0gU0hPVUxEIGJlIG1hcmtlZCB3 aXRoIHRoZSBzYW1lIHByaW9yaXR5IGJ1dCBjYW4gaGF2ZQ0KPiA+ID4gICAgZGlmZmVyZW5jZSBk cm9wIHByZWNlZGVuY2VzLg0KPiA+ID4NCj4gPiA+IHdoaWNoIGluZGVlZCBpcyBpbiBjb21wbGlh bmNlIHdpdGggdGhlIHJlY29tbWVuZGF0aW9ucyBwdXQgZm9yd2FyZCBpbg0KPiA+ID4gZHJhZnQt eW9yay1kYXJ0LWRzY3AtcnRwLTAwIGluIHRoYXQNCj4gPiA+IGl0IGVuc3VyZXMgdGhhdCB0aGUg RFNDUCBtYXJraW5ncyAgZG8gbm90IHJlc3VsdCBpbiByZS1vcmRlcmluZw0KPiA+ID4gd2l0aGlu IHRoZSBtZWRpYSBmbG93LCBidXQgaGFzIGl0IGJlZW4gYXNjZXJ0YWluZWQsIGZyb20gYSBDQw0K PiA+ID4gcGVyc3BlY3RpdmUgdGhhdCB1c2FnZSBvZiBkaWZmZXJlbnQgZHJvcCBwcmVjZWRlbmNl IHdpdGhpbiB0aGUgc2FtZSBDQw0KPiA+ID4gY29udGV4dCBpcyB2aWFibGUgPw0KPiA+ID4NCj4g PiA+ID5Gcm9tIHRoZSBSVENXRUIgZGF0YSBjaGFubmVsIHBlcnNwZWN0aXZlIHRoaXMgY2VydGFp bmx5IGlzbid0IHZpYWJsZQ0KPiA+ID4gPihiZWluZw0KPiA+ID4gU0NUUCBiYXNlZCksDQo+ID4g PiB3aGV0aGVyIGl0IGlzIHZpYWJsZSBmcm9tIGFuIFJNQ0FUIENDIHBlcnNwZWN0aXZlIGlzIHNv bWV0aGluZyB0aGF0IHdlDQo+ID4gPiBpbiB0aGUgUk1DQVQgd2cgd291bGQgbmVlZCB0byBtYWtl IG1vcmUgY2xlYXIuDQo+ID4gPg0KPiA+ID4gQlIsIEthcmVuDQo+ID4gPg0KPiA+ID4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiBGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndn LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBpbnRlcm5ldC0NCj4gPiA+ID4gZHJhZnRz QGlldGYub3JnDQo+ID4gPiA+IFNlbnQ6IDIzLiBqdW5pIDIwMTQgMjE6MTINCj4gPiA+ID4gVG86 IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPiA+ID4gPiBDYzogdHN2d2dAaWV0Zi5vcmcNCj4gPiA+ ID4gU3ViamVjdDogW3RzdndnXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1x b3MtMDIudHh0DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IEEgTmV3IEludGVybmV0LURyYWZ0 IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPiA+ID4gPiBk aXJlY3Rvcmllcy4NCj4gPiA+ID4gIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFRy YW5zcG9ydCBBcmVhIFdvcmtpbmcgR3JvdXANCj4gPiA+ID4gV29ya2luZyBHcm91cCBvZiB0aGUg SUVURi4NCj4gPiA+ID4NCj4gPiA+ID4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBEU0NQIGFu ZCBvdGhlciBwYWNrZXQgbWFya2luZ3MgZm9yIFJUQ1dlYg0KPiA+ID4gPiBRb1MNCj4gPiA+ID4g ICAgICAgICBBdXRob3JzICAgICAgICAgOiBTdWJoYSBEaGVzaWthbg0KPiA+ID4gPiAgICAgICAg ICAgICAgICAgICAgICAgICAgIEN1bGxlbiBKZW5uaW5ncw0KPiA+ID4gPiAgICAgICAgICAgICAg ICAgICAgICAgICAgIERhbiBEcnV0YQ0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAg IFBhdWwgSm9uZXMNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBKYW1lcyBQb2xr DQo+ID4gPiA+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3Mt MDIudHh0DQo+ID4gPiA+IAlQYWdlcyAgICAgICAgICAgOiA3DQo+ID4gPiA+IAlEYXRlICAgICAg ICAgICAgOiAyMDE0LTA2LTIzDQo+ID4gPiA+DQo+ID4gPiA+IEFic3RyYWN0Og0KPiA+ID4gPiAg ICBNYW55IG5ldHdvcmtzLCBzdWNoIGFzIHNlcnZpY2UgcHJvdmlkZXIgYW5kIGVudGVycHJpc2Ug bmV0d29ya3MsDQo+ID4gPiA+IGNhbg0KPiA+ID4gPiAgICBwcm92aWRlIHBlciBwYWNrZXQgdHJl YXRtZW50cyBiYXNlZCBvbiBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlcyBDb2RlDQo+ID4gPiA+ICAg IFBvaW50cyAoRFNDUCkgb24gYSBwZXItaG9wIGJhc2lzLiAgVGhpcyBkb2N1bWVudCBwcm92aWRl cyB0aGUNCj4gPiA+ID4gICAgcmVjb21tZW5kZWQgRFNDUCB2YWx1ZXMgZm9yIGJyb3dzZXJzIHRv IHVzZSBmb3IgdmFyaW91cyBjbGFzc2VzIG9mDQo+ID4gPiA+ICAgIHRyYWZmaWMuDQo+ID4gPiA+ DQo+ID4gPiA+DQo+ID4gPiA+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0 aGlzIGRyYWZ0IGlzOg0KPiA+ID4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3MvDQo+ID4gPiA+DQo+ID4gPiA+IFRoZXJlJ3MgYWxz byBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPiA+ID4gPiBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3MtMDINCj4gPiA+ID4NCj4g PiA+ID4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0K PiA+ID4gPiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRzdndn LXJ0Y3dlYi1xb3MtMDINCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPiA+ ID4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0DQo+ID4gPiA+IHRvb2xzLmlldGYub3JnLg0KPiA+ID4gPg0KPiA+ID4gPiBJbnRl cm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ID4g PiA+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo= From nobody Sun Jul 20 21:54:44 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6391B2CAE for ; Sun, 20 Jul 2014 21:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 i3CTAeMwx_xu for ; Sun, 20 Jul 2014 21:54:39 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [142.59.210.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0E8E1B2AC4 for ; Sun, 20 Jul 2014 21:54:39 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s6L4scsD020842; Sun, 20 Jul 2014 22:54:38 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s6L4scbX019464; Sun, 20 Jul 2014 22:54:38 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id s6L4sbXf019463; Sun, 20 Jul 2014 22:54:37 -0600 Date: Sun, 20 Jul 2014 22:54:37 -0600 From: "Brian F. G. Bidulock" To: "Karen E. Egede Nielsen" Message-ID: <20140721045437.GA19231@openss7.org> Mail-Followup-To: "Karen E. Egede Nielsen" , tsvwg@ietf.org References: <3e766b0d446e695da4315465b6a3595a@mail.gmail.com> <20140720213823.GA14062@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/a-x5tW60OoGCe_2vIpWD2E_lEwI Cc: tsvwg@ietf.org Subject: Re: [tsvwg] comments to RFC3758 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 04:54:41 -0000 Karen, Please see comments below... Karen E. Egede Nielsen wrote: (Mon, 21 Jul 2014 01:03:59) > > > > (3) > > > If the decision to "abandon" a chunk is made, no matter how such a > > > decision is made, the appropriate congestion adjustment MUST be > > > made as specified in RFC 2960 if the chunk would have been marked > > > for retransmission later (e.g., either by T3-Timeout or by Fast > > > Retransmit). > > > [Karen] I cannot see that 3 says this. Such an interpretation of (3) > presumes that a message is only abandoned at a T3 or when marked for > fast retransmission. Furthermore 3 speaks about congestion control > adjustments not about inflight or rwnd. > > BR, Karen > > The document does not presume that If "the chunk would have been marked for retransmission later", then it would have been considered in flight had it not been "abandoned". Therefore, (3) effectively says that the abandoned chunk must continue to be considered in flight for as long as it would have been had it not been abandoned, which would be until the next T3-expiry or an ack. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From nobody Sun Jul 20 22:40:22 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9132A1B2DA9 for ; Sun, 20 Jul 2014 22:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 20MLTJ5YU8R9 for ; Sun, 20 Jul 2014 22:39:52 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7A271B2DA7 for ; Sun, 20 Jul 2014 22:39:52 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s6L5dRsG020680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 20 Jul 2014 22:39:30 -0700 (PDT) Message-ID: <53CCA790.105@isi.edu> Date: Sun, 20 Jul 2014 22:39:28 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Black, David" , "tsvwg@ietf.org" References: <8D3D17ACE214DC429325B2B98F3AE71207783F636C@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71207783F636C@MX15A.corp.emc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/09vXvdMEzmq7S4AUpHRr09D9Py8 Subject: Re: [tsvwg] Toronto Tue agenda posted, send slides!! X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 05:39:58 -0000 Hi, David (et al.), There are no slides for the port use doc. I did not request a slot, and am not attending. The next step is for me to post a summary of the issues raised during WGLC and resolve those issues in an updated document, but that was not ready in time for the draft deadline, so I had not planned on having anything presented. Joe On 7/20/2014 12:19 PM, Black, David wrote: > The tsvwg agenda for Tuesday (both sessions) was posted a while back: > > https://datatracker.ietf.org/meeting/90/agenda/tsvwg/ > > Those presenters who haven't already sent slides (thank you to those who > have) should send slides ASAP, by mid-day Monday at the latest please. > > If the tsvwg meeting starts on Tuesday w/o slides for an agenda item, > the chairs may impose a 3-5min time limit for a brief verbal summary + Q&A. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > From nobody Mon Jul 21 00:49:26 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E6B1B2DC5; Mon, 21 Jul 2014 00:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=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 aGg5DM2K12Hs; Mon, 21 Jul 2014 00:49:21 -0700 (PDT) Received: from mailms.fh-muenster.de (mail.fh-muenster.de [212.201.120.190]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD36C1B2DC8; Mon, 21 Jul 2014 00:49:15 -0700 (PDT) Received: from [10.0.1.121] (unknown [212.201.121.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ruengele) by mailms.fh-muenster.de (Postfix) with ESMTPSA id 8AF9B296BE6; Mon, 21 Jul 2014 09:49:13 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_840D47F0-AEEE-4DBC-BEBE-62C265D7C4ED" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: =?iso-8859-1?Q?Irene_R=FCngeler?= In-Reply-To: <53B5183A.7060301@erg.abdn.ac.uk> Date: Mon, 21 Jul 2014 09:48:55 +0200 Message-Id: References: <53B5183A.7060301@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/VTgejRM-_B-QjZgL_PUHaJImz7o Cc: tsvwg-chairs@ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-prpolicies-03 - due to conclude Monday, July 21st, 2014 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 07:49:23 -0000 --Apple-Mail=_840D47F0-AEEE-4DBC-BEBE-62C265D7C4ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, I have read this version of the draft and support its progression to = RFC. Best regards Irene Am 03.07.2014 um 10:45 schrieb Gorry Fairhurst : > This is the start of the WGLC on "Additional Policies for the Partial = Reliability Extension of the Stream Control Transmission Protocol" for = publication intended as a PS. >=20 > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-prpolicies/ >=20 > This WGLC will last until Monday, July 21st, 2014 (longer since this = includes time prior to an IETF meeting). >=20 > Could people please send *any* comments to the list if they think this = is ready to publish? >=20 > A good note is "I have read this version of the draft, > and I approve (or support) its progression to RFC". >=20 > James/Gorry/David > TSVWG chairs >=20 ***************************************** Dr. Irene R=FCngeler=20 Fachhochschule M=FCnster, Abt. Steinfurt=20 FB Elektrotechnik und Informatik=20 Labor f=FCr Netzwerkprogrammierung, Datenbanklabor=20 Bismarckstr. 11=20 Tel.: 02551-962561=20 Fax: 02551-962563=20 EMail: I.Ruengeler@fh-muenster.de --Apple-Mail=_840D47F0-AEEE-4DBC-BEBE-62C265D7C4ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi,

I have read this version of = the draft and support its progression to = RFC.

Best = regards

Irene

Am = 03.07.2014 um 10:45 schrieb Gorry Fairhurst <gorry@erg.abdn.ac.uk>:
This is = the start of the WGLC on "Additional Policies for the Partial = Reliability Extension of the Stream Control Transmission Protocol" for = publication intended as a PS.

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-prpolicies/
This WGLC will last until Monday, July 21st, 2014 (longer since = this includes time prior to an IETF meeting).

Could people please = send *any* comments to the list if they think this is ready to = publish?

A good note is "I have read this version of the = draft,
and I approve (or support) its progression to = RFC".

James/Gorry/David
TSVWG = chairs


*****************************************

Dr. Irene R=FCngeler 
Fachhochschule M=FCnster, Abt. = Steinfurt 
FB Elektrotechnik und = Informatik 
Labor f=FCr = Netzwerkprogrammierung, Datenbanklabor 
Bismarckstr. 11 
Tel.: = 02551-962561 
Fax: = 02551-962563 
EMail: I.Ruengeler@fh-muenster.de<= /font>





= --Apple-Mail=_840D47F0-AEEE-4DBC-BEBE-62C265D7C4ED-- From nobody Mon Jul 21 04:08:53 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DA01B2B8D; Mon, 21 Jul 2014 04:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 xJyskRcg4oMG; Mon, 21 Jul 2014 04:08:44 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28FF61B2D7A; Mon, 21 Jul 2014 04:08:42 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ho1so3833565wib.4 for ; Mon, 21 Jul 2014 04:08:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pLkTQD094eHAhomXeoG/pby02ikZqHfmtvVX0wT4PDs=; b=AGRdiqrb/cpqmyTXbRGdU1oIaU5gs+2+PgT1FrUMaVbzaGBMC30jjivBRfNflrJuXF ji7Dh2v7tgr9uLvyEmHl2TFxFEP0NZJJ0IhM9CnnXxdY9dpGEOVBLid5QyKUZbOvLX0c gXoBd/rqE7dXib67ztdLiB57ibmw6hIyFpshVLKqohqyyj9vAUq8iFDw0zuPLIy+Cu9w MdEfZHW5Vpa7tASERSP4/G3UwxJR+uYd5btNDcGUgLkCqOHhEpXWk3BmFDWQqQVTsWen mQF1M3UmXQoXPCa4x6zQ01VmYsK1KITPgO/GH5EYndVXlUH0iwdSpZRwMuNfJQl69y5r JeDA== X-Received: by 10.194.48.103 with SMTP id k7mr21719127wjn.68.1405940919969; Mon, 21 Jul 2014 04:08:39 -0700 (PDT) Received: from [31.133.140.161] (dhcp-8ca1.meeting.ietf.org. [31.133.140.161]) by mx.google.com with ESMTPSA id lk7sm36836510wjb.24.2014.07.21.04.08.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 04:08:39 -0700 (PDT) Message-ID: <53CCF4B1.6030004@gmail.com> Date: Mon, 21 Jul 2014 23:08:33 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Black, David" References: <20140623191132.21904.23978.idtracker@ietfa.amsl.com> <1373b5f3f2f88c06aafc0deb45287f61@mail.gmail.com> <8D3D17ACE214DC429325B2B98F3AE71207783F6386@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71207783F6399@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71207783F6399@MX15A.corp.emc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/kGIX537u_XI8_MnRCJsPqVlFIk4 Cc: "Karen E. Egede Nielsen" , rmcat WG , "dart@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 11:08:47 -0000 On 21/07/2014 14:00, Black, David wrote: > Karen, > >>> What's the rationale for "certainly isn't viable" regarding different drop >>> precedences within a single SCTP session? >> [Karen] Ok - "certainly not viable" is too strong formulation. >> Having different drop precedences within the same SCTP CC context would, >> given that SCTP CC presently is drop driven only, >> results in that the whole data channel is impacted, from a CC perspective, >> by the highest drop precedence. But I realize that whether this is >> acceptable is a question indeed. > > I think you're on to something here. If the drop precedences only came into > play after the decision to drop a packet had been made, their effect would > probably be minimal, as they would only affect what to drop in a session, not > how much to drop. OTOH, DiffServ AF is not intended to operate in that fashion > - the rationale for the 3 drop precedences per AF class was based on envisioning > the output of two-threshold rate shaper: > AFx1 - Within base or committed traffic profile > AFx2 - Beyond base/committed, but within excess or burst traffic profile > AFx3 - Completely out of profile > > Hence the relative mix of those drop precedences can be expected to affect > the overall drop rate/probability seen in a session where those precedences > are mixed. Yes. And it was clearly aimed at layered video, such that there was a benefit to the end user in dropping the least important layer during lossy periods. With anything like a TCP-like congestion control algorithm in sight, the effects may be completely bizarre. Brian > > Thanks, > --David > >> -----Original Message----- >> From: Karen E. Egede Nielsen [mailto:karen.nielsen@tieto.com] >> Sent: Sunday, July 20, 2014 9:20 PM >> To: Black, David; tsvwg@ietf.org >> Cc: rmcat WG; dart@ietf.org >> Subject: RE: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt >> >> Hi, >> >>> -----Original Message----- >>> From: Black, David [mailto:david.black@emc.com] >>> Sent: 21. juli 2014 02:51 >>> To: Karen E. Egede Nielsen; tsvwg@ietf.org >>> Cc: rmcat WG; dart@ietf.org; Black, David >>> Subject: RE: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt >>> >>> Karen, >>> >>> , [+dart list] >>> >>>> I wonder if the recommendations of this document should not relate to >>>> the viability (or rather the opposite) of handling different RTCWEB >>>> data channels individually from a DSCP markings perspective. Or more >>>> generally relate to the fact that media streams within the same >>>> congestion control context cannot be handled individually. >>>> Right now such considerations are not in the document. If the >>>> intention is for such consideration to come in documents from the dart >>>> wg, then it would be very important to have a reference to this >>>> dependency - or ? >>> IMHO, such a reference is necessary, although the dart WG draft will be >>> informational. The reference should be added once there is an official >>> dart >>> WG draft (likely to happen this week). >>> >>>> Something else: >>>> >>>> Right now the document stipulates that packets within the same media >>>> stream may be marked with different DSCP codepoints, i.e., it is said: >>>> >>>> One may select difference drop precedences for the >>>> different packets in the media flow. Therefore, all packets in the >>>> stream SHOULD be marked with the same priority but can have >>>> difference drop precedences. >>>> >>>> which indeed is in compliance with the recommendations put forward in >>>> draft-york-dart-dscp-rtp-00 in that >>>> it ensures that the DSCP markings do not result in re-ordering >>>> within the media flow, but has it been ascertained, from a CC >>>> perspective that usage of different drop precedence within the same CC >>>> context is viable ? >>> Good question - I will include that in my slides for the dart WG meeting. >>> >>>> >From the RTCWEB data channel perspective this certainly isn't viable >>>>> (being >>>> SCTP based), >>>> whether it is viable from an RMCAT CC perspective is something that we >>>> in the RMCAT wg would need to make more clear. >>> What's the rationale for "certainly isn't viable" regarding different drop >>> precedences within a single SCTP session? >> [Karen] Ok - "certainly not viable" is too strong formulation. >> Having different drop precedences within the same SCTP CC context would, >> given that SCTP CC presently is drop driven only, >> results in that the whole data channel is impacted, from a CC perspective, >> by the highest drop precedence. But I realize that whether this is >> acceptable is a question indeed. >> >>> Thanks, >>> --David (as an editor of draft-york, *not* as a tsvwg WG chair) >>> >>>> -----Original Message----- >>>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Karen E. >>>> Egede Nielsen >>>> Sent: Sunday, July 20, 2014 4:49 PM >>>> To: tsvwg@ietf.org >>>> Cc: rmcat WG >>>> Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt >>>> >>>> Hi, >>>> >>>> Please accept the following comments: >>>> >>>> I wonder if the recommendations of this document should not relate to >>>> the viability (or rather the opposite) of handling different RTCWEB >>>> data channels individually from a DSCP markings perspective. Or more >>>> generally relate to the fact that media streams within the same >>>> congestion control context cannot be handled individually. >>>> Right now such considerations are not in the document. If the >>>> intention is for such consideration to come in documents from the dart >>>> wg, then it would be very important to have a reference to this >>>> dependency - or ? >>>> >>>> Something else: >>>> >>>> Right now the document stipulates that packets within the same media >>>> stream may be marked with different DSCP codepoints, i.e., it is said: >>>> >>>> One may select difference drop precedences for the >>>> different packets in the media flow. Therefore, all packets in the >>>> stream SHOULD be marked with the same priority but can have >>>> difference drop precedences. >>>> >>>> which indeed is in compliance with the recommendations put forward in >>>> draft-york-dart-dscp-rtp-00 in that >>>> it ensures that the DSCP markings do not result in re-ordering >>>> within the media flow, but has it been ascertained, from a CC >>>> perspective that usage of different drop precedence within the same CC >>>> context is viable ? >>>> >>>> >From the RTCWEB data channel perspective this certainly isn't viable >>>>> (being >>>> SCTP based), >>>> whether it is viable from an RMCAT CC perspective is something that we >>>> in the RMCAT wg would need to make more clear. >>>> >>>> BR, Karen >>>> >>>>> -----Original Message----- >>>>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of internet- >>>>> drafts@ietf.org >>>>> Sent: 23. juni 2014 21:12 >>>>> To: i-d-announce@ietf.org >>>>> Cc: tsvwg@ietf.org >>>>> Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.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 >>>>> Working Group of the IETF. >>>>> >>>>> Title : DSCP and other packet markings for RTCWeb >>>>> QoS >>>>> Authors : Subha Dhesikan >>>>> Cullen Jennings >>>>> Dan Druta >>>>> Paul Jones >>>>> James Polk >>>>> Filename : draft-ietf-tsvwg-rtcweb-qos-02.txt >>>>> Pages : 7 >>>>> Date : 2014-06-23 >>>>> >>>>> Abstract: >>>>> Many networks, such as service provider and enterprise networks, >>>>> can >>>>> provide per packet treatments based on Differentiated Services Code >>>>> Points (DSCP) on a per-hop basis. This document provides the >>>>> recommended DSCP values for browsers to use for various classes of >>>>> traffic. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/ >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-02 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rtcweb-qos-02 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission until the htmlized version and diff are available at >>>>> tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 21 05:14:21 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612C91B2D4A; Mon, 21 Jul 2014 05:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 6z9yxx9ClsHv; Mon, 21 Jul 2014 05:13:39 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 24A2A1B2884; Mon, 21 Jul 2014 05:13:38 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1X9CTI-0003KY-9v; Mon, 21 Jul 2014 14:13:36 +0200 Received: from dhcp-8bda.meeting.ietf.org ([31.133.139.218]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1X9CTH-00040B-LZ; Mon, 21 Jul 2014 14:13:36 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <53CCF4B1.6030004@gmail.com> Date: Mon, 21 Jul 2014 14:13:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140623191132.21904.23978.idtracker@ietfa.amsl.com> <1373b5f3f2f88c06aafc0deb45287f61@mail.gmail.com> <8D3D17ACE214DC429325B2B98F3AE71207783F6386@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71207783F6399@MX15A.corp.emc.com> <53CCF4B1.6030004@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 4 sum rcpts/h 12 sum msgs/h 5 total rcpts 18561 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6024BC657B88BEF5A70F9DE2D49E9E0F5F1A2150 X-UiO-SPAM-Test: remote_host: 31.133.139.218 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 37 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/yb1mth3K3mntHxqQUcgVwGO1rUY Cc: "Karen E. Egede Nielsen" , rmcat WG , "dart@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 12:14:02 -0000 On 21. juli 2014, at 13:08, Brian E Carpenter = wrote: > On 21/07/2014 14:00, Black, David wrote: >> Karen, >>=20 >>>> What's the rationale for "certainly isn't viable" regarding = different drop >>>> precedences within a single SCTP session? >>> [Karen] Ok - "certainly not viable" is too strong formulation. >>> Having different drop precedences within the same SCTP CC context = would, >>> given that SCTP CC presently is drop driven only, >>> results in that the whole data channel is impacted, from a CC = perspective, >>> by the highest drop precedence. But I realize that whether this is >>> acceptable is a question indeed. >>=20 >> I think you're on to something here. If the drop precedences only = came into >> play after the decision to drop a packet had been made, their effect = would >> probably be minimal, as they would only affect what to drop in a = session, not >> how much to drop. OTOH, DiffServ AF is not intended to operate in = that fashion >> - the rationale for the 3 drop precedences per AF class was based on = envisioning >> the output of two-threshold rate shaper: >> AFx1 - Within base or committed traffic profile >> AFx2 - Beyond base/committed, but within excess or burst traffic = profile >> AFx3 - Completely out of profile >>=20 >> Hence the relative mix of those drop precedences can be expected to = affect >> the overall drop rate/probability seen in a session where those = precedences >> are mixed. >=20 > Yes. And it was clearly aimed at layered video, such that there was > a benefit to the end user in dropping the least important layer > during lossy periods. With anything like a TCP-like congestion > control algorithm in sight, the effects may be completely bizarre. Reordering could make this even worse. Could different drop precedences = cause reordering? Cheers, Michael From nobody Mon Jul 21 05:25:39 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BD01B2DD9; Mon, 21 Jul 2014 05:25:35 -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] autolearn=ham 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 fqdTANcgnMJz; Mon, 21 Jul 2014 05:25:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC661B2CE8; Mon, 21 Jul 2014 05:25:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721122532.23928.3517.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 05:25:32 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/CJj3a0DDR5ZvqFQu36ZtKuiTgmc Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-failover-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 12:25:35 -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 Working Group of the IETF. Title : Quick Failover Algorithm in SCTP Authors : Yoshifumi Nishida Preethi Natarajan Armando Caro Paul D. Amer Karen E. E. Nielsen Filename : draft-ietf-tsvwg-sctp-failover-05.txt Pages : 17 Date : 2014-07-21 Abstract: One of the major advantages of SCTP is that it supports multi-homed communication. A multi-homed SCTP end-point has the ability to withstand network failures by migrating the traffic from an inactive network to an active one. However, if the [RFC4960] specified failover operation is followed there can be a significant delay in the migration to the active destination addresses, thus severely reducing the effectiveness of SCTP multi-homed operation. The memo complements RFC4960 by the introduction of the Potentially Failed state and associated new Quick Failover operation to apply during network failure and specifies for SCTP senders to support this more performance optimal failover procedure as an add-on to the [RFC4960] failover operation. The memo in addition complements [RFC4960] by introduction of alternative switchover operation modes for the data transfer path management after a failover. These operation modes offer for more performance optimal operation in some network environments. From the perspective of this memo the implementation of the additional switchover operation modes is considered optional. The procedures defined require only minimal modifications to the current specification. The procedures are sender-side only and do not impact the SCTP receiver. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-failover/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-failover-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-failover-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 Jul 21 06:02:49 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CCF1B2946; Mon, 21 Jul 2014 06:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 wg5zoM07g8SA; Mon, 21 Jul 2014 06:02:44 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 072721B2BC1; Mon, 21 Jul 2014 06:02:40 -0700 (PDT) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s6LD2ai5007565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2014 09:02:37 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s6LD2ai5007565 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1405947758; bh=24HeUWi1xnoe1yrrz34OJ548KIk=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=SVmsml5QfwXNMs+RagKsrHLUOIX0b/Chv5HnxTdzmbNCavHNjLR+8sXMRiN+clRND j1kuXHxoV7aCmCpLOm1D0r8FFYEBQy3uyv4Yt6Y69wDVYORhDOAcji4h1if9qeiSt5 H8uqIgpXfUH9sRl4j39DQ6bHgjnZpLiKfQvNSZzA= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s6LD2ai5007565 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd56.lss.emc.com (RSA Interceptor); Mon, 21 Jul 2014 09:02:20 -0400 Received: from mxhub20.corp.emc.com (mxhub20.corp.emc.com [10.254.93.49]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s6LD2JuI005897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jul 2014 09:02:19 -0400 Received: from mx15a.corp.emc.com ([169.254.1.186]) by mxhub20.corp.emc.com ([10.254.93.49]) with mapi; Mon, 21 Jul 2014 09:02:19 -0400 From: "Black, David" To: Michael Welzl , Brian E Carpenter Date: Mon, 21 Jul 2014 09:02:17 -0400 Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt Thread-Index: Ac+k3TTr8iUPhOT8Qg+6sRLudWbtEAABnElQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE71207783F6420@MX15A.corp.emc.com> References: <20140623191132.21904.23978.idtracker@ietfa.amsl.com> <1373b5f3f2f88c06aafc0deb45287f61@mail.gmail.com> <8D3D17ACE214DC429325B2B98F3AE71207783F6386@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71207783F6399@MX15A.corp.emc.com> <53CCF4B1.6030004@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/uOtGPs0WLTTTO9jKpaoG0_6RC5Q Cc: "Karen E. Egede Nielsen" , rmcat WG , "dart@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 13:02:48 -0000 > >> Hence the relative mix of those drop precedences can be expected to af= fect > >> the overall drop rate/probability seen in a session where those preced= ences > >> are mixed. > > > > Yes. And it was clearly aimed at layered video, such that there was > > a benefit to the end user in dropping the least important layer > > during lossy periods. With anything like a TCP-like congestion > > control algorithm in sight, the effects may be completely bizarre. >=20 > Reordering could make this even worse. Could different drop precedences c= ause > reordering? No, packets MUST NOT be reordered among the three drop precedences within an AF class (e.g., AF2x). See RFC 2597 and draft-york. Thanks, --David > -----Original Message----- > From: Michael Welzl [mailto:michawe@ifi.uio.no] > Sent: Monday, July 21, 2014 8:14 AM > To: Brian E Carpenter > Cc: Black, David; Karen E. Egede Nielsen; rmcat WG; dart@ietf.org; > tsvwg@ietf.org > Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt >=20 >=20 > On 21. juli 2014, at 13:08, Brian E Carpenter > wrote: >=20 > > On 21/07/2014 14:00, Black, David wrote: > >> Karen, > >> > >>>> What's the rationale for "certainly isn't viable" regarding differen= t > drop > >>>> precedences within a single SCTP session? > >>> [Karen] Ok - "certainly not viable" is too strong formulation. > >>> Having different drop precedences within the same SCTP CC context wou= ld, > >>> given that SCTP CC presently is drop driven only, > >>> results in that the whole data channel is impacted, from a CC perspec= tive, > >>> by the highest drop precedence. But I realize that whether this is > >>> acceptable is a question indeed. > >> > >> I think you're on to something here. If the drop precedences only cam= e > into > >> play after the decision to drop a packet had been made, their effect w= ould > >> probably be minimal, as they would only affect what to drop in a sessi= on, > not > >> how much to drop. OTOH, DiffServ AF is not intended to operate in tha= t > fashion > >> - the rationale for the 3 drop precedences per AF class was based on > envisioning > >> the output of two-threshold rate shaper: > >> AFx1 - Within base or committed traffic profile > >> AFx2 - Beyond base/committed, but within excess or burst traffic prof= ile > >> AFx3 - Completely out of profile > >> > >> Hence the relative mix of those drop precedences can be expected to af= fect > >> the overall drop rate/probability seen in a session where those preced= ences > >> are mixed. > > > > Yes. And it was clearly aimed at layered video, such that there was > > a benefit to the end user in dropping the least important layer > > during lossy periods. With anything like a TCP-like congestion > > control algorithm in sight, the effects may be completely bizarre. >=20 > Reordering could make this even worse. Could different drop precedences c= ause > reordering? >=20 > Cheers, > Michael From nobody Mon Jul 21 08:04:06 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23DE91B2805 for ; Sat, 19 Jul 2014 12:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 vo80TV-PB910 for ; Sat, 19 Jul 2014 12:06:53 -0700 (PDT) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209541B2804 for ; Sat, 19 Jul 2014 12:06:53 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id hn18so1657498igb.3 for ; Sat, 19 Jul 2014 12:06:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=hPT1FX5E8SoSahiPFIoD4D8TC0er93237ItwArposXI=; b=YPDH+SEMhOIzJ4H6xE7+R8UHqQ6+MB7+Euk/RkcGZ4rjmLfIRW/A19Yjv2rYHE9EFi RSE6Id+fJhXiCwn6yIPFHDNFXdUbjawxMRWDT7g5FevIILdUcmohcqfS0i9qWOg49Fw7 WGpCzKP7+xYXfxe5GFLZqPMihLJwj83o2OUqjEWa9whpO6NaH50WMk7wndcIxjB0uiD3 0j4bdhaPvjcfvUJ2lU7sDpcr4ijYvXPiN+X3abPvB98o43MU/dORQO7wHMsGPLKkcEwd ac2WWaHCYiHBr3SFhQwPNKAwm6ffQfgUxf+KZDK+d9Iw7PxOlcf+0lJ2+9H7WtyRIb+U Xb9A== X-Gm-Message-State: ALoCoQnl7PuPPyYp4PlhQNvKskJ2eLOOVX1h6Ts0aGgUFDg26+74dow/eH9BQoekZdXW0+Y5azPL X-Received: by 10.50.33.16 with SMTP id n16mr52261782igi.15.1405796812227; Sat, 19 Jul 2014 12:06:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.82.199 with HTTP; Sat, 19 Jul 2014 12:06:32 -0700 (PDT) From: Jamal Hadi Salim Date: Sat, 19 Jul 2014 15:06:32 -0400 Message-ID: To: tsvwg Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/jQeH9O1bY3whtmhkInSmvaZHz-E X-Mailman-Approved-At: Mon, 21 Jul 2014 08:03:57 -0700 Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-prpolicies-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 19:06:54 -0000 I have read the draft and happy with the outcome. I believe it is ready for publication. cheers, jamal From nobody Tue Jul 22 05:56:54 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B36E1A00A8; Tue, 22 Jul 2014 05:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham 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 Nsypnycev0Df; Tue, 22 Jul 2014 05:56:50 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB571A0B0B; Tue, 22 Jul 2014 05:56:49 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6MCumD7016927; Tue, 22 Jul 2014 13:56:48 +0100 Received: from 950129200 (dhcp-b3fb.meeting.ietf.org [31.133.179.251]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6MCukhi016913 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Jul 2014 13:56:47 +0100 From: "Adrian Farrel" To: , Date: Tue, 22 Jul 2014 13:56:50 +0100 Message-ID: <0a5301cfa5ac$6825a810$3870f830$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+lrDblFl8JW6QbRJmmL3RziD80Ig== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20832.007 X-TM-AS-Result: No--12.942-10.0-31-10 X-imss-scan-details: No--12.942-10.0-31-10 X-TMASE-MatchedRID: oXSYuYko9fW+f4AWV7koYpFVDMlVCkWeRNgaAQZwtvLSYAzZ6KmqWiDV X+rtfKhFe90HnwLjz9Ybv5DeMKZl+XHVdX7/QM0wALBxQHkJtWr6mRiZWXNny+jCW3sOvH3bxcb MLAKq7YqXFZdE28TAzJuVoHk2NGVjRzLiTrEr9wL6daZahG7qsaO7Nt6iP+dX+3g863hsMpHa0c p3Dczxw/i12qLq8EUdrAnhCV4MJPmveTp3UjBuIPzu9Lw9C7fAaIqWsHxNIOrD3h2nmZ4BQRND3 wNw/alWc5hDpbdtHF4n9WsdM8RFdF2kuSHmn3uDzFOoeBdH/n2TgV2heE0WDQZbeEWcL03VWXOj 3NIpqIo7ef1IrGI+Tgh//gBB6K3YwacxYVzCGcBmVHNo7XGknYVdLK46KrcfaFS7OYJKPS/pJ6q AR9mJ/LLSYTqRH1LyMagTEj7fGJKLYaqu+AuRavSG/+sPtZVkknjBMY7iKBIgTu9XTnBqm/IT0d cXGT9tYCbEtPclhZF0fTzLMWE5CmSBCik5/ZoSt1AhvyEKdj4ZiTLIQu4YpJsoi2XrUn/JyeMtM D9QOgDGlDvsLUDW2o6HM5rqDwqttivIExMylat97l/Sk0ESklp2bIxGOtZBB9T3NSP1I6oz4gAM viISeA== Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/NxYGYl7xZRXesyoLNZWjM2YvZB0 Subject: [tsvwg] Progressing foo-over-UDP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 12:56:52 -0000 In London I took an action to write up suggested text for how to handle the concerns of congestion and checksum in UDP-over-foo. I think we had some agreement of what was needed (look at the minutes of TSVWG - or was it TSV Area? - from London). Of course, I have let you all down. I have about 75% of the necessary text for MPLS-over-UDP (as a concrete example), but I am not complete. You don't need to know my excuses. Attached below (so you can laugh at me) is the text I have so far. it is work in progress, but since I am currently getting in the way, some of you might want to take the pen (if no-one wants to, I will try to continue and complete this). Cheers, Adrian ================== x. Applicability and Deployment of MPLS-in-UDP It is helpful to categorise the type of networks in which this solution might be deployed. That is, it is useful to look at the type of network over which the UDP tunnel might run, and the type of network that may be running MPLS. An understanding of these categories will lead to the realization that deploying MPLS-in-UDP in some environments is entirely safe, in other scenarios might cause issues to the networks involved but is a local choice for the operators of those networks, while in other situations the deployment might be significantly harmful to other services or traffic outside the responsibility of the operator deploying MPLS-in-UDP. In broad terms these deployment categories can be listed as follows: - Tunneling across the Internet - Tunneling over a provider network in a customer/provider relationship - Tunneling in a client/server relationship owned by a single operator - Tunneling within a "flat" network The remainder of this section describes the deployment of MPLS-in-UDP in these networks, and gives warnings, advice, and caveats appropriate to those scenarios with special reference to congestion avoidance and the use of checksums. The use made of MPLS-in-UDP by applications must be cognisant of the underlying network deployment. However, it needs to be understood that an end-point application is generally unaware of the services or connectivity over which it is sending data. That is, an end-point application is sending IP data possibly using TCP or UDP, and that data is encapsulated in MPLS somewhere within the network, and then those MPLS packets are themselves encapsulated in UDP as described in this document. That means that the decision points for the concerns and choices described in the sections that follow are at the point of encapsulation of MPLS in UDP, and at the time of deployment of the encapsulation function. While there are possibilities to apply back-pressure to applications, when there is tunneling within tunnels and a significant amount of multiplexing of flows within flows (as is the case with MPLS-in-UDP) these techniques are hard to apply and may have less immediate effect. Implementers are advised to note that widely deployable implementations have to provide the function set that is needed in each of the deployment scenarios discussed below. That is, those implementations that only provide a subset of the functionality are not suitable for deployment in the full set of scenarios. The text in these sections is not intended to be, and should not be taken as, broader guidance for the issues of tunneling different protocols over UDP. x.1. Congestion Considerations End-to-end traffic flows may be multiplexed into MPLS LSPs, and those LSPs may be multiplexed into a single UDP tunnel. These UDP tunnels appear as single flows in the core IP network over which the tunnel flows. Thus, any congestion issues related to the core network and caused by end-to-end traffic flows may be hard to report back to the head ends of the flows causing the congestion. The impact of congestion must be considered both in terms of the effect on the rest of the network of a UDP tunnel that is consuming excessive capacity, and in terms of the effect on the flows using the UDP tunnels in particular if packets are queued (causing delay or jitter) or dropped. Various mechanisms exist to propagate congestion information to the source of flows either when congestion has occurred or when it is perceived to be imminent. It should be noted that in the case of a tunnel (such as a UDP tunnel), the source of a flow is the head end of the tunnel. That is, any congestion notification from the core network will be propagated to the head end of the tunnel, not to the original source of the traffic. The head end of a UDP tunnel can take a number of actions when it is informed about congestion. No comment is made here about which action is best or even appropriate, but section x.3 discusses these actions in the context of the different deployment scenarios. - Do nothing assuming that the burden of congestion will be carried by other flows, or that the fact of congestion on the UDP tunnel will cause back-pressure in the payload flows. - Pass on the congestion information to the payload flows. However, in this instance the payload of the UDP tunnel is MPLS flows, and the mechanisms for congestion notification in MPLS flows are lacking. - Throttle the data being placed onto the UDP tunnel by queuing or dropping packets from the payload flows. - Change the flows that are in a tunnel by putting some of them in a different tunnel. This may have no effect on the congestion, but in some networks with ECMP may result in an improvement. - Completely fail one or more flows carried in the tunnel, or even fail the entire tunnel. This mechanism is sometimes known as "circuit breaker". x.2. UDP Checksum Considerations is checksum an issue what can be done about it - use it or not x.3. Deployment Scenarios x.3.1. MPLS-in-UDP over the Public Internet - Tunneling across the Internet The use of MPLS-in-UDP over the public Internet is NOT RECOMMENDED. x.3.2. MPLS-in-UDP in Managed Networks - Tunneling over a provider network in a customer/provider relationship - Tunneling in a client/server relationship owned by a single operator x.3.3. MPLS-in-UDP in Private Networks - Tunneling in a client/server relationship owned by a single operator - Tunneling within a "flat" network From nobody Tue Jul 22 07:18:26 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508581B28B8 for ; Tue, 22 Jul 2014 07:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 G0i2jztRCFE1 for ; Tue, 22 Jul 2014 07:18:23 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FD771A0AE6 for ; Tue, 22 Jul 2014 07:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2147; q=dns/txt; s=iport; t=1406038703; x=1407248303; h=from:to:cc:subject:date:message-id:mime-version; bh=qs3rod23dv84fxDhHRWz5aGNWtVnU7gEDO2hYrTy2ME=; b=fICHu9u3WsBOBtaNPMj4P/xtFkZl7rCUpw5arD/1/4CufMNlO09HokXJ cfCg5vRU6bhTGzg3lsP78bjT7qSsf3cbCdG5eesTx14mLK1m61qwRnvA0 BQjyWonJ12Fd4Sz5S7GIYegBYm/JAVJJ5RlOUc6IUjdAHnpIePAp4xT45 I=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAHdxzlOtJV2a/2dsb2JhbABYgw6BHw7OWIEPFnaECnkSAYEAJwQOE4g0v0sXjByCWFeDNYEYBY42hAuBRYcgiBqMFYNEgXBB X-IronPort-AV: E=Sophos;i="5.01,710,1400025600"; d="asc'?scan'208";a="341916441" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 22 Jul 2014 14:18:23 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6MEIM2G031101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 22 Jul 2014 14:18:22 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 09:18:22 -0500 From: "Fred Baker (fred)" To: "Cullen Jennings (fluffy)" Thread-Topic: Text from RFC 3246 regarding excess traffic Thread-Index: AQHPpbfKEXB6/TL6jkmmYqe25AwjEA== Date: Tue, 22 Jul 2014 14:18:21 +0000 Message-ID: <08C0D551-C18C-4706-BDB2-F8D9A878F194@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.117.143] Content-Type: multipart/signed; boundary="Apple-Mail=_5243DCE9-31AA-41B9-835E-63B9EB6C434B"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/NWhXgrX1EuvcFHLB2m2SuncuiYs Cc: "tsvwg@ietf.org" Subject: [tsvwg] Text from RFC 3246 regarding excess traffic X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:18:24 -0000 --Apple-Mail=_5243DCE9-31AA-41B9-835E-63B9EB6C434B Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii The EF PHB is intended to be a building block for low loss services. However, under sufficiently high load of EF traffic (including unexpectedly large bursts from many inputs at once), any device with finite buffers may need to discard packets. Thus, it must be possible to establish whether a device conforms to the EF definition even when some packets are lost. This is done by performing an "off-line" test of conformance to equations 1 through 4. After observing a sequence of packets entering and leaving the node, the packets which did not leave are assumed lost and are notionally removed from the input stream. The remaining packets now constitute the arrival stream (the a_j's) and the packets which left the node constitute the departure stream (the d_j's). Conformance to the equations can thus be verified by considering only those packets that successfully passed through the node. If the EF PHB is implemented by a mechanism that allows unlimited preemption of other traffic (e.g., a priority queue), the implementation MUST include some means to limit the damage EF traffic could inflict on other traffic (e.g., a token bucket rate limiter). Traffic that exceeds this limit MUST be discarded. This maximum EF rate, and burst size if appropriate, MUST be settable by a network administrator (using whatever mechanism the node supports for non- volatile configuration). --Apple-Mail=_5243DCE9-31AA-41B9-835E-63B9EB6C434B 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 iD8DBQFTznKObjEdbHIsm0MRAnvKAKCmScgNEZ91mIr00R5NZsQbho83FwCfcSsv wQcGA4NI1CFLeMfcGXpZLlY= =Xn/x -----END PGP SIGNATURE----- --Apple-Mail=_5243DCE9-31AA-41B9-835E-63B9EB6C434B-- From nobody Tue Jul 22 07:21:38 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8338F1B28D8 for ; Tue, 22 Jul 2014 07:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=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 JhmqVkUsBbr3 for ; Tue, 22 Jul 2014 07:21:32 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49B281B28D6 for ; Tue, 22 Jul 2014 07:21:32 -0700 (PDT) Received: from dhcp-a0db.meeting.ietf.org (dhcp-a0db.meeting.ietf.org [31.133.160.219]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id B807A1C0ACEB4 for ; Tue, 22 Jul 2014 16:21:29 +0200 (CEST) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <31B1D778-3B81-4E2F-BDAA-64B96CE71B87@lurchi.franken.de> Date: Tue, 22 Jul 2014 10:21:27 -0400 To: tsvwg WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/6WxMEX5egQ1wrqxqqKPuHuA-pQM Subject: [tsvwg] Name of the new DATA chunk X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:21:36 -0000 Dear all, it was suggested to use I-DATA chunk for Interleaving DATA chunk as a better name for the chunk defined in http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-01 Any opinons? Best regards Michael From nobody Tue Jul 22 08:10:36 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07CC51B28AF; Tue, 22 Jul 2014 08:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 qNOO5jy94ib7; Tue, 22 Jul 2014 08:09:59 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83331B28A8; Tue, 22 Jul 2014 08:09:56 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so602810wiv.15 for ; Tue, 22 Jul 2014 08:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=jiEnkMnrnmf4casJAdKEiE8+NecAIBfiZ454GBQsZ4M=; b=1ERtgvmw8e/pjc2Bg1xRH9zVhyiP3kovh2eecs+MdGA17mjD7QNUvOpTYBHadsHRhV dp0CDxRMAYiGckiVQt758FiBiYZ9j+W5IsCHbRjhEH/lMZnLDIXtbtQ3+eR5rFsCCTT1 yA9DJG29T3qZg+8WXlbu9ZnFgsqOTGfyYBVtpf0a705+Sars0zoHiTJuKKtYQ53QDSOH ZV41FxX9LFAlA04d+rgMSqitFcU78xOUgvp3MYih4QI6LDqj6jzKJzPB9GNWO6V8W9WB onKRBIy6lveF83odfgUI08UzWVV+fjRN+8WlUACZlkraT6LQPXnl8OxoMsuvN3XBZpGn SpQw== X-Received: by 10.194.179.4 with SMTP id dc4mr34576562wjc.32.1406041794416; Tue, 22 Jul 2014 08:09:54 -0700 (PDT) Received: from ?IPv6:2001:67c:370:168:7d81:63d9:9d6:709b? ([2001:67c:370:168:7d81:63d9:9d6:709b]) by mx.google.com with ESMTPSA id ez1sm3618300wib.15.2014.07.22.08.09.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 08:09:53 -0700 (PDT) Message-ID: <53CE7EBD.6080201@gmail.com> Date: Tue, 22 Jul 2014 11:09:49 -0400 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, mpls@ietf.org, tsvwg@ietf.org References: <0a5301cfa5ac$6825a810$3870f830$@olddog.co.uk> In-Reply-To: <0a5301cfa5ac$6825a810$3870f830$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/V-0MgJ6rYz3WnmhzkYkXhI_gWwA Subject: Re: [tsvwg] Progressing foo-over-UDP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 15:10:17 -0000 On 07/22/2014 08:56 AM, Adrian Farrel wrote: > In London I took an action to write up suggested text for how to handle the > concerns of congestion and checksum in UDP-over-foo. > > I think we had some agreement of what was needed (look at the minutes of TSVWG - > or was it TSV Area? - from London). > > Of course, I have let you all down. I have about 75% of the necessary text for > MPLS-over-UDP (as a concrete example), but I am not complete. You don't need to > know my excuses. > > Attached below (so you can laugh at me) is the text I have so far. it is work in > progress, but since I am currently getting in the way, some of you might want to > take the pen (if no-one wants to, I will try to continue and complete this). Adrian, thank you for sending this. It's important (as we gather what seems to be an inexhaustible supply of foos to encapsulate with UDP), and David and Gorry were able to point to your e-mail during TSVWG this morning. Spencer > Cheers, > Adrian > > ================== > > x. Applicability and Deployment of MPLS-in-UDP > > It is helpful to categorise the type of networks in which this > solution might be deployed. That is, it is useful to look at the > type of network over which the UDP tunnel might run, and the type of > network that may be running MPLS. An understanding of these > categories will lead to the realization that deploying MPLS-in-UDP in > some environments is entirely safe, in other scenarios might cause > issues to the networks involved but is a local choice for the > operators of those networks, while in other situations the deployment > might be significantly harmful to other services or traffic outside > the responsibility of the operator deploying MPLS-in-UDP. > > In broad terms these deployment categories can be listed as follows: > > - Tunneling across the Internet > - Tunneling over a provider network in a customer/provider > relationship > - Tunneling in a client/server relationship owned by a single > operator > - Tunneling within a "flat" network > > The remainder of this section describes the deployment of MPLS-in-UDP > in these networks, and gives warnings, advice, and caveats > appropriate to those scenarios with special reference to congestion > avoidance and the use of checksums. The use made of MPLS-in-UDP by > applications must be cognisant of the underlying network deployment. > However, it needs to be understood that an end-point application is > generally unaware of the services or connectivity over which it is > sending data. That is, an end-point application is sending IP data > possibly using TCP or UDP, and that data is encapsulated in MPLS > somewhere within the network, and then those MPLS packets are > themselves encapsulated in UDP as described in this document. That > means that the decision points for the concerns and choices described > in the sections that follow are at the point of encapsulation of MPLS > in UDP, and at the time of deployment of the encapsulation function. > While there are possibilities to apply back-pressure to applications, > when there is tunneling within tunnels and a significant amount of > multiplexing of flows within flows (as is the case with MPLS-in-UDP) > these techniques are hard to apply and may have less immediate > effect. > > Implementers are advised to note that widely deployable > implementations have to provide the function set that is needed in > each of the deployment scenarios discussed below. That is, those > implementations that only provide a subset of the functionality are > not suitable for deployment in the full set of scenarios. > > The text in these sections is not intended to be, and should not be > taken as, broader guidance for the issues of tunneling different > protocols over UDP. > > x.1. Congestion Considerations > > End-to-end traffic flows may be multiplexed into MPLS LSPs, and those > LSPs may be multiplexed into a single UDP tunnel. These UDP tunnels > appear as single flows in the core IP network over which the tunnel > flows. Thus, any congestion issues related to the core network and > caused by end-to-end traffic flows may be hard to report back to the > head ends of the flows causing the congestion. > > The impact of congestion must be considered both in terms of the > effect on the rest of the network of a UDP tunnel that is consuming > excessive capacity, and in terms of the effect on the flows using the > UDP tunnels in particular if packets are queued (causing delay or > jitter) or dropped. > > Various mechanisms exist to propagate congestion information to the > source of flows either when congestion has occurred or when it is > perceived to be imminent. It should be noted that in the case of a > tunnel (such as a UDP tunnel), the source of a flow is the head end > of the tunnel. That is, any congestion notification from the core > network will be propagated to the head end of the tunnel, not to the > original source of the traffic. > > The head end of a UDP tunnel can take a number of actions when it is > informed about congestion. No comment is made here about which > action is best or even appropriate, but section x.3 discusses these > actions in the context of the different deployment scenarios. > > - Do nothing assuming that the burden of congestion will be carried > by other flows, or that the fact of congestion on the UDP tunnel > will cause back-pressure in the payload flows. > > - Pass on the congestion information to the payload flows. However, > in this instance the payload of the UDP tunnel is MPLS flows, and > the mechanisms for congestion notification in MPLS flows are > lacking. > > - Throttle the data being placed onto the UDP tunnel by queuing or > dropping packets from the payload flows. > > - Change the flows that are in a tunnel by putting some of them in a > different tunnel. This may have no effect on the congestion, but > in some networks with ECMP may result in an improvement. > > - Completely fail one or more flows carried in the tunnel, or even > fail the entire tunnel. This mechanism is sometimes known as > "circuit breaker". > > x.2. UDP Checksum Considerations > > is checksum an issue > what can be done about it > > - use it or not > > x.3. Deployment Scenarios > > x.3.1. MPLS-in-UDP over the Public Internet > > > - Tunneling across the Internet > The use of MPLS-in-UDP over the public Internet is NOT RECOMMENDED. > > x.3.2. MPLS-in-UDP in Managed Networks > > - Tunneling over a provider network in a customer/provider > relationship > - Tunneling in a client/server relationship owned by a single > operator > > x.3.3. MPLS-in-UDP in Private Networks > > - Tunneling in a client/server relationship owned by a single > operator > - Tunneling within a "flat" network > From nobody Mon Jul 28 05:38:10 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DCA1A0174 for ; Mon, 28 Jul 2014 05:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 VKob2eOm_Num for ; Mon, 28 Jul 2014 05:38:06 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id C64A81A0164 for ; Mon, 28 Jul 2014 05:38:05 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id B027E2B41E7 for ; Mon, 28 Jul 2014 13:38:02 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Mon, 28 Jul 2014 13:38:02 +0100 Message-ID: Date: Mon, 28 Jul 2014 13:38:02 +0100 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/mX644Pfr_8DTtilghRo6c63canA Subject: [tsvwg] Draft notes from Toronto meeting X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 12:38:09 -0000 Please review the draft notes and send any comments/corrections, they are available at: http://www.ietf.org/proceedings/90/minutes/minutes-90-tsvwg Gorry