From gorry@erg.abdn.ac.uk Mon Jul 1 00:00:30 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5205421F9CC6 for ; Mon, 1 Jul 2013 00:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cm87R1Td1-Eh for ; Mon, 1 Jul 2013 00:00:23 -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 B107E21F8FAF for ; Mon, 1 Jul 2013 00:00:23 -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 D5A182B44BA; Mon, 1 Jul 2013 08:00:19 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Mon, 1 Jul 2013 08:00:20 +0100 Message-ID: In-Reply-To: <20130628180923.GF6068@verdi> References: <51C1CD63.7070106@erg.abdn.ac.uk> <20130628180923.GF6068@verdi> Date: Mon, 1 Jul 2013 08:00:20 +0100 From: gorry@erg.abdn.ac.uk To: "John Leslie" 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 Cc: Gorry Fairhurst , tsvwg chair , tsvwg WG Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 07:00:30 -0000 > Gorry Fairhurst wrote: >> >> This email announces the beginning of a short working group last call >> for draft-ietf-tsvwg-byte-pkt-congest-10, "Byte and Packet Congestion >> Notification". This document is now thought by the authors to be ready >> to proceed to be published as a Proposed Standard... > > Alas, we do need clarity about the intended status. > Sorry BCP. > I cannot see how this draft would qualify for Proposed Standard; so > I will not discuss that further unless someone confirms that that indeed > is the status that will be proposed. > > The document itself claims Intended status: BCP. > This is correct. > IMHO, we have been overtaken by events over the last six years; and > to publish a BCP on this topic today would require considerable review > and discussion. I am willing to participate in such review; but I am > doubtful we will see quick progress with the current authors. :^( > > I suggest instead publishing pretty much as-is with intended status: > Informational. Surely the effort which has gone into it so far justifies > a WG Informational RFC. (I'd be happiest with an added note of the > expected work in AQM; but I certainly won't insist on that.) > > I do encourage everyone interested in this to attend the AQM BoF at > 1700 on Tuesday, July 30th. > > (As a brief suggestion of issues deserving our work to publish this > as a BCP today, I'll mention: > - whether we are attempting to estimate time-on-the-wire when we count > bytes and/or packets; > - what AQM has come to mean over the last few years; and > - how byte and/or packet counting will interact with time-in-queue AQM.) > > -- > John Leslie > I'll send an email closing the WGLC and listing the people who participated. Gorry From weixinpeng@huawei.com Wed Jul 3 18:30:47 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B982C11E810B for ; Wed, 3 Jul 2013 18:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzfiWbk2Mh9L for ; Wed, 3 Jul 2013 18:30:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6853611E80F3 for ; Wed, 3 Jul 2013 18:30:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATC45798; Thu, 04 Jul 2013 01:30:30 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 4 Jul 2013 02:30:27 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 4 Jul 2013 02:30:28 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.117]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Thu, 4 Jul 2013 09:30:18 +0800 From: Weixinpeng To: "tsvwg@ietf.org" Thread-Topic: A new draft on tunnel congestion information feedback mechanism. Thread-Index: Ac54Vgjdf28hJXfBSJSXu8OXWXH9WQ== Date: Thu, 4 Jul 2013 01:30:16 +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.77.68] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B43CA34426nkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "gorry@erg.abdn.ac.uk" Subject: [tsvwg] A new draft on tunnel congestion information feedback mechanism. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 01:30:47 -0000 --_000_C5C3BB522B1DDF478AA09545169155B43CA34426nkgeml507mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, A new draft on tunnel congestion information feedback mechanism ha= s been submitted. Best Regards Xinpeng. 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. URL: http://www.ietf.org/internet-drafts/draft-wei-tsvwg-tunnel= -congestion-feedback-00.txt Status: http://datatracker.ietf.org/doc/draft-wei-tsvwg-tunnel-con= gestion-feedback Htmlized: http://tools.ietf.org/html/draft-wei-tsvwg-tunnel-congesti= on-feedback-00 --_000_C5C3BB522B1DDF478AA09545169155B43CA34426nkgeml507mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

     &= nbsp;   A new draft on tunnel congestion information feedback mec= hanism has been submitted.

 

Best Regards<= /p>

Xinpeng.

 

 

 

 

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.

 

 

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

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

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

 

--_000_C5C3BB522B1DDF478AA09545169155B43CA34426nkgeml507mbxchi_-- From gorry@erg.abdn.ac.uk Thu Jul 4 06:28:51 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7691911E80D1 for ; Thu, 4 Jul 2013 06:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQoK8jLmFOtX for ; Thu, 4 Jul 2013 06:28:45 -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 4030E21F9E4B for ; Thu, 4 Jul 2013 06:28:40 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 8A37D2B44B1; Thu, 4 Jul 2013 14:28:38 +0100 (BST) Received: from Gorry.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 3F9EF2B439A for ; Thu, 4 Jul 2013 14:28:37 +0100 (BST) Message-ID: <51D57884.7020207@erg.abdn.ac.uk> Date: Thu, 04 Jul 2013 14:28:36 +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:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tsvwg] Agenda requests for TSVWG in Berlin X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2013 13:28:51 -0000 Hi all, If you still would like to present at the planned TSVWG meeting in Berlin, please let the chairs know asap: * Presentation title / draft * Presenter * Presentation time - Last meeting we saw a large number of drafts, so this time we plan to focus must time on drafts that have seen recent discussion on the list (hint: If it has not been discussed on the list, then it probably isn't ready for tsvwg) and those drafts that have changed significantly since the last meeting. - Time for WG drafts will be allocated in precedence of other presentations. Best wishes, Gorry, James, and David ++++ Here is my list of current requests received - in no particular order and **NO** decision yet: Agenda Requests (Berlin) Working Group Documents: Byte and Packet Congestion Notification draft-ietf-tsvwg-byte-pkt-congest Individual Documents: (Ruediger.Geib@telekom.de) DiffServ interconnection classes draft-geib-tsvwg-diffserv-intercon G. Shepherd Multicast UDP Usage Guidelines for Application Designers draft-shepherd-multicast-udp-guidelines-01 Subha Dhesikan DSCP and other packet markings for RTCWeb QoS draft-dhesikan-tsvwg-rtcweb-qos-01 New work: () Tunnel Congestion Feedback draft-wei-tsvwg-tunnel-congestion-feedback-00 draft-iyengar-minion-concept-00 draft-iyengar-minion-protocol-00 draft-zmafir-tsvwg-flow-metadata-rsvp-00 (No Draft) draft-choukir-tsv-flow-metadata-encoding-00 (No Draft) MiniStack, a minimalistic operating system stack (No Draft) Notes on other matters: New AD announcement draft-bonica-6man-frag-deprecate-00 -- no presentation requested. From Karen.Nielsen@tieto.com Thu Jul 4 08:39:03 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2251E21F9FD5 for ; Thu, 4 Jul 2013 08:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7HJ-VTSWm81 for ; Thu, 4 Jul 2013 08:38:58 -0700 (PDT) Received: from ebb06.tieto.com (ebb06.tieto.com [131.207.168.38]) by ietfa.amsl.com (Postfix) with ESMTP id 979B221F9FF3 for ; Thu, 4 Jul 2013 08:38:55 -0700 (PDT) X-AuditID: 83cfa826-b7fc96d000004032-dd-51d5970bbbd8 Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb06.tieto.com (SMTP Mailer) with SMTP id D7.86.16434.B0795D15; Thu, 4 Jul 2013 18:38:51 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.10]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Thu, 4 Jul 2013 18:38:51 +0300 From: To: , Date: Thu, 4 Jul 2013 18:38:49 +0300 Thread-Topic: draft-ietf-tsvwg-sctp-failover: comments and suggestions Thread-Index: Ac5svfYLAadF7kBnQImSRAK4lD10OAL18SIQAAAI0gA= Message-ID: References: <51A360E7.7020209@ericsson.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCKsWRmVeSWpSXmKPExsXSfL5DS5d7+tVAg6UXbSw+vN3HbLFxyQ02 i7t/tzFbHHtzl82BxePX16tsHkuW/GTyuPj6OrPHl8uf2QJYorhsUlJzMstSi/TtErgyWlb1 MxUcja5Y/k6jgfGCZxcjJ4eEgInEzYk/mCFsMYkL99azdTFycQgJrGKUWPL1CyuEM4lR4sfa 30wgVWwC8hJz965iB7FFBGwl1i+ZB9bNLOAqsevZJJYuRg4OFgEViX8PWEDCwkDh7w+msUGU u0m8XTUZyraS2N49hxHE5hXwkfj3qx3MFhLYyijx5kkAiM0p4Cux7NE3sDmMQMd9P7WGCWKV uMStJ/OZII4WkFiy5zzUA6ISLx//Y4WoF5W4076eEaJeT+LG1ClsELa2xLKFr5kh9gpKnJz5 hGUCo9gsJGNnIWmZhaRlFpKWBYwsqxj5U5OSDMz0SjJTS/L1kvNzNzGCI2uF2g7GZw+kDjEK cDAq8fBaNl0NFGJNLCuuzD3EKMnBpCTKyzcNKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE91Qz UI43JbGyKrUoHyYlzcGiJM6bqHwlUEggPbEkNTs1tSC1CCYrw8GhJMH7bSpQo2BRanpqRVpm TglCmomDE2Q4D9BweZDFvMUFibnFmekQ+VOMilLivL9AmgVAEhmleXC9sMT3ilEc6BVhXjmQ dh5g0oTrfgU0mAlo8F/2KyCDSxIRUlINjOwvp7u4rDknW9S0JNhvlnRjufx896C/y6/LPyrq 5ZvPbMDnPplDWUPUpOuSRMzKDy4TDdrUNx6+s+aQx97nK1qmliR1aGoy1AZNvaVwqVUjasYn 1g/rX7z7fezD3xlqB75aq9QY72mRtvfzurzja1AZQ3DTym1zV/7ztoiwO7Mw+tnN1hitaiWW 4oxEQy3mouJEAASccQlXAwAA Cc: tsvwg@ietf.org, draft-ietf-tsvwg-sctp-failover@tools.ietf.org Subject: Re: [tsvwg] draft-ietf-tsvwg-sctp-failover: comments and suggestions X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 15:39:03 -0000 Hi All, Please find some additional comments inline below. > >- Section 5.1: CWND Handling for Potentially Failed Destinations > > >I agree with you to stick to the behavior of RFC4960 as default behavior. = We've >been exploring several possibilities for performance improvement and discu= ssing >using 2 MTU might be an idea, although we think we'll need further discuss= ions. >Preethi might have some more comments on this point. > Please accept the following addition comments: The motivation for the 2MTU, I now understand, is to aim to mitigate unwant= ed effects of=20 path bouncing resulting from a spurious T3-timeout followed by failover=20 and subsequent "immediate" switchback operation of RFC4960 once HB ACK is acknowledged within the back-off'ed RTO.=20 While I think that one can very well say in this document that the CWND cou= ld be set to 2MTU=20 in case the first HB sent on a PF path is successfully ack'ed, then I would= like to note that=20 this then is motivated by a desire, first and foremost, to be backward comp= atible with RC4960, more than it really necessarily addresses how to best mitigate throughput degradation ef= fects of spurious T3-timeouts. Indeed for implementations that operate with different switchback modes tha= n the immediate switchback operation of RFC4960, (e.g. operate with certain permanent failover modes), then the set of the = CWND to 2 MTU on the previous PF path=20 is not of a big significance as it can be most optimal, from a performance = perspective, to stay on the new data carrying path, which at this point in time may have= a CWND of IW, IW+1MTU or even higher. I think that the motivation for setting the CWND to 2MTU possibly should be= made conditionally on whether the SCTP indeed follows the immediate switchback operation of RFC4960. One further observation is that in a situation where it is only the 2dn or = the 3rd (or 4th..) of the HBs sent on the PF path, that is successful, then= =20 setting the CWND to 2 MTU may actually constitute a decrease of the CWND. T= his is the case if the implementation=20 follows RC4960 and raise the CWND to IW (4MTU) after an idle period of one = RTO following the T3 timeout. When in the text it is said that the CWND should be set to 1MTU at the stat= e transition from PF to ACTIVE does this then very explicitly addresses the fact that unsuccessful HBs, sent on a PF path, shall keep the= CWND down at 1MTU as otherwise data failures would ? If so then I think that it could be good to add this clarification. Final thoughts: We have in real deployment experienced fault situations where HBs consisten= tly were able to get through on the primary path,=20 but where the path broke due to congestion once it got loaded with data. Th= ere are different ways in which one can improve the protocol operation to best tackle such a situation. Our present solution, w= hich is to deploy a permanent failover mode together with PF and looking for a way to add reliability to the T3 timeouts, may not be the= ultimate way to solve this, but I would like to note that=20 in such a situation then consistently returning to the primary path and set= ting CWND =3D 2MTU is not the right thing to do. >- Section 5.3: Permanent Failover > >We have good experiences from live networks with running SCTP in a "no >switchback" mode of operation with no automatic migration back to a prefer= red >primary path. Once the primary path is left due to it being potentially fa= iled, then a >selected alternative path automatically becomes the new primary path. > >This mode of operation corresponds to a simplified variant of the permanen= t >failover operation proposed in [CAR002] with alpha =3D beta =3D >SCTP_PEER_ADDR:THLDS. The mode of operation is run with notifications of >change of primary path being provided to upper layers via RFC6458 >SCTP_PEER_ADDR_CHANGE semantics (SCTP_ADDR_MADE_PRIM). > >The mode of operation does not suit all purposes, but in networks environm= ents >where a number of equally preferred paths are available, then by this mode= of >operation one minimizes the effects of unnecessary path bouncing and the t= hereby >associated effects of throughput degradation due to path changes and slow = start >operation. > >Based on our experiences we would recommend and support that the Permanent >Failover mode of operation, at least in the simple variant described above= , is >promoted as a valid alternative approach. For the purpose of activation of= this >mode of operation a switchback (or failover) mode operation parameter coul= d be >introduced as configurable by the introduction of an appropriate new read/= write >socket option in the Socket API. > > >Yes. I agree that there will be a situation where Permanent Failover work = effectively. >OTOH, supporting this=A0prevents us from keeping RFC4960 behavior as RFC49= 60 >doesn't have this mode. >But, I believe this is a very interesting point and we would like to get m= ore feedback >in order to think about this more. > I understand to continue to support RFC4960 behaviour, but I suppose that o= ne can add to RFC4960 behaviour :-) We have the simple "no switchback mode" described above runni= ng in deployment. >- Section 5.4: The impact of HB timeouts in association error counter > >The draft recommends for excluding HB timeouts from contributing to the >(association) error counter. We fully support this approach for all timeou= ts of HBs >that are send to probe the state of destinations addresses that are in PF = state and >we would even propose for the draft to demand that generally timeouts stem= ming >from HBs, which are not sent on the Primary Path, will be excluded from th= e >association error counter. > >Thereby the association error counter and thus the association fate reflec= ts the >forward progress of the data transmission to peer endpoint while at the sa= me time it >will be appropriately isolated from timeouts of HBs sent on non-data carry= ing paths. > >Allowing timeout of HBs sent on the Primary Path to impact the association= error >counter will serve to validate the aliveness of the peer endpoint when the= re is no >data in transit. > >This suggestion follows the thought expressed in http://www.ietf.org/mail- >archive/web/tsvwg/current/msg11294.html and it is thus believed to fulfil = the original >intend of RFC4960. > >This is a bit difficult point for me. I don't know much about the original= intention of >RFC4960, but if we follow what is written there, i think we need to increm= ent >association error count. (Please correct me if I misunderstand this point)= So, my >personal preference is to set bigger AMR to avoid early termination so tha= t we can >keep the RFC4960 behavior. >However, we don't mind discussing to update the logic described in 4960 fo= r more >sophisticated solution. > Thanks ! Yes, I concur that the text of section 8.1 of RFC4960 stipulates that all H= B Acks and HB timeouts=20 influence the association error counter. But from the referenced discussion= thread, http://www.ietf.org/mail-archive/web/tsvwg/current/msg11294.html (simply = copying it in here to avoid repeating the arguments)=20 it also seems that by purpose no keywords were used when writing these par= agraphs.=20 Further as the Potentially Feature was not defined at the time, I am not su= re that it would be valid to say that the text of RFC4960 apply (at least) to the H= Bs sent as part of this function. >From our perspective what we would like to support and see happening is=20 that all HBs, whether sent as part of the PF function or not, influence the= association error counter=20 if and only if they are transmitted on the Primary Path (and then with stan= dard logic running making sure that all data transmissions=20 prevent (or cancel in race conditions) any influence from HBs). Thereby the association error counter will be influenced by (and will thus = reflect) the data transmission only. Except in idle situation where HBs on Primary Path will serve to update the= association error counter in a similar manner as data would. Thereby one get a very clean and reliable implementation of the association= error counter. By reliable, I mean that one can use the same AMR value regardless of the level of HB probing that one have acti= vated and regardless of whether the Potentially Failed feature is activated= or not. Such an implementation also makes the AMR value be independent from the num= ber of paths supported in the association context.=20 One can choose to use a value of AMR proportional with the number of paths = in order to have all paths be tried a number of times before association cl= osure, but with the choice suggested, one is not forced to "artificially" raise the AM= R value to make room for the HBs that will fire as part of the potentially = failed feature as well as for some fraction of the Path Monitoring HBs that can happen to fire dur= ing the same timeframe. An additional thought is that in the odd cases where HBs get through wherea= s data do not, then I think that it is contra-productive to have the associ= ation error counter be reset as long as data consistently fail.=20 I, personally, does not so much like the suggestion to use a "maximal" or "= bigger" AMR. I think that it will be complex to deduce exactly what failure time (aka number of data retransmission) that a certain AMR v= alue will guarantee you,=20 whereas when only data transmission influences the AMR, things will be clea= n, simple and predictable. I would be very happy if we by this communication could solicit information= from others. > >- Section 5.1 Thoughts on the destination address state machine > >In RFC4960 address state machine, notification of cease of use of the curr= ent >primary path as transmission path for new data is provided to upper layer = via >(coupled with) the announcement of the destination as being UNREACHABLE. W= ith >the introduction of the potentially failed state as a semi-hidden state (n= ot resulting in >notified state transition to UL) the information on the fail-over to use a= new data >carrying path is lost. >While there may be merits in suppressing notifications on potentially fail= ed >addresses, then we believe that it is unfortunate that the notification of= failover from >usage of the primary path for new data is lost. >This is especially problematic in path bouncing scenarios where the primar= y path is >unstable but still works some. E.g., HBs may go through, but the path brea= ks (data >transmission fails) as soon as it is more loaded. In such a situation no n= otifications >may be generated to UL, even if new data transmission consistently cycles = to and >from the primary path. The solution to such path bouncing scenarios will h= ave to >come from more advanced path failover mechanism, like [CAR002] (and would = not >be solved just by notification), but it would be a great help if appropria= te >notifications were provided. > >I think it will be OK to send notification as long as it's a new notificat= ion type. But >we should not send notifications defined in RFC6458. ok - I assume this is for backward compatible reasons.=20 >I guess having a new notification type won't cause problems, but I would l= ike to get >more feedback on this. Ok - we can come back with a suggestion. Thanks a lot ! BR, Karen > >Thanks! >-- >Yoshifumi From gjshep@gmail.com Fri Jul 5 17:49:20 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052D621F8F24 for ; Fri, 5 Jul 2013 17:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06P1V4H--0wX for ; Fri, 5 Jul 2013 17:49:19 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0A221F8F0C for ; Fri, 5 Jul 2013 17:49:19 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id z11so2341983wgg.34 for ; Fri, 05 Jul 2013 17:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=JdSQD33g4DWwJ5jxTq3NV/Imqbd4UbePRTdVAAKqju4=; b=X1+gw0JclGZgeplkS8Nj44/RblA+B4yVzQkbguQ9Gf9JB9NdSPwGNmKFmJVhRf2Vka y5ZdDmtMhtlx0cLD5ds+fkeJfCkDWhLOWxgCC/h9IRu75qB2g3CgwGinpLhe84yVtYKh sox5uAmPTDAd0tKFlrb6fm+BBYYbO7KC+6BOG6CyMbhO7VGh1Ptu5F6cIr00EIrl0Puq r2xMonxHUNTrYaxsGeAQFTzK9PT/1s8HOqTSv1/mttR8BSMm8B7/qhcozvHmDrYyle7D 6GioYZ3tUEHZYM6WDKqfzbyt5U6rIpy6S9DDQaTjYuBcxeOBs3k86o2qNecYYzQ9qznV Wu4Q== MIME-Version: 1.0 X-Received: by 10.194.123.199 with SMTP id mc7mr7265686wjb.35.1373071758418; Fri, 05 Jul 2013 17:49:18 -0700 (PDT) Received: by 10.180.185.36 with HTTP; Fri, 5 Jul 2013 17:49:18 -0700 (PDT) In-Reply-To: <20130612173053.17598.30587.idtracker@ietfa.amsl.com> References: <20130612173053.17598.30587.idtracker@ietfa.amsl.com> Date: Fri, 5 Jul 2013 17:49:18 -0700 Message-ID: From: Greg Shepherd To: "" , Magnus Westerlund Content-Type: multipart/alternative; boundary=089e012279ac696a1a04e0cd2e2e Subject: [tsvwg] Fwd: Confirmation for Auto-Post of I-D draft-shepherd-multicast-udp-guidelines X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gjshep@gmail.com List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 00:49:20 -0000 --089e012279ac696a1a04e0cd2e2e Content-Type: text/plain; charset=ISO-8859-1 Can I have an agenda slot in Berlin to discuss draft-shepherd-multicast-udp-guidelines? Thanks, Greg ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Wed, Jun 12, 2013 at 10:30 AM Subject: Confirmation for Auto-Post of I-D draft-shepherd-multicast-udp-guidelines To: Greg Shepherd Hi, The IETF datatracker draft submission service has received your draft draft-shepherd-multicast-udp-guidelines-01, and requires a confirmation step in order to be able to complete the posting of the draft. Please follow this link to the page where you can confirm the posting: Confirmation URL: http://datatracker.ietf.org/submit/status/51145/confirm/1b4e70f5499fef25c2d9d6c7990b8e06df9c81b8/ Best regards, The IETF Secretariat through the draft submission service --089e012279ac696a1a04e0cd2e2e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Can I have an agenda slot in Berlin to discuss draft-sheph= erd-multicast-udp-guidelines?

Thanks,
--089e012279ac696a1a04e0cd2e2e-- From gorry@erg.abdn.ac.uk Sun Jul 7 08:29:03 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7EA21F9F8F for ; Sun, 7 Jul 2013 08:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.561 X-Spam-Level: X-Spam-Status: No, score=-105.561 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXVb6SfS0YAj for ; Sun, 7 Jul 2013 08:28:57 -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 5B48C21F9D62 for ; Sun, 7 Jul 2013 08:28:57 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 894122B44CA; Sun, 7 Jul 2013 16:28:56 +0100 (BST) Received: from Gorry.local (fgrpf.plus.com [212.159.18.54]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id A3B4B2B4098 for ; Sun, 7 Jul 2013 16:28:55 +0100 (BST) Message-ID: <51D98936.5050601@erg.abdn.ac.uk> Date: Sun, 07 Jul 2013 16:28:54 +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:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tsvwg] Result of the recent WGLC for draft-ietf-tsvwg-byte-pkt-congest-10. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 07 Jul 2013 15:29:03 -0000 This email summarises the results of the WGLC for draft-ietf-tsvwg-byte-pkt-congest-10. This document had been approved by the IESG for publication as an RFC, butthe just-concluded WGLC revealed that updates to the document are still potentially needed. The document is therefore returned to the WG work on these changes. The resulting ID will requirereview in a short WGLCto confirm the final document, followed by an IETF last call by the community at large. We hope a new revision will be available shortly. Best wishes, Gorry (as document shepherd) From madanmohanm@huawei.com Sun Jul 7 23:00:06 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237BF11E818C for ; Sun, 7 Jul 2013 23:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.836 X-Spam-Level: X-Spam-Status: No, score=-4.836 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTL7FIEZsUDb for ; Sun, 7 Jul 2013 23:00:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B9F1011E8111 for ; Sun, 7 Jul 2013 22:59:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATF38775; Mon, 08 Jul 2013 05:59:56 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 8 Jul 2013 06:59:40 +0100 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 8 Jul 2013 06:59:52 +0100 Received: from SZXEML537-MBX.china.huawei.com ([169.254.1.17]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.007; Mon, 8 Jul 2013 13:59:43 +0800 From: Madan Mohan Mishra To: "tsvwg@ietf.org" Thread-Index: Ac57nUzZSiXmaUvYR7WcRwnMJIJMrw== Date: Mon, 8 Jul 2013 05:59:42 +0000 Message-ID: <2F3BA9016646EE43862F506BAC2D49A92CE484C8@szxeml537-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.96.96] Content-Type: multipart/alternative; boundary="_000_2F3BA9016646EE43862F506BAC2D49A92CE484C8szxeml537mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Nagesh shamnur , Rajith Raveendranath Subject: [tsvwg] (no subject) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 06:00:06 -0000 --_000_2F3BA9016646EE43862F506BAC2D49A92CE484C8szxeml537mbxchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Group, I have a doubt in one of the scenario related to restart duing shutdown= which is not very clear to my understanding as per the RFC4960. The scenar= io is as below: Clause as per the RFC: ---------------------------------------------------------------------------= ---------- 9.2. Shutdown of an Association "If an endpoint is in the SHUTDOWN-ACK-SENT state and receives an INIT chunk (e.g., if the SHUTDOWN COMPLETE was lost) with source and destination transport addresses (either in the IP addresses or in the INIT chunk) that belong to this association, it should discard the INIT chunk and retransmit the SHUTDOWN ACK chunk." ---------------------------------------------------------------------------= ---------- Network scenario as per the above RFC snippet: SCTP-A S= CTP-B Local IP List: L-IP1, L-IP2 Loc= al IP List: R-IP1, R-IP2 ESTABLISHED ESTA= BLISHED ---------------------------SHUT-DOWN (L-IP1->R-IP1)--------------------> <-------------------------SHUT-DOWN-ACK (R-IP1<- L-IP1)-------------- ---------------------------SHUT-DOWN-COMP (L-IP1->R-IP1)-----lost in networ= k Now, local end point rebooted It might create a new association as below: local IP addresses. Local IP List: L-IP2, L-IP3 ----------------------------INIT (L-IP2->R-IP1)----------------------------= ----> = SHUT-DOWN-ACK sent state = As per RFC, upon receiving INIT message = in SHUT-DOWN-ACK-SENT state, it should = retransmit SHUT-DOWN-ACK and discard INIT message. <-----------SHUT-DOWN-ACK (L-IP1<-R-IP1)------------------- This mesage wil= be discarded at L-IP1, since there will be = no association in L-IP1 The destination IP address of last SHUT-DOWN-ACK message is no more exist. = So , all the SHUT-DOWN-ACK messages sent by SCTP-B will be discarded in network. RFC4960 does not mention explicitly to handle this kind of situation? As, retransmission of SHUT-DOWN-ACK message is not due to T2 timer expiry, = path switching is not applicable. So, SHUT-DOWN-ACK message will always be sent on the pri= mary address. So, I believe, SCTP-B should send SHUT-DOWN-ACK message to the same destina= tion address which is exist in both INIT and current association destination address lis= t so that the message will not be discarded. Please share your opinion. Thanks and Regards, Madan --_000_2F3BA9016646EE43862F506BAC2D49A92CE484C8szxeml537mbxchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Group,

    I have a doubt in one of the scenario related to= restart duing shutdown which is not very clear to my understanding as per = the RFC4960. The scenario is as below:

 

Clause as per the RFC:

------------------------------------------------------------------------= -------------

9.2.  Shutdown of an Association
"If an endpoint is in the SHUTDOWN-ACK-SENT state and receives an INIT=
   chunk (e.g., if the SHUTDOWN COMPLETE was lost) with source an= d
   destination transport addresses (either in the IP addresses or= in the
   INIT chunk) that belong to this association, it should discard= the
   INIT chunk and retransmit the SHUTDOWN ACK chunk."

------------------------------------------------------------------------= -------------

 

Network scenario as per the above RFC snippet:

SCTP-A           =             &nb= sp;            =             &nb= sp;            =        SCTP-B

Local IP List: L-IP1, L-IP2       &nb= sp;            =             &nb= sp;            = Local IP List: R-IP1, R-IP2

ESTABLISHED          &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            E= STABLISHED

---------------------------SHUT-DOWN (L-IP1->R-IP1)------------------= -->

<-------------------------SHUT-DOWN-ACK (R-IP1<- L-IP1)-----------= ---

---------------------------SHUT-DOWN-COMP (L-IP1->R-IP1)-----= lost in network

Now, local end point rebooted

It might create a new association as below:

local IP addresses.

Local IP List: L-IP2, L-IP3

----------------------------INIT (L-IP2->R-IP1)----------------------= ---------->

     =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            = SHUT-DOWN-ACK sent state

            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;     As per RFC, upon receiving INIT message

            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;     in SHUT-DOWN-ACK-SENT state, it should

            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;     retransmit SHUT-DOWN-ACK and discard INIT = message.

 =

<-----------SHUT-DOWN-ACK (= L-IP1<-R-IP1)------------------- This mesage wil be discarded at L-IP1, since there will be=

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;    no association in L-IP1

 

The destination IP address of = last SHUT-DOWN-ACK message is no more exist. So , all

the SHUT-DOWN-ACK messages sen= t by SCTP-B will be discarded in network.

 

RFC4960 does not mention expli= citly to handle this kind of situation?

 

As, retransmission of SHUT-DOW= N-ACK message is not due to T2 timer expiry, path switching

is not applicable. So, SHUT-DO= WN-ACK message will always be sent on the primary address.

 

So, I believe, SCTP-B should s= end SHUT-DOWN-ACK message to the same destination address

which is exist in both INIT an= d current association destination address list so that the message will

not be discarded.

 

Please share your opinion.

 

Thanks and Regards,

Madan

 

--_000_2F3BA9016646EE43862F506BAC2D49A92CE484C8szxeml537mbxchi_-- From gorry@erg.abdn.ac.uk Mon Jul 8 02:05:42 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF6D21F95DC for ; Mon, 8 Jul 2013 02:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.953 X-Spam-Level: X-Spam-Status: No, score=-105.953 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOZKHNqqe6xZ for ; Mon, 8 Jul 2013 02:05:24 -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 7D1CC21F84A7 for ; Mon, 8 Jul 2013 02:05:14 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id C1F0E2B44CE; Mon, 8 Jul 2013 10:04:56 +0100 (BST) Received: from Gorry.local (fgrpf.plus.com [212.159.18.54]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 5BD702B4075; Mon, 8 Jul 2013 10:04:54 +0100 (BST) Message-ID: <51DA80B5.7060008@erg.abdn.ac.uk> Date: Mon, 08 Jul 2013 10:04:53 +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:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: gjshep@gmail.com, tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tsvwg] Some comments on draft-shepherd-multicast-udp-guidelines-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 08 Jul 2013 09:05:42 -0000 Greg, I like the idea of publishing something on the topic in this draft, and think this a valuable addition to what is said in RFC 5405. It's not that multicast is hard - it's just slightly different. However I do see the need for additional/different congestion control requirements for multicast. Was that the intention, and that the basic guidance for using UDP in RFC 5405 also applies? - I'd have expected that RFC 5405 is normatively cited as a list of basic UDP requirements? This email was as a TSVWG contributor, I'm interested in multicast transport/infrastructure (not as a WG Chair). Gorry --- Introduction: I suspect any advice also applies to use of UDP-Lite with multicast? --- At the end of section 2.1 I see the assertion here that multicast tunnels should not be congestion-controlled, making this the responsibility of applications that use the tunnels. While I can see this has been the case with traditional tunnels, the key question that needs to be thought about here (I think raised by Magnus?) is whether this is right also for automatic multicast tunnels - or whether a circuit-breaker approach, as discussed for example with PW3E, is more appropriate. I'm not sure if the IETF should simply ignore protocols designed for "private" well-managed networks. For unicast, such traffic now frequently traverses VPNs and tunnels via the general Internet. Good advice is important, although we may of course be unable to place "requirements". As above for both unicast and multicast, I think the issue here is that if the "private" traffic is not CC'ed then the tunnels between private networks do not use CC. This then means that we need to think about how to protect the unicast CC traffic from this impact. Is this a network operational responsibility (e.g. alarms and rate limits) or a transport responsibility (e.g. circuit-breakers and CC)? As I recall, the aggregate multicast tunnel traffic may be argued to result in a significant proportion of the internet traffic through a home gateway. This question therefore seems relevant to various drafts including: AMT and draft-ietf-pwe3-p2mp-pw-requirements-02.txt !!! --- The multicast congestion control space faces similar challenges to the multicast reliability space. I think the solution space is slightly bigger than the present draft says. To me, the key issue with Multicast in the General Internet is that there are (at least) three fundamental differences: * The multicast tree is often not heterogeneous - this implies there may be a wide range of path characteristics. This has implications on the methods used for RMT e.g. in 3.1 of RFC 5405, it says many applications "cannot maintain a reliable RTT estimate for a destination". This often applies to the set of destinations in an RMT session or a multicast RTP session. * The heterogeneity also means that some receivers may be receiving significantly more loss than the rest of the group. In talks on multicast I've called these "crying babies" (by which I mean recipients that can gain the attention of the sender and may need special care). It seems to me that many multicast apps try to exclude these from the group - e.g. start a unicast session to this particular endpoint, or simply don't distribute a security key to these receivers. * Any receiver *anywhere* can potentially try to receive any group. That's not a transport problem. It may imply the need for rate limits on the aggregate multicast service, but there is no way at the transport layer to stop a join message propagating to the next hop router. It also points to the need for multicast operators to monitor their infrastructure (which we do, and I'm sure others do - since specific multicast transport issues can only be debugged when you understand the health of the underlying network infrastructure). While all this may initially seem problematic, the overall goal of multicast is for users to get useful data. This implies there is an incentive for apps to not to do silly things that will render their service useless. --- Effective MTU: I saw Lars' comment on path MTU discovery (relating to 3.2 of RFC 5405) - somehow this needs to be combined with the 1200 byte rule of thumb that many of us have been using for multicast for years. I recall some multicast deployments shying away from using PMTUD because it was hard to protect the infrastructure when there was no specific destination endpoint. Hence this was a DoS vulnerability. (Just because a receiver can see a packet from a multicast tree doesn't mean it should be allowed to drive-down the sender MTU to a trivial value). Could the draft explain whether this is an issue or non-issue? --- Security See above on the responsibility for sharing the limited capacity available in a typical home gateway. One of the great things about multicast is RPF checks - a great way to protect from some DOS attacks. RPF checks in multicast REALLY help to make this manageable! IPsec and other security mechanisms work with multicast - but they need multicast key management techniques. Maybe the draft should say something about firewalls - pointing them to support multicast! --- NITS I suspect you do not need to cite this? [I-D.narten-iana-considerations-rfc2434bis]. From Michael.Tuexen@lurchi.franken.de Mon Jul 8 02:33:46 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136E321F9E3B for ; Mon, 8 Jul 2013 02:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ky35-EOcdZnq for ; Mon, 8 Jul 2013 02:33:45 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 74CBC21F9755 for ; Mon, 8 Jul 2013 02:33:43 -0700 (PDT) Received: from [192.168.1.101] (p508F19C9.dip0.t-ipconnect.de [80.143.25.201]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 767F71C0C0692; Mon, 8 Jul 2013 11:33:40 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Tuexen In-Reply-To: <2F3BA9016646EE43862F506BAC2D49A92CE484C8@szxeml537-mbx.china.huawei.com> Date: Mon, 8 Jul 2013 11:33:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <36FC71F6-1754-4F7B-A5AB-D16B3D6947C2@lurchi.franken.de> References: <2F3BA9016646EE43862F506BAC2D49A92CE484C8@szxeml537-mbx.china.huawei.com> To: Madan Mohan Mishra X-Mailer: Apple Mail (2.1508) Cc: "tsvwg@ietf.org" , Rajith Raveendranath , Nagesh shamnur Subject: Re: [tsvwg] (no subject) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 09:33:46 -0000 On Jul 8, 2013, at 7:59 AM, Madan Mohan Mishra = wrote: > Hi Group, > I have a doubt in one of the scenario related to restart duing = shutdown which is not very clear to my understanding as per the RFC4960. = The scenario is as below: > =20 > Clause as per the RFC: > = --------------------------------------------------------------------------= ----------- > 9.2. Shutdown of an Association > "If an endpoint is in the SHUTDOWN-ACK-SENT state and receives an INIT > chunk (e.g., if the SHUTDOWN COMPLETE was lost) with source and > destination transport addresses (either in the IP addresses or in = the > INIT chunk) that belong to this association, it should discard the > INIT chunk and retransmit the SHUTDOWN ACK chunk." > = --------------------------------------------------------------------------= ----------- > =20 > Network scenario as per the above RFC snippet: > SCTP-A = SCTP-B > Local IP List: L-IP1, L-IP2 = Local IP List: R-IP1, R-IP2 > ESTABLISHED = ESTABLISHED > ---------------------------SHUT-DOWN = (L-IP1->R-IP1)--------------------> > <-------------------------SHUT-DOWN-ACK (R-IP1<- L-IP1)-------------- > ---------------------------SHUT-DOWN-COMP (L-IP1->R-IP1)-----lost in = network > Now, local end point rebooted > It might create a new association as below: > local IP addresses. > Local IP List: L-IP2, L-IP3 > ----------------------------INIT = (L-IP2->R-IP1)--------------------------------> > = SHUT-DOWN-ACK sent state > = As per RFC, upon receiving INIT message > = in SHUT-DOWN-ACK-SENT state, it should > = retransmit SHUT-DOWN-ACK and discard INIT message. > =20 > <-----------SHUT-DOWN-ACK (L-IP1<-R-IP1)------------------- This = mesage wil be discarded at L-IP1, since there will be > = no association in L-IP1 > =20 > The destination IP address of last SHUT-DOWN-ACK message is no more = exist. So , all > the SHUT-DOWN-ACK messages sent by SCTP-B will be discarded in = network. > =20 > RFC4960 does not mention explicitly to handle this kind of situation? Well, you can consider the SHUTDOWN-ACK as a response to the received = INIT in this particular case. That would mean that it is a good idea to send the = SHUTDOWN-ACK to the source address of the received INIT. This would resolve your = issue here. Best regards Michael > =20 > As, retransmission of SHUT-DOWN-ACK message is not due to T2 timer = expiry, path switching > is not applicable. So, SHUT-DOWN-ACK message will always be sent on = the primary address. > =20 > So, I believe, SCTP-B should send SHUT-DOWN-ACK message to the same = destination address > which is exist in both INIT and current association destination = address list so that the message will > not be discarded. > =20 > Please share your opinion. > =20 > Thanks and Regards, > Madan > =20 From chelai@cisco.com Mon Jul 8 11:09:39 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BAE21F9C9B for ; Mon, 8 Jul 2013 11:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pW28njZ9Bba for ; Mon, 8 Jul 2013 11:09:35 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E2C7A21F9C11 for ; Mon, 8 Jul 2013 11:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3010; q=dns/txt; s=iport; t=1373306975; x=1374516575; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=prsk5aXZELUcbj0R+zxRX3Ce6bW9Xn0eaxXRJf3NQhM=; b=QwNP2WYlpvEJK3xR5QsSln0xfUmAb6/CKIMM0+BPose5w6FTtlIIInyB Yc+H1ytnjaTa9yIOisdgI0ScOa7iwLhzoodaNeFn5t/cAzWSdxKoXu/u+ 1sjx3o4Hj9VuQ4nBiXjUP2gXiece9vTrCDObDcCC0n8fMOABJ85NtoTdI M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FANn/2lGtJXHA/2dsb2JhbABagwkyRwaDCL1lF34WdIIjAQEBBCMRMRIOBAIBCBEEAQEDAgYdAwICAjAUAQgIAgQTCAGIBgcFqAGRIoEmjhQWIgaCTjNpA5h8kB+DEYIo X-IronPort-AV: E=Sophos;i="4.87,1021,1363132800"; d="scan'208";a="232047786" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 08 Jul 2013 18:09:01 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r68I8r5D022490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 8 Jul 2013 18:08:53 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.24]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Mon, 8 Jul 2013 13:08:53 -0500 From: "Cheng-Jia Lai (chelai)" To: "tsvwg@ietf.org" Thread-Topic: New Version Notification for draft-lai-tsvwg-normalizer-02.txt Thread-Index: AQHOfAOOWCkKXOydoE6QSvOumZ7Q+ZlbE3UQ Date: Mon, 8 Jul 2013 18:08:52 +0000 Message-ID: References: <20130708174941.21964.73518.idtracker@ietfa.amsl.com> In-Reply-To: <20130708174941.21964.73518.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.161.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [tsvwg] New Version Notification for draft-lai-tsvwg-normalizer-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 18:09:39 -0000 SGksDQoNCldlIHVwZGF0ZWQgdGhlIEktRCdzIEFic3RyYWN0IHRvIGNsYXJpZnkgdGhlIHByb2Js ZW0sIGFuZCBvdXIgcHJvcG9zYWwgZm9yIGFuIGluY2VudGl2ZSB0aGF0IG1heSBlbmNvdXJhZ2Ug dmlkZW8gZW5kcG9pbnRzIHRvIGdlbmVyYXRlIG1vcmUgZGlzY2FyZGFibGUgcGFja2V0cyBpbiBs b3dlciBkcm9wIHByZWNlZGVuY2Ugd2l0aGluIEFGIFBIQiBncm91cHMgaW4gRGlmZlNlcnYuIFRo YW5rcyBmb3IgeW91ciBjb21tZW50cyBpbiBhZHZhbmNlLg0KDQpCZXN0IHJlZ2FyZHMsDQpDSg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBK dWx5IDA4LCAyMDEzIDEwOjUwIEFNDQpUbzogU3RhbiBZYW5nIChzdGFueWFuZyk7IEZyZWQgWWlw IChmeWlwKTsgQ2hlbmctSmlhIExhaSAoY2hlbGFpKTsgV2VueWkgV2FuZyAod2VueXdhbmcpOyBU b2VybGVzcyBFY2tlcnQgKGVja2VydCkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtbGFpLXRzdndnLW5vcm1hbGl6ZXItMDIudHh0DQoNCg0KQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LWxhaS10c3Z3Zy1ub3JtYWxpemVyLTAyLnR4dA0KaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBDaGVuZy1KaWEgTGFpIGFuZCBwb3N0ZWQgdG8gdGhlDQpJ RVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtbGFpLXRzdndnLW5vcm1hbGl6ZXIN ClJldmlzaW9uOgkgMDINClRpdGxlOgkJIE5vcm1hbGl6YXRpb24gTWFya2VyIGZvciBBRiBQSEIg R3JvdXAgaW4gRGlmZlNlcnYNCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTA3LTA2DQpHcm91cDoJCSBJ bmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTUNClVSTDogICAgICAgICAg ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGFpLXRzdndnLW5v cm1hbGl6ZXItMDIudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtbGFpLXRzdndnLW5vcm1hbGl6ZXINCkh0bWxpemVkOiAgICAgICAgaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGFpLXRzdndnLW5vcm1hbGl6ZXItMDINCkRp ZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbGFp LXRzdndnLW5vcm1hbGl6ZXItMDINCg0KQWJzdHJhY3Q6DQogICBJbiBEaWZmU2VydiwgcHJlZmVy ZW50aWFsIGRyb3BwaW5nIG9mIHBhY2tldHMgaW4gQUYgUEhCIGdyb3VwcyBoYXMNCiAgIGxvbmcg YmVlbiBjb25zaWRlcmVkIGJlbmVmaWNpYWwsIHR5cGljYWxseSBmb3IgdmlkZW8gZmxvd3Mgd2l0 aA0KICAgZGlzY2FyZGFibGUgcGFja2V0cy4gIFVuZm9ydHVuYXRlbHksIHRoZSBlY29zeXN0ZW0g b2YgYmFuZHdpZHRoDQogICBjb250ZW50aW9uIGF0IGNvbmdlc3Rpb24gaXMgdmVyeSBsaWtlbHkg dG8gZGlzY291cmFnZSB0aG9zZSB2aWRlbw0KICAgZW5kcG9pbnRzIGZyb20gZ2VuZXJhdGluZyBw YWNrZXRzIHdpdGggbG93ZXIgcHJlY2VkZW5jZSBtYXJraW5ncywNCiAgIGkuZS4gdGhleSB3b3Vs ZCBsb3NlIG1vcmUgcGFja2V0cyBpZiBkb2luZyBzby4gIFRodXMsIHRvIG9mZmVyIGFuDQogICBp bmNlbnRpdmUgZm9yIG1vcmUgY29sbGFib3JhdGl2ZSBhbmQgbXV0dWFsbHkgYmVuZWZpY2lhbCBi ZWhhdmlvcnMgb2YNCiAgIHZpZGVvIGVuZHBvaW50cyBpbiBBRiBQSEIgZ3JvdXBzLCB3ZSBwcm9w b3NlIGEgTm9ybWFsaXphdGlvbiBNYXJrZXINCiAgIChOTSkgZm9yIHRyYWZmaWMgY29uZGl0aW9u aW5nIGF0IG5ldHdvcmsgZWRnZXMuICBEZXBsb3ltZW50IG9mIE5NDQogICB3aWxsIGVuY291cmFn ZSB0aGUgdmlkZW8gZW5kcG9pbnRzIHRvIGdlbmVyYXRlIGZpbmVyIGxheWVycyBvZiBpbnRyYS0N CiAgIGZsb3cgcHJlY2VkZW5jZSAoSUZQKSB3aXRoIGRpc2NhcmRhYmxlIHBhY2tldHMgaW4gbW9y ZSBiYWxhbmNlZA0KICAgZGlzdHJpYnV0aW9ucy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From fluffy@iii.ca Mon Jul 8 16:36:37 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D87A21F9BB1 for ; Mon, 8 Jul 2013 16:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D66acc8MxvNt for ; Mon, 8 Jul 2013 16:36:27 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1202B21F9A7A for ; Mon, 8 Jul 2013 16:35:55 -0700 (PDT) Received: from sjc-vpn3-654.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 84C3322E2D0; Mon, 8 Jul 2013 19:35:48 -0400 (EDT) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Jul 2013 16:35:47 -0700 Message-Id: <32AE7F11-A06E-40C1-A73C-5C69F252DAF9@iii.ca> To: tsvwg@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: DAN DRUTA Subject: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 23:36:37 -0000 The draft-dhesikan-tsvwg-rtcweb-qos draft was discussed extensively when = it was an individual draft then WG draft in another WG and I don't think = there is much more to say about it. This is one of the normative = dependencies of the webrtc work and that stuff is already getting = implemented in browsers so I want to move this along in an expedient = fashion.=20 I think it is ready for WGLC. If there are any issues people think need = to be discussed before WGLC, please let us know so we can resolve them = in Berlin. Thanks, Cullen From dave.taht@gmail.com Mon Jul 8 17:00:37 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388A911E80E3 for ; Mon, 8 Jul 2013 17:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.306 X-Spam-Level: X-Spam-Status: No, score=-0.306 tagged_above=-999 required=5 tests=[AWL=-2.294, BAYES_00=-2.599, FRT_STOCK2=3.988, J_CHICKENPOX_102=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LnmLWkIW5IA for ; Mon, 8 Jul 2013 17:00:34 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id BE3E821F9A0C for ; Mon, 8 Jul 2013 17:00:34 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id c10so11631783ieb.10 for ; Mon, 08 Jul 2013 17:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HSZ1LYg+KKWqOx+Bm4Dm+DFrUfbxX1DvNK8Soz1kzpQ=; b=eOeQJsP4gACJIZjfvYVlUvBskNUfpVPjX5nzZ7aPLoQgg6cXIifnaSfkmFmgAReHxy KbFq8qJMYu8OqPPggRguzKEVQ+VtszL4n1O1E+cFwb1ABu1N6zk94kNypYPII2MYTHth XF6HDEwdF/6cogNK7nKkieN4hGjkVKD/i4SWkdEK3ZtD/jimjPmBY2FNMyfEdsPSMWek rgO6MicnkwxH7x9AFPv18JaTTg6FPNdCiGymZp7mww8KOGnawUfK3RyeCu6ijXDxkj9N Ltg3iVKcgqqoJXRipV2+Cv/CLhhapOeie1IcETnY38MPTLJ8f050RKSzZQsbedS+oFKd H1zw== MIME-Version: 1.0 X-Received: by 10.50.23.8 with SMTP id i8mr33131466igf.42.1373328033738; Mon, 08 Jul 2013 17:00:33 -0700 (PDT) Received: by 10.64.86.8 with HTTP; Mon, 8 Jul 2013 17:00:33 -0700 (PDT) In-Reply-To: <32AE7F11-A06E-40C1-A73C-5C69F252DAF9@iii.ca> References: <32AE7F11-A06E-40C1-A73C-5C69F252DAF9@iii.ca> Date: Mon, 8 Jul 2013 17:00:33 -0700 Message-ID: From: Dave Taht To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DAN DRUTA , tsvwg@ietf.org Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 00:00:37 -0000 On Mon, Jul 8, 2013 at 4:35 PM, Cullen Jennings wrote: > > The draft-dhesikan-tsvwg-rtcweb-qos draft was discussed extensively when = it was an individual draft then WG draft in another WG and I don't think th= ere is much more to say about it. This is one of the normative dependencies= of the webrtc work and that stuff is already getting implemented in browse= rs so I want to move this along in an expedient fashion. > > I think it is ready for WGLC. If there are any issues people think need t= o be discussed before WGLC, please let us know so we can resolve them in Be= rlin. > > Thanks, Cullen > Note: The sample code in the document does not include correct code for ipv6, which is more or less: IPv6 DiffServ IPv4 IPPROTO_IP IP_TOS IPv6 IPPROTO_IPV6 IPV6_TCLASS So, to set the DSCP in IPv6 you must use IPv6 Traffic Class field. int ds =3D IPTOS_DSCP_AF11; int rc =3D setsockopt(fd, IPPROTO_IPV6, IPV6_TCLASS, &ds, sizeof(ds)); see: http://www.bufferbloat.net/issues/249 for more details --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From fluffy@iii.ca Mon Jul 8 17:28:30 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716DE21F9B08 for ; Mon, 8 Jul 2013 17:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.23 X-Spam-Level: X-Spam-Status: No, score=-0.23 tagged_above=-999 required=5 tests=[AWL=-2.219, BAYES_00=-2.599, FRT_STOCK2=3.988, J_CHICKENPOX_102=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meqpZuuToHI5 for ; Mon, 8 Jul 2013 17:28:26 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9EB21F9B21 for ; Mon, 8 Jul 2013 17:28:24 -0700 (PDT) Received: from sjc-vpn3-654.cisco.com (unknown [128.107.239.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 64492509B8; Mon, 8 Jul 2013 20:28:21 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Cullen Jennings In-Reply-To: Date: Mon, 8 Jul 2013 17:28:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1F2C212E-475E-403B-BC7E-DF94A25B8E3B@iii.ca> References: <32AE7F11-A06E-40C1-A73C-5C69F252DAF9@iii.ca> To: Dave Taht X-Mailer: Apple Mail (2.1508) Cc: DAN DRUTA , tsvwg@ietf.org Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 00:28:30 -0000 Good catch - thank you. On Jul 8, 2013, at 5:00 PM, Dave Taht wrote: > On Mon, Jul 8, 2013 at 4:35 PM, Cullen Jennings wrote: >>=20 >> The draft-dhesikan-tsvwg-rtcweb-qos draft was discussed extensively = when it was an individual draft then WG draft in another WG and I don't = think there is much more to say about it. This is one of the normative = dependencies of the webrtc work and that stuff is already getting = implemented in browsers so I want to move this along in an expedient = fashion. >>=20 >> I think it is ready for WGLC. If there are any issues people think = need to be discussed before WGLC, please let us know so we can resolve = them in Berlin. >>=20 >> Thanks, Cullen >>=20 >=20 > Note: The sample code in the document does not include correct code > for ipv6, which is more or less: >=20 > IPv6 DiffServ >=20 > IPv4 IPPROTO_IP IP_TOS > IPv6 IPPROTO_IPV6 IPV6_TCLASS >=20 > So, to set the DSCP in IPv6 you must use IPv6 Traffic Class field. >=20 > int ds =3D IPTOS_DSCP_AF11; > int rc =3D setsockopt(fd, IPPROTO_IPV6, IPV6_TCLASS, &ds, sizeof(ds)); >=20 > see: >=20 > http://www.bufferbloat.net/issues/249 >=20 > for more details >=20 > --=20 > Dave T=E4ht >=20 > Fixing bufferbloat with cerowrt: = http://www.teklibre.com/cerowrt/subscribe.html From hannes.tschofenig@gmx.net Tue Jul 9 00:51:16 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BABA21F9F4C for ; Tue, 9 Jul 2013 00:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfVbU79mW8Rb for ; Tue, 9 Jul 2013 00:51:11 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id A40F421F9F42 for ; Tue, 9 Jul 2013 00:51:10 -0700 (PDT) Received: from [172.16.254.103] ([80.92.116.131]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MQQzk-1UmXaJ1oJI-00TkRA; Tue, 09 Jul 2013 09:51:00 +0200 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <32AE7F11-A06E-40C1-A73C-5C69F252DAF9@iii.ca> Date: Tue, 9 Jul 2013 10:50:55 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <32AE7F11-A06E-40C1-A73C-5C69F252DAF9@iii.ca> To: Cullen Jennings X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:vyJYbOKskVV/MD3gDVsG/X+ofY7SEJN+4X70nQubLK+VkDEuf6d HDcLwvPpx4H+nHEByB2WeHWVWEC0quCqpkrd8fbbFmZtqBWsaQcp6TWarIi7bX/CcSZKsHB jghVSt0N6FJ87RtxrhQuBD9lKpme8T/5e7PO1yyTARPRIGoZE8g8kpFD9wylDWmrq9qnkNv GbS6CUaYHOMUYrGXUQ+zA== Cc: DAN DRUTA , tsvwg@ietf.org Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 07:51:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Cullen,=20 this document is still an individual draft and so I am not sure what you = mean by working group last call.=20 - =46rom a content point of view I am not sure how useful it is. I = shared my views about how this applies to LTE; IMHO it is not = applicable. It would be so great if we could solve all QoS challenges by defining = yet another set of DiffServ code points.=20 Ciao Hannes On Jul 9, 2013, at 2:35 AM, Cullen Jennings wrote: >=20 > The draft-dhesikan-tsvwg-rtcweb-qos draft was discussed extensively = when it was an individual draft then WG draft in another WG and I don't = think there is much more to say about it. This is one of the normative = dependencies of the webrtc work and that stuff is already getting = implemented in browsers so I want to move this along in an expedient = fashion.=20 >=20 > I think it is ready for WGLC. If there are any issues people think = need to be discussed before WGLC, please let us know so we can resolve = them in Berlin. >=20 > Thanks, Cullen >=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR28DgAAoJEGhJURNOOiAtwEgH/RyutI92AUxypRQxBkUT/kUW 3JBjPOCEZyrIcShqlwLtesmOhrgbxbkoo8ltHSwEoQdPAWo+krmJBaG+5Z/ypCwB PHz7zmepxChbQUF/giBp/9Sa37PlV7F0TSG3Bp9cFrXAYqCBhuyD34veosIAUE69 HZu9yFwmEreLCIeggdcUyD1Loy+pZd1Sqs5wicFu+7oV8M+ejb2D4x3GozhgV2RJ dVxtl0dvJ1lPwNluCSXr57ZtUAHHuFDQ28qujt6cCQyVytRT2HkS3DgRX58ownGg 3d8W6Dw7bbkU3WN0+oyOnthGdiYP2Kr2hSbEKWSGXCn9bYiNDiwWEdzjvsUsUxs=3D =3DS45+ -----END PGP SIGNATURE----- From gorry@erg.abdn.ac.uk Tue Jul 9 01:03:41 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACEC21F9E0A for ; Tue, 9 Jul 2013 01:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.264 X-Spam-Level: X-Spam-Status: No, score=-106.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXbGDYUguu+B for ; Tue, 9 Jul 2013 01:03:35 -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 8859021F9E01 for ; Tue, 9 Jul 2013 01:03:33 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id BFED72B44CA; Tue, 9 Jul 2013 09:03:32 +0100 (BST) Received: from Gorry.local (fgrpf.plus.com [212.159.18.54]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id BE80A2B4250 for ; Tue, 9 Jul 2013 09:03:31 +0100 (BST) Message-ID: <51DBC3D3.3000300@erg.abdn.ac.uk> Date: Tue, 09 Jul 2013 09:03:31 +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:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: tsvwg@ietf.org References: <32AE7F11-A06E-40C1-A73C-5C69F252DAF9@iii.ca> In-Reply-To: <32AE7F11-A06E-40C1-A73C-5C69F252DAF9@iii.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 08:03:41 -0000 On 09/07/2013 00:35, Cullen Jennings wrote: > > The draft-dhesikan-tsvwg-rtcweb-qos draft was discussed extensively when it was an individual draft then WG draft in another WG and I don't think there is much more to say about it. This is one of the normative dependencies of the webrtc work and that stuff is already getting implemented in browsers so I want to move this along in an expedient fashion. > > I think it is ready for WGLC. If there are any issues people think need to be discussed before WGLC, please let us know so we can resolve them in Berlin. > > Thanks, Cullen > In the email above you ask for WGLC. The first step is for the group to consider adoption. As I recall, this draft was brought to TSVWG for consideration because it discusses transport mappings to QoS. I understand from the draft this proposes default mappings for an RTCWeb use cases. As I see it, the present draft: * Advocates use of separate QoS code points for different streaming components * Describes both endpoint handling of priority for the media and transport priority/precedence (aka DSCP). * Proposes formalising a mapping between specific DSCPs and subnetwork QoS functions (LTE, WiFi - but not general Ethernet). Please read this draft and comment on the list - we will table this for discussion at the next IETF meeting. Gorry From andrewmcgr@gmail.com Tue Jul 9 02:48:20 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A1D21F9F98 for ; Tue, 9 Jul 2013 02:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHdYBe6Nl2AO for ; Tue, 9 Jul 2013 02:48:19 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id A63B121F9F96 for ; Tue, 9 Jul 2013 02:48:18 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id fq12so4535073lab.24 for ; Tue, 09 Jul 2013 02:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6sS2YZe/r2NsfXjipUQ2uNBpcS2CnueiZ4zIgnsmOjk=; b=0iiy/mIn32tQ6K9YX+zwwYjSOZ5kE+3W4tH/PfhqrmL+bEXCLMKRdSiNZmM5+uvJ4f ix3mM9dmpFcOOjUHZ95ScypnIOM3dICHypmHaYyjurYFlfcDCSdKL+yYmVpFU5TAtX51 22y95CilrQY0fg4X7FL/6QMc+0i1jXXzFJpg5swnvOCbEtYLaAK/IaLfveDi7/fYALoa vsKjyQkNBRVn37tti2DHFiPqU0svqLpItHxySwvW0Kun55TO/NphzNdoz4hPX3W2b1H6 HMGzVatnyj0SM+pPLZNKtaIltlASHTCj71HjixBTZ2jg9VBRzy0akBxXZP7HoSAw9dFo PbtA== MIME-Version: 1.0 X-Received: by 10.152.22.42 with SMTP id a10mr12573431laf.30.1373363297559; Tue, 09 Jul 2013 02:48:17 -0700 (PDT) Received: by 10.112.51.41 with HTTP; Tue, 9 Jul 2013 02:48:17 -0700 (PDT) In-Reply-To: <51DBC3D3.3000300@erg.abdn.ac.uk> References: <32AE7F11-A06E-40C1-A73C-5C69F252DAF9@iii.ca> <51DBC3D3.3000300@erg.abdn.ac.uk> Date: Tue, 9 Jul 2013 19:48:17 +1000 Message-ID: From: Andrew McGregor To: gorry@erg.abdn.ac.uk Content-Type: multipart/alternative; boundary=089e0158b7947faabf04e1110f4b Cc: tsvwg Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 09:48:20 -0000 --089e0158b7947faabf04e1110f4b Content-Type: text/plain; charset=ISO-8859-1 So, there is a significant bug in the mappings proposed. That is this: there is a substantial deployed base of home routers and other network devices that use the Linux kernel's default output queue pfifo_fast, which uses a mapping derived from RFC 1349 (documented in the linux man page tc_prio, see for example http://linux.die.net/man/8/tc-prio) If the proposed mappings don't work with that queue discipline, they won't work on the deployed base. pfifo_fast has then unfortunate properties of ignoring the top 3 bits of the tos byte, and sometimes paying attention to one of the ECN bits in choosing a queueing band. In effect, since Linux has produced a de-facto standard codepoint assignment for the edge of the network, we had better recommend something compatible. The proposed mapping uses EF for all audio, which will create a priority inversion and have all the Linux devices on the edge classify that traffic as 'bulk interactive', lower than the interactive video at AF4x in the 'interactive' band. This is probably not what we want. I've filled out the linux band numbers in table 1 from the draft; the third number in each table cell is the linux band, smaller number is higher priority: +-----------------------+-------------+-------------+-------------+ | Media Type | Low | Medium | High | +-----------------------+-------------+-------------+-------------+ | Audio | 46 (EF) 1 | 46 (EF) 1 | 46 (EF) 1 | | Interactive Video | 38 (AF43) 1 | 36 (AF42) 0 | 34 (AF41) 2 | | Non-Interactive Video | 26 (AF33) 1 | 28 (AF32) 0 | 30 (AF31) 2 | | Data | 8 (CS1) 1 | 0 (BE) 1 | 10 (AF11) 2 | +-----------------------+-------------+-------------+-------------+ Table 1 - Media Type, Priority, and DSCP Mapping As can readily be seen, there are a number of priority inversions there. Effectively, RFC 4594 doesn't work as designed at the edge of the network, and we have to go back to RFC 1349, or at least a restricted set of RFC 4594 codepoints. Effectively, Linux has given us a priority series that reads: AFx2>AFx3>AFx1>(CS1 or BE) So, for the purpose of working with both Linux routers and RFC 4594, the useful series of codepoints are AF42>AF33>AF21>(CS1 or BE), and it becomes an exercise of deciding where to place those codepoints in the table. I'd rather use CS1 than BE because it at least states that the application is doing QoS marking. Aside from fixing the actual mappings, though, the draft is a great idea and really should be published as soon as reasonably possible. On Tue, Jul 9, 2013 at 6:03 PM, Gorry Fairhurst wrote: > On 09/07/2013 00:35, Cullen Jennings wrote: > >> >> The draft-dhesikan-tsvwg-rtcweb-**qos draft was discussed extensively >> when it was an individual draft then WG draft in another WG and I don't >> think there is much more to say about it. This is one of the normative >> dependencies of the webrtc work and that stuff is already getting >> implemented in browsers so I want to move this along in an expedient >> fashion. >> >> I think it is ready for WGLC. If there are any issues people think need >> to be discussed before WGLC, please let us know so we can resolve them in >> Berlin. >> >> Thanks, Cullen >> >> > In the email above you ask for WGLC. The first step is for the group to > consider adoption. As I recall, this draft was brought to TSVWG for > consideration because it discusses transport mappings to QoS. > > I understand from the draft this proposes default mappings for an RTCWeb > use cases. As I see it, the present draft: > > * Advocates use of separate QoS code points for different streaming > components > > * Describes both endpoint handling of priority for the media and transport > priority/precedence (aka DSCP). > > * Proposes formalising a mapping between specific DSCPs and subnetwork QoS > functions (LTE, WiFi - but not general Ethernet). > > Please read this draft and comment on the list - we will table this for > discussion at the next IETF meeting. > > Gorry > > > --089e0158b7947faabf04e1110f4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
So, there is a significant bug in the mappings proposed. = =A0That is this: there is a substantial deployed base of home routers and o= ther network devices that use the Linux kernel's default output queue p= fifo_fast, which uses a mapping derived from RFC 1349=A0(documented in the = linux man page tc_prio, see for example http://linux.die.net/man/8/tc-prio)=A0 =A0If the proposed m= appings don't work with that queue discipline, they won't work on t= he deployed base. =A0pfifo_fast has then unfortunate properties of ignoring= the top 3 bits of the tos byte, and sometimes paying attention to one of t= he ECN bits in choosing a queueing band.

In effect, since Linux has produced a de-facto standard code= point assignment for the edge of the network, we had better recommend somet= hing compatible. =A0The proposed mapping uses EF for all audio, which will = create a priority inversion and have all the Linux devices on the edge clas= sify that traffic as 'bulk interactive', lower than the interactive= video at AF4x in the 'interactive' band. =A0This is probably not w= hat we want.

I've filled out the linux band numbers in table 1 f= rom the draft; the third number in each table cell is the linux band, small= er number is higher priority:
+-----------------------+-----= --------+-------------+-------------+
| Media Type =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Low =A0 =A0 =A0| =A0 Medi= um =A0 =A0| =A0 =A0High =A0 =A0 |
+-----------------------+------= -------+-------------+-------------+
| Audio =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 | =A046 (EF) =A01 | =A046 (EF) =A01 | =A046 (EF) =A01 |
| Interactive Video =A0 =A0 | 38 (AF43) 1 | 36 (AF42) 0 | 34 (AF41) 2 = |
| Non-Interactive Video | 26 (AF33) 1 | 28 (AF32) 0 | 30 (AF31)= 2 |
| Data =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A08 (CS1) =A01 = | =A0 0 (BE) =A01 | 10 (AF11) 2 |
+-----------------------+-------------+-------------+-------------+
=A0 =A0 =A0 Table 1 - Media Type, Priority, and DSCP Mapping
<= div>
As can readily be seen, there are a number of prio= rity inversions there. =A0Effectively, RFC 4594 doesn't work as designe= d at the edge of the network, and we have to go back to RFC 1349, or at lea= st a restricted set of RFC 4594 codepoints.

Effectively, Linux has given us a priority = series that reads: AFx2>AFx3>AFx1>(CS1 or BE)

=
So, for the purpose of working with both Linux routers and= RFC 4594, the useful series of codepoints are AF42>AF33>AF21>(CS1= or BE), and it becomes an exercise of deciding where to place those codepo= ints in the table. =A0I'd rather use CS1 than BE because it at least st= ates that the application is doing QoS marking.

Aside from fixing the actual mappings, though, th= e draft is a great idea and really should be published as soon as reasonabl= y possible.


On Tue, Jul 9, 2013 at 6:03 PM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
On 09/07/2013 00:35, Cullen Jenning= s wrote:

The draft-dhesikan-tsvwg-rtcweb-qos draft was discussed extensively = when it was an individual draft then WG draft in another WG and I don't= think there is much more to say about it. This is one of the normative dep= endencies of the webrtc work and that stuff is already getting implemented = in browsers so I want to move this along in an expedient fashion.

I think it is ready for WGLC. If there are any issues people think need to = be discussed before WGLC, please let us know so we can resolve them in Berl= in.

Thanks, Cullen


In the email above you ask for WGLC. The first step is for the group to con= sider adoption. As I recall, this draft was brought to TSVWG for considerat= ion because it discusses transport mappings to QoS.

I understand from the draft this proposes default mappings for an RTCWeb us= e cases. As I see it, the present draft:

* Advocates use of separate QoS code points for different streaming compone= nts

* Describes both endpoint handling of priority for the media and transport = priority/precedence (aka DSCP).

* Proposes formalising a mapping between specific DSCPs and subnetwork QoS = functions (LTE, WiFi - but not general Ethernet).

Please read this draft and comment on the list - we will table this for dis= cussion at the next IETF meeting.

Gorry



--089e0158b7947faabf04e1110f4b-- From turners@ieca.com Tue Jul 9 04:06:04 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443E621F9F45 for ; Tue, 9 Jul 2013 04:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOGt6amZ+-10 for ; Tue, 9 Jul 2013 04:05:59 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [74.52.222.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2B95C21F9F05 for ; Tue, 9 Jul 2013 04:05:59 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 057D6654613AC; Tue, 9 Jul 2013 06:05:58 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id EE24965461387 for ; Tue, 9 Jul 2013 06:05:57 -0500 (CDT) Received: from [74.96.0.204] (port=50438 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UwVk5-0004es-Qh for tsvwg@ietf.org; Tue, 09 Jul 2013 06:05:57 -0500 Message-ID: <51DBEE95.1080301@ieca.com> Date: Tue, 09 Jul 2013 07:05:57 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [74.96.0.204]:50438 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [tsvwg] wg review/adoption of draft-turner-rsvp-auth-update X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 11:06:04 -0000 Hi, I'd like to solicit additional review of this draft: http://datatracker.ietf.org/doc/draft-turner-rsvp-auth-update/ We got some initial comments from David Black that we incorporated in the -01 version. The issue we're most worried about is whether using unused reserved bits will cause problems. I've also asked for a couple of minutes on the tsvwg's agenda to discuss this draft. Cheers, spt From gorry@erg.abdn.ac.uk Tue Jul 9 06:31:30 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51F621F9CCC for ; Tue, 9 Jul 2013 06:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKnyxoj1oiEw for ; Tue, 9 Jul 2013 06:31:26 -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 DC62F21F9CDD for ; Tue, 9 Jul 2013 06:31:25 -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 875672B4250 for ; Tue, 9 Jul 2013 14:31:24 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Tue, 9 Jul 2013 14:31:24 +0100 Message-ID: <63962533299aeee4ae03283e9e9b6b0e.squirrel@www.erg.abdn.ac.uk> Date: Tue, 9 Jul 2013 14:31:24 +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 Subject: [tsvwg] Preliminary TSVWG Agenda X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 13:31:30 -0000 Here is a link to the draft agenda - this is preliminary, we have still to schedule some talks and we may yet adjust this agenda. http://tools.ietf.org/wg/tsvwg/agenda?item=agenda-87-tsvwg.html Let us know of corrections, conflicts or omissions. Gorry, David and James (TSVWG Co-Chairs) From eckelcu@cisco.com Tue Jul 9 14:05:13 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB41521F99F6 for ; Tue, 9 Jul 2013 14:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5esN9tWbqv3 for ; Tue, 9 Jul 2013 14:05:08 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id ED73B21F9DC2 for ; Tue, 9 Jul 2013 14:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1143; q=dns/txt; s=iport; t=1373403908; x=1374613508; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=+O4/D4xsGNviglpvlnYaGBo6C9HBfJ4vCEKxePhH3dg=; b=Darg2wc7mB0+H3Gfl8anjF64Br6qMVa5uA1jPT5cgPqL+leRWfTz80dz hh54seuUxvoALdsktbQO6q1q3qflI3wOsUMm6PcPAX+gPp0OgrVJLMRzn 9r5KTpyQuusDOOtaW5BIDZVYGC0V/8U+nWkTGC1RaCDNNQ9kg9p8zyxd+ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAGZ63FGtJV2d/2dsb2JhbABbDoJ7Mk3BEYEbFnSCIwEBAQQ6SwQCAQgRBAEBCxQJBzIUCQgCBAESCIgGAQy6Bo86OAaDA2sDmH2QIIJTPoIo X-IronPort-AV: E=Sophos;i="4.87,1030,1363132800"; d="scan'208";a="229794082" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 09 Jul 2013 21:05:03 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r69L52Th020036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Jul 2013 21:05:02 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.187]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Tue, 9 Jul 2013 16:05:02 -0500 From: "Charles Eckel (eckelcu)" To: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] Preliminary TSVWG Agenda Thread-Index: AQHOfKii1NaOlInuvky0Sq3I2dubaplc1RRQ Date: Tue, 9 Jul 2013 21:05:02 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828048B0814@xmb-aln-x08.cisco.com> References: <63962533299aeee4ae03283e9e9b6b0e.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <63962533299aeee4ae03283e9e9b6b0e.squirrel@www.erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tsvwg] Preliminary TSVWG Agenda X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 21:05:14 -0000 Hi Chairs, Here are links to the two missing drafts identified in the draft agenda. http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encoding-00 http://tools.ietf.org/html/draft-zamfir-tsvwg-flow-metadata-rsvp-00 I will forward the corresponding draft announcements as well. We appreciate any comments on the drafts and hope to have some time to pres= ent them at IETF 87.=20 The overall framework of which these drafts are a part is provided by: http://tools.ietf.org/html/draft-eckert-intarea-flow-metadata-framework-00 Cheers, Charles > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > gorry@erg.abdn.ac.uk > Sent: Tuesday, July 09, 2013 6:31 AM > To: tsvwg@ietf.org > Subject: [tsvwg] Preliminary TSVWG Agenda >=20 > Here is a link to the draft agenda - this is preliminary, we have still t= o > schedule some talks and we may yet adjust this agenda. >=20 > http://tools.ietf.org/wg/tsvwg/agenda?item=3Dagenda-87-tsvwg.html >=20 > Let us know of corrections, conflicts or omissions. >=20 > Gorry, David and James > (TSVWG Co-Chairs) From eckelcu@cisco.com Tue Jul 9 14:08:45 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4148121F9DB5 for ; Tue, 9 Jul 2013 14:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sL05nSpA0RGN for ; Tue, 9 Jul 2013 14:08:40 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BF78621F9D0F for ; Tue, 9 Jul 2013 14:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4780; q=dns/txt; s=iport; t=1373404120; x=1374613720; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=2LNnDhHIsBxSOzxjSw7VHsju2PGgq9U5UU4PN5BQHJE=; b=XBAFef5DRhGizB47EbjRxLoyzfwcGk4/DqmprGGHKtLdJmAwM1tJmah0 8zygHquRiOefgS2n755pKBx4/aTXKJNe5JfRknJhzF8Y91lXAz3GFIDMA +Rdx5YftJW/BOkjoNHyoITfwSRvIjzSidePB3FY84oyHslPxwuzRkPftp M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFANR63FGtJV2b/2dsb2JhbABbgwkyTYMIvgkXgQQWdIIjAQEBBCMRQw4GAQgRBAEBAwIGHQMCBDAUAQYBAQUEAQQTCAGIBQEMmWCOfZEpgSaOFA8vglAzawOYfZAggViBOYIo X-IronPort-AV: E=Sophos;i="4.87,1030,1363132800"; d="scan'208";a="232815259" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 09 Jul 2013 21:08:39 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r69L8dSj017435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 9 Jul 2013 21:08:39 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.187]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 9 Jul 2013 16:08:38 -0500 From: "Charles Eckel (eckelcu)" To: "tsvwg@ietf.org" Thread-Topic: New Version Notification for draft-choukir-tsvwg-flow-metadata-encoding-00.txt Thread-Index: Ac586HrbP3VYJaT6Rgu7o3L6GEcq0A== Date: Tue, 9 Jul 2013 21:08:37 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828048B0832@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [tsvwg] FW: New Version Notification for draft-choukir-tsvwg-flow-metadata-encoding-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 21:08:45 -0000 VGhpcyBpcyBvbmUgb2YgYSBzZXQgb2YgZHJhZnRzIGZvciBjb21tdW5pY2F0aW5nIGZsb3cgY2hh cmFjdGVyaXN0aWNzIChhLmsuYS4gbWV0YWRhdGEpIGluIGEgY29uc2lzdGVudCBtYW5uZXIgYmV0 d2VlbiBhcHBsaWNhdGlvbnMgYW5kIHRoZSBuZXR3b3JrIHRvIHByb3ZpZGUgYmV0dGVyIHZpc2li aWxpdHkgb2YgYXBwbGljYXRpb24gZmxvd3MuDQoNClRoZSBmcmFtZXdvcmsgaXMgZGVzY3JpYmVk IGluOg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZWNrZXJ0LWludGFyZWEtZmxv dy1tZXRhZGF0YS1mcmFtZXdvcmstMDANCg0KVGhpcyBkb2N1bWVudCAoaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtY2hvdWtpci10c3Z3Zy1mbG93LW1ldGFkYXRhLWVuY29kaW5nLTAw KSBkZXNjcmliZXMgYSBwcm90b2NvbCBpbmRlcGVuZGVudCBlbmNvZGluZyBmb3IgZmxvdyBtZXRh ZGF0YS4gQSBmbG93IGlzIGRlZmluZWQgYXMgYSBzZXQgb2YgSVAgcGFja2V0cyBwYXNzaW5nIHRo cm91Z2ggYSBuZXR3b3JrIGluIGEgZ2l2ZW4gZGlyZWN0aW9uLiAgQWxsIHBhY2tldHMgYmVsb25n aW5nIHRvIGEgcGFydGljdWxhciBmbG93IGhhdmUgYSBzZXQgb2YgY29tbW9uIHByb3BlcnRpZXMg KGUuZy4gSVAsIHBvcnQsIHRyYW5zcG9ydCkuDQpGbG93IG1ldGFkYXRhIGV4cG9zZXMga2V5IGNo YXJhY3RlcmlzdGljcyBvZiB0aGUgZmxvdywgc3VjaCBhcyB0aGUgYmFuZHdpZHRoLCB0aGUgdG9s ZXJhbmNlIHRvIGRlbGF5IGFuZCBsb3NzLCBhbmQgb3RoZXJzIGFzIGRlZmluZWQgaW4gdGhlIGZy YW1ld29yayBkcmFmdC4gVGhpcyBpbmZvcm1hdGlvbiBpcyBzaWduYWxlZCBhbG9uZyB0aGUgc2Ft ZSBwYXRoIGFzIHRoZSBhY3R1YWwgZmxvdy4NCg0KVGhlIG1hcHBpbmcgb2YgZmxvdyBtZXRhZGF0 YSBlbmNvZGluZyB0byBkaWZmZXJlbnQgc2lnbmFsaW5nIHByb3RvY29scyBpcyBvdXRzaWRlIHRo ZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiBUaGUgZm9sbG93aW5nIGRyYWZ0cyBwcm92aWRlIG1h cHBpbmcgdG8gUENQLCBSU1ZQLCBhbmQgU1RVTjoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXdpbmctcGNwLWZsb3dkYXRhLTAwDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC16YW1maXItdHN2d2ctZmxvdy1tZXRhZGF0YS1yc3ZwLTAwDQpodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1tYXJ0aW5zZW4tbW11c2ljLW1hbGljZS0wMA0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgSnVseSAwOCwgMjAxMyAz OjEzIFBNDQpUbzogVG9lcmxlc3MgRWNrZXJ0IChlY2tlcnQpOyBBbWluZSBDaG91a2lyIChhbWNo b3VraSk7IEFuY2EgWmFtZmlyIChhbmNheik7IENoYXJsZXMgRWNrZWwgKGVja2VsY3UpDQpTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWNob3VraXItdHN2d2ctZmxv dy1tZXRhZGF0YS1lbmNvZGluZy0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtY2hvdWtpci10c3Z3Zy1mbG93LW1ldGFkYXRhLWVuY29kaW5nLTAwLnR4dA0KaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUb2VybGVzcyBFY2tlcnQgYW5kIHBvc3RlZCB0byB0 aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1jaG91a2lyLXRzdndnLWZs b3ctbWV0YWRhdGEtZW5jb2RpbmcNClJldmlzaW9uOgkgMDANClRpdGxlOgkJIFByb3RvY29sIElu ZGVwZW5kZW50IEVuY29kaW5nIGZvciBTaWduYWxpbmcgRmxvdyBDaGFyYWN0ZXJpc3RpY3MNCkNy ZWF0aW9uIGRhdGU6CSAyMDEzLTA3LTA5DQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24N Ck51bWJlciBvZiBwYWdlczogMTgNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtY2hvdWtpci10c3Z3Zy1mbG93LW1ldGFkYXRhLWVuY29k aW5nLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWNob3VraXItdHN2d2ctZmxvdy1tZXRhZGF0YS1lbmNvZGluZw0KSHRtbGl6ZWQ6 ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaG91a2lyLXRzdndnLWZs b3ctbWV0YWRhdGEtZW5jb2RpbmctMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIGEgcHJvdG9jb2wgaW5kZXBlbmRlbnQgZW5jb2RpbmcgZm9yIGZsb3cNCiAgIGNo YXJhY3RlcmlzdGljcyAoYS5rLmEuIG1ldGFkYXRhKS4gIEEgZmxvdyBpcyBkZWZpbmVkIGFzIGEg c2V0IG9mIElQDQogICBwYWNrZXRzIHBhc3NpbmcgdGhyb3VnaCBhIG5ldHdvcmsgaW4gYSBnaXZl biBkaXJlY3Rpb24uICBBbGwgcGFja2V0cw0KICAgYmVsb25naW5nIHRvIGEgcGFydGljdWxhciBm bG93IGhhdmUgYSBzZXQgb2YgY29tbW9uIHByb3BlcnRpZXMgKGUuZy4NCiAgIElQLCBwb3J0LCB0 cmFuc3BvcnQpLiAgRmxvdyBtZXRhZGF0YSBleHBvc2VzIGtleSBjaGFyYWN0ZXJpc3RpY3Mgb2YN CiAgIHRoZSBmbG93IHN1Y2ggYXMgdGhlIG9yaWdpbmF0aW5nIGFwcGxpY2F0aW9uLCB0aGUgdHlw ZSBvZiBtZWRpYSBpbg0KICAgdXNlIChlLmcuICBhdWRpbywgdmlkZW8pIGFuZCBvdGhlcnMgYXMg ZGVmaW5lZCBpbg0KICAgW0ktRC5lY2tlcnQtaW50YXJlYS1mbG93LW1ldGFkYXRhLWZyYW1ld29y a10uICBUaGUgZmxvdw0KICAgY2hhcmFjdGVyaXN0aWNzIGFyZSBleHByZXNzZWQgaW4gdGVybXMg b2YgaW5mb3JtYXRpb24gZWxlbWVudHMuDQogICBUaGVzZSBpbmZvcm1hdGlvbiBlbGVtZW50cyBh cmUgc2lnbmFsZWQgZWl0aGVyIG91dCBvZiBiYW5kIG9yIGluIGJhbmQNCiAgIGJ1dCBhbHdheXMg YWxvbmcgdGhlIHNhbWUgcGF0aCBvZiB0aGUgZmxvdyBhc3NvY2lhdGVkIHdpdGggdGhlDQogICBh cHBsaWNhdGlvbi4NCg0KICAgW0ktRC5lY2tlcnQtaW50YXJlYS1mbG93LW1ldGFkYXRhLWZyYW1l d29ya10gZGVmaW5lcyB0aGUgb3ZlcmFsbA0KICAgZnJhbWV3b3JrIGZvciBmbG93IG1ldGFkYXRh IGFuZCB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgZmxvdw0KICAgY2hhcmFjdGVyaXN0aWNzLCB3aGVy ZWFzIHRoaXMgZG9jdW1lbnQgY2FwdHVyZXMgdGhlIGVuY29kaW5nIG9mIHRoZXNlDQogICBjaGFy YWN0ZXJpc3RpY3MuICBUaGUgbWFwcGluZyBvZiBmbG93IG1ldGFkYXRhIGVuY29kaW5nIHRvIGRp ZmZlcmVudA0KICAgc2lnbmFsaW5nIHByb3RvY29scyBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0 aGlzIGRvY3VtZW50Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYg U2VjcmV0YXJpYXQNCg0K From wes@mti-systems.com Tue Jul 9 19:56:54 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAAC21F99CF for ; Tue, 9 Jul 2013 19:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPsVYCQIR0bm for ; Tue, 9 Jul 2013 19:56:48 -0700 (PDT) Received: from atl4mhfb03.myregisteredsite.com (atl4mhfb03.myregisteredsite.com [209.17.115.61]) by ietfa.amsl.com (Postfix) with ESMTP id A2C0721F9A35 for ; Tue, 9 Jul 2013 19:56:42 -0700 (PDT) Received: from atl4mhob15.myregisteredsite.com (atl4mhob15.myregisteredsite.com [209.17.115.53]) by atl4mhfb03.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r6A2ufQP026913 for ; Tue, 9 Jul 2013 22:56:41 -0400 Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob15.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r6A2uf5G019627 for ; Tue, 9 Jul 2013 22:56:41 -0400 Received: (qmail 4575 invoked by uid 0); 10 Jul 2013 02:56:41 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.133?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 10 Jul 2013 02:56:41 -0000 Message-ID: <51DCCD64.2050405@mti-systems.com> Date: Tue, 09 Jul 2013 22:56:36 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Cullen Jennings References: <32AE7F11-A06E-40C1-A73C-5C69F252DAF9@iii.ca> In-Reply-To: <32AE7F11-A06E-40C1-A73C-5C69F252DAF9@iii.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: DAN DRUTA , tsvwg@ietf.org Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 02:56:54 -0000 On 7/8/2013 7:35 PM, Cullen Jennings wrote: > > The draft-dhesikan-tsvwg-rtcweb-qos draft was discussed extensively when it was an individual draft then WG draft in another WG and I don't think there is much more to say about it. This is one of the normative dependencies of the webrtc work and that stuff is already getting implemented in browsers so I want to move this along in an expedient fashion. Without checking ... it makes no sense to me that there would be a normative dependency on this since it does not impact the interoperability or correctness of an implementation. It's purely a performance enhancement, if/when it actually causes the intended things to happen in the network. That said, I think the interesting facet of this document is that packets within the same flow (defined by 5-tuple of address-port pairs and protocol number) are receiving different codepoints, and the implications of that for a CC that may be on top of them need to be delved into. There isn't really text or recommendations going into that, which seems to be the important part, as if you can figure that out, these mappings are the more obvious part. So, I think it might make sense to do this, but the current document isn't addressing the implications or how this works in a bigger system sense, and I don't think the particular marking tables are the hard or important part. -- Wes Eddy MTI Systems From gorry@erg.abdn.ac.uk Wed Jul 10 00:11:35 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EC921F9E94 for ; Wed, 10 Jul 2013 00:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.531 X-Spam-Level: X-Spam-Status: No, score=-106.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyWp-FUF2FRO for ; Wed, 10 Jul 2013 00:11:31 -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 0B5BB21F9ED1 for ; Wed, 10 Jul 2013 00:11:30 -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 AD4C82B44BA; Wed, 10 Jul 2013 08:11:28 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 10 Jul 2013 08:11:28 +0100 Message-ID: <6a07edb299e0c8ed434052dfe1091a96.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828048B0814@xmb-aln-x08.cisco.com> References: <63962533299aeee4ae03283e9e9b6b0e.squirrel@www.erg.abdn.ac.uk> <92B7E61ADAC1BB4F941F943788C08828048B0814@xmb-aln-x08.cisco.com> Date: Wed, 10 Jul 2013 08:11:28 +0100 From: gorry@erg.abdn.ac.uk To: "Charles Eckel (eckelcu)" 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 Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" Subject: Re: [tsvwg] Preliminary TSVWG Agenda X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 07:11:35 -0000 I updated the reading list on the Agenda page. We'll issue a revised Agenda with the final allocations. Gorry > Hi Chairs, > > Here are links to the two missing drafts identified in the draft agenda. > > http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encoding-00 > http://tools.ietf.org/html/draft-zamfir-tsvwg-flow-metadata-rsvp-00 > > I will forward the corresponding draft announcements as well. > We appreciate any comments on the drafts and hope to have some time to > present them at IETF 87. > The overall framework of which these drafts are a part is provided by: > http://tools.ietf.org/html/draft-eckert-intarea-flow-metadata-framework-00 > > Cheers, > Charles > >> -----Original Message----- >> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf >> Of >> gorry@erg.abdn.ac.uk >> Sent: Tuesday, July 09, 2013 6:31 AM >> To: tsvwg@ietf.org >> Subject: [tsvwg] Preliminary TSVWG Agenda >> >> Here is a link to the draft agenda - this is preliminary, we have still >> to >> schedule some talks and we may yet adjust this agenda. >> >> http://tools.ietf.org/wg/tsvwg/agenda?item=agenda-87-tsvwg.html >> >> Let us know of corrections, conflicts or omissions. >> >> Gorry, David and James >> (TSVWG Co-Chairs) > From hadi@mojatatu.com Tue Jul 9 18:22:59 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2ED11E80DF for ; Tue, 9 Jul 2013 18:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.93 X-Spam-Level: X-Spam-Status: No, score=-102.93 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhXXpkBnOqXz for ; Tue, 9 Jul 2013 18:22:54 -0700 (PDT) Received: from mail-bk0-f46.google.com (mail-bk0-f46.google.com [209.85.214.46]) by ietfa.amsl.com (Postfix) with ESMTP id AFCFD21F9BD4 for ; Tue, 9 Jul 2013 18:22:53 -0700 (PDT) Received: by mail-bk0-f46.google.com with SMTP id na10so2594814bkb.33 for ; Tue, 09 Jul 2013 18:22:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=wteH0c4qDRo+VCl0O8Sz6zpwOqsvHMN/v7Q7IUetMtk=; b=ETOk6ZIo6V2zsRLfhurFrcn99lUqXenNAPfPcUTy+llt0mrrpKIxBfOcCkJJyB/PFI tH2ab2b3qE8ASwFA+AEFW1l8j9+yCG8S2QZdohzGQyr/ldwhsajg7QqvpKTqCeFk88gP /cyTQ8x2R2+5uB51wYSHAtV7STv5ILRa5hhqAQez9+Vs78X59ti/qCeiCcQaD+o+ZVae /PSdtgsrgZ3joDTq0SNAEAu56LGmRcSqcavoWNdbDjDS5s7an4A+amY9hAnmHISx690k ioDoO5vE+2sNAzDLK0PiSrd2Yiyuxtim6GMBE332jgzZyLR+fFU3aFi4ofC59eCf/Iph ykTQ== X-Received: by 10.205.34.14 with SMTP id sq14mr4619772bkb.100.1373419372499; Tue, 09 Jul 2013 18:22:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.2.135 with HTTP; Tue, 9 Jul 2013 18:22:32 -0700 (PDT) From: Jamal Hadi Salim Date: Tue, 9 Jul 2013 21:22:32 -0400 Message-ID: To: tsvwg@ietf.org, Salvatore.Loreto@ericsson.com, robin.seggelmann@t-systems.com, randall@lakerest.net, Michael Tuexen Content-Type: multipart/alternative; boundary=bcaec51a7c7ad39e5a04e11e1dc5 X-Gm-Message-State: ALoCoQlzB7u6P3p7flohkqkZwABW1uGg2ld2deq1Yllsc6ssJmP8xf0qDu8DIvSlkR2NVi+U+fzj X-Mailman-Approved-At: Wed, 10 Jul 2013 00:16:20 -0700 Subject: [tsvwg] comments draft-tuexen-tsvwg-sctp-prpolicies-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 01:22:59 -0000 --bcaec51a7c7ad39e5a04e11e1dc5 Content-Type: text/plain; charset=ISO-8859-1 Hi, Looks good. I have an unrelated question since a mention occurs in the sprstat_abandoned_sent stats): does it make sense to abandon a message that is partially sent? At the receiver, I am assuming if such a partial message was to make it, partial delivery will be made to the socket user? cheers, jamal --bcaec51a7c7ad39e5a04e11e1dc5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

Looks good.=A0
=
I have an unrelated question since a mention occurs in the sprstat_aba= ndoned_sent stats):=A0
does it make sense to abandon a message th= at is partially sent? At the receiver, I am
assuming if such a =A0partial message was to make it, partial delivery= will be made to
the socket user?


cheers,
jamal


--bcaec51a7c7ad39e5a04e11e1dc5-- From tuexen@fh-muenster.de Wed Jul 10 00:42:27 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172F721F9DE3 for ; Wed, 10 Jul 2013 00:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlXRvyCqHA00 for ; Wed, 10 Jul 2013 00:42:26 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 86B1221F9D2A for ; Wed, 10 Jul 2013 00:42:23 -0700 (PDT) Received: from [192.168.1.101] (p5481B3B6.dip0.t-ipconnect.de [84.129.179.182]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id CB0F11C0C0695; Wed, 10 Jul 2013 09:42:18 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Tuexen In-Reply-To: Date: Wed, 10 Jul 2013 09:42:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <27BA1FEC-AE84-412F-8D8A-4857FF283149@fh-muenster.de> References: To: Jamal Hadi Salim X-Mailer: Apple Mail (2.1508) Cc: tsvwg@ietf.org, robin.seggelmann@t-systems.com Subject: Re: [tsvwg] comments draft-tuexen-tsvwg-sctp-prpolicies-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 07:42:27 -0000 On Jul 10, 2013, at 3:22 AM, Jamal Hadi Salim wrote: >=20 > Hi, >=20 > Looks good.=20 > I have an unrelated question since a mention occurs in the = sprstat_abandoned_sent stats):=20 > does it make sense to abandon a message that is partially sent? At the = receiver, I am > assuming if such a partial message was to make it, partial delivery = will be made to > the socket user? Ji Jamal, you have to distinguish between the sender and receiver side. Assume the sender sends a user message which is approximately of size = 3*MTU. So SCTP will fragment it into 3 DATA chunk and send them. If the user has specified that the number of retransmissions is limited to 0 and the last fragment gets lost in the network, the sender will increment sprstat_abandoned_sent. What will happen at the receiver side if you assume that the first two fragments have been received. If partial delivery was started, you will get a SCTP_PARTIAL_DELIVERY_EVENT event indicating = SCTP_PARTIAL_DELIVERY_ABORTED. Without partial delivery being started, the receiver could also drop the first part of the message. Best regards Michael >=20 >=20 > cheers, > jamal >=20 >=20 From Michael.Tuexen@lurchi.franken.de Wed Jul 10 03:44:04 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC7621F9F52 for ; Wed, 10 Jul 2013 03:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJgugloohVk6 for ; Wed, 10 Jul 2013 03:44:04 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 7204B11E811E for ; Wed, 10 Jul 2013 03:42:55 -0700 (PDT) Received: from [192.168.1.101] (p5481BB69.dip0.t-ipconnect.de [84.129.187.105]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id A21B21C0C0692; Wed, 10 Jul 2013 12:42:51 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Tuexen In-Reply-To: Date: Wed, 10 Jul 2013 12:42:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8250D7C2-2DE6-4E8E-9FED-366DD2C1B8E0@lurchi.franken.de> References: <27BA1FEC-AE84-412F-8D8A-4857FF283149@fh-muenster.de> To: Jamal Hadi Salim X-Mailer: Apple Mail (2.1508) Cc: tsvwg , "robin.seggelmann" Subject: Re: [tsvwg] comments draft-tuexen-tsvwg-sctp-prpolicies-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 10:44:04 -0000 On Jul 10, 2013, at 11:48 AM, Jamal Hadi Salim = wrote: >=20 > Hi Michael, >=20 > On Wed, Jul 10, 2013 at 3:42 AM, Michael Tuexen = wrote: >=20 > Assume the sender sends a user message which is approximately of size = 3*MTU. > So SCTP will fragment it into 3 DATA chunk and send them. If the user > has specified that the number of retransmissions is limited to 0 and > the last fragment gets lost in the network, the sender will increment > sprstat_abandoned_sent. >=20 > Ok, so the last fragment essentially doesnt get acknowledged before = we=20 > abandon ship. And the other stat indicates we abandoned while we still = had some > sitting locally. Is the intersection of the two (some are sent but not = acked and > some are still sitting locally) implying both stats will be = incremented? I think there is no intersection: Either a fragment has been sent or no fragment has been sent. Depending on this, the corresponding counter has incremented. >=20 > Other than the perceived ambiguity - why do i care to know about the > two types of abandoned messages in a user app? I will have to sum > those two, so why not just give me one stat? Differentiating between unsent and sent makes sense. For unsent you know for sure that the message has not been received by the peer. For sent messages, you don't know (for example, the SACK could have been lost). I'm not giving you one stat because: * if you want only one, adding them is not too hard. * the SCTP_SEND_FAILED_EVENT event gives you also an indication whether the user message was sent or not. This stats is something like a summary. > =20 > BTW: the doc will benefit from such a small description as you gave me > above. OK. I'll add some text. >=20 > What will happen at the receiver side if you assume that the first two > fragments have been received. If partial delivery was started, you = will > get a SCTP_PARTIAL_DELIVERY_EVENT event indicating = SCTP_PARTIAL_DELIVERY_ABORTED. > Without partial delivery being started, the receiver could also drop = the > first part of the message. >=20 >=20 > You answered the essence of my question. > Silly follow up: I am assuming that event will come with an EOR? Events should have the MSG_EOR flag set if the buffer provided was large enough. Best regards Michael > To use your example (at receiver): > EPOLLIN, recvmsg chunk1, chunk2, EAGAIN > EPOLLIN, recvmsg SCTP_PARTIAL_DELIVERY_EVENT, EOR >=20 > cheers, > jamal From eckert@cisco.com Wed Jul 10 11:02:34 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A863921F9D50; Wed, 10 Jul 2013 11:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.487 X-Spam-Level: X-Spam-Status: No, score=-10.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHCH52Ixpan8; Wed, 10 Jul 2013 11:02:30 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 39CE921F9DBC; Wed, 10 Jul 2013 11:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4297; q=dns/txt; s=iport; t=1373479350; x=1374688950; h=date:from:to:subject:message-id:mime-version; bh=4Krnakf2c8xhkFVZQbRn1doD4IUXOzkoPjHFhN9iwgA=; b=R8fvfXei5wYryAYq4/WluL2Lv8z2e3SARqJckvk5pxEivA28wqXSNDRz xdH07wdrnQkCDjhhcse4zdm2N1g5GmY8JZHKQQVHbpGfWKxLQExb/wsDH 90+AqnA62aqy6PYvs0IPhSZfBinWfwpPZ/acgoHJrrks+l2MFSTEhm4hs A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAE+g3VGrRDoG/2dsb2JhbABagwkywWyBExZ0giMBAQE+KyAgAQMBAQEJGgQWBTIDBg8SCYgFDbdjj3CDA2wDiSWOMQGBKZAhgViBWRw X-IronPort-AV: E=Sophos;i="4.87,1037,1363132800"; d="scan'208";a="82622009" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 10 Jul 2013 18:01:48 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6AI1lK7023862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jul 2013 18:01:47 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r6AI1lCI001615; Wed, 10 Jul 2013 11:01:47 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r6AI1lVi001614; Wed, 10 Jul 2013 11:01:47 -0700 Date: Wed, 10 Jul 2013 11:01:47 -0700 From: "Toerless Eckert (eckert)" To: tsvwg@ietf.org, rtcweb@ietf.org, rmcat@ietf.org Message-ID: <20130710180147.GA614@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Subject: [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 18:02:34 -0000 When dealing with congestion for real-time datagram (UDP/RTP) based video flows, one idea that we think has shown to provide good value is to intelligently drop in the network preferentially the least important packets within a video flow, for example non-referenced P-frames, because their loss creates the lowest impact to video quality. One of the main concerns raised against such schemes was one of fairness. If flows would start to indicate different priorities for packets in them, how would we be able to avoid that flows would indicate all their packets to be of high priority to shift packet drops to other flows. Or even more importantly: how could we motivate flows to indicate that some of their packets are low priority without them having to fear that they would experience more loss than than flows that don't do this. So, there is one draft that we would like to present (presumably in TSVWG) explaining how we think this problem can be solved: draft-lai-tsvwg-normalizer-00.txt (Actually, this is how we did solve the problem in our implementatin of intelligent dropping, so this is not theoretical). Now granted, the problem of fairness is but one element of building a complete ssytem around the idea of intelligent dropping, so if folks here on the lists would like to see for example a) how well can it work in routers to shift packet drops to low-prio packets b) whats the evidence that it's good for video quality c) How should we do the marking best going forward Then please let us know. We'd be very interested to provide insight into the parts of those pieces that we have also worked out or discuss the ones we have not (primarily c ;-) Thanks! Toerless In-Reply-To: On Sat, Feb 09, 2013 at 03:00:48AM +0000, Cheng-Jia Lai (chelai) wrote: > Hi all, > > We have submitted a new Internet draft to describe a Normalization Marker (NM) for DiffServ AF PHB groups, based on our work at Cisco. The goal of NM deployment is to create a new incentive for video encoders to generate more discardable packets when using AF PHB in DIffServ. We are looking forward to your review comments. > > Best regards, > CJ > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, February 08, 2013 6:25 PM > To: Cheng-Jia Lai (chelai) > Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (eckert); Fred Yip (fyip) > Subject: New Version Notification for draft-lai-tsvwg-normalizer-00.txt > > > A new version of I-D, draft-lai-tsvwg-normalizer-00.txt > has been successfully submitted by Cheng-Jia Lai and posted to the > IETF repository. > > Filename: draft-lai-tsvwg-normalizer > Revision: 00 > Title: Normalization Marker for AF PHB Group in DiffServ > Creation date: 2013-02-08 > WG ID: Individual Submission > Number of pages: 15 > URL: http://www.ietf.org/internet-drafts/draft-lai-tsvwg-normalizer-00.txt > Status: http://datatracker.ietf.org/doc/draft-lai-tsvwg-normalizer > Htmlized: http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-00 > > > Abstract: > This memo describes a Normalization Marker (NM) at DiffServ (DS) > nodes to normalize the distribution of DS codepoint (DSCP) markings > for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM is > useful for traffic conditioning with Active Queue Management (AQM) > when the AF PHB group is deployed for multimedia service classes that > carry video packets with advanced codec technologies. Using NM can > offer an incentive that is however missing in today's ecosystem of > practical deployment, i.e., when congestion occurs in the AF PHB > group, the network should allow a video codec to benefit from its > effort of generating finer layers of intra-flow precedence (IFP) with > discardable packets in a more balanced distribution. > > > > > The IETF Secretariat > -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From dave.taht@gmail.com Wed Jul 10 12:03:08 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB3011E811D; Wed, 10 Jul 2013 12:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dj2XaG2g3PCb; Wed, 10 Jul 2013 12:03:05 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1886621F8445; Wed, 10 Jul 2013 12:02:27 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id e11so16421513iej.1 for ; Wed, 10 Jul 2013 12:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3AlDLwTsx/AR+UkecOj/78vM/vAMlo2qsmB0zV/5P3Y=; b=xlLYEYs2XohMvUWfjsYjDE+k63d6G1E291HK/KTlEdHQk70SdapINQxwYdl7mUenHd /iIAzwZIv/P/c/FsdG1AV9r+DZtllC3zDXj4XfL3NF3AyR2KAEuLChCoJwVdD11XFoc4 VFYVyvg6LfLNcwv4EKrXRLQG27Mn7eM1+vmD1KxUJAvVndz6DBDbibcdg7/z0QxuaJ6c oan4kuvxbIetee9UWg05MEXh4Os9fzSVnGj1fV6wf3f+/Sri5DDWF7R22dAFWApn4vcF 1tLAJo6Om1zBIQYoe0TRUbc83G2btqtWx6JSjH2dS6kgmNBmYsi43eR9Kvf2k9SSiEVN 6Zsg== MIME-Version: 1.0 X-Received: by 10.42.133.66 with SMTP id g2mr10511733ict.49.1373482946633; Wed, 10 Jul 2013 12:02:26 -0700 (PDT) Received: by 10.64.98.162 with HTTP; Wed, 10 Jul 2013 12:02:26 -0700 (PDT) In-Reply-To: <20130710180147.GA614@cisco.com> References: <20130710180147.GA614@cisco.com> Date: Wed, 10 Jul 2013 12:02:26 -0700 Message-ID: From: Dave Taht To: "Toerless Eckert (eckert)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rmcat@ietf.org, rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 19:03:08 -0000 On Wed, Jul 10, 2013 at 11:01 AM, Toerless Eckert (eckert) wrote: > When dealing with congestion for real-time datagram (UDP/RTP) based video= flows, one idea > that we think has shown to provide good value is to intelligently drop in= the network > preferentially the least important packets within a video flow, for examp= le non-referenced > P-frames, because their loss creates the lowest impact to video quality. I've begun to look at webrtc of late in the context of fq_codel. One thing that might work would be ECN marking important frames and not ECN marking others. Problem overall is that ecn can be gamed and is largely not enabled, and so on... > One of the main concerns raised against such schemes was one of fairness.= If flows > would start to indicate different priorities for packets in them, how wou= ld we > be able to avoid that flows would indicate all their packets to be of hig= h priority > to shift packet drops to other flows. Or even more importantly: how could= we motivate > flows to indicate that some of their packets are low priority without the= m having to > fear that they would experience more loss than than flows that don't do t= his. same gaming problem... > So, there is one draft that we would like to present (presumably in TSVWG= ) explaining > how we think this problem can be solved: draft-lai-tsvwg-normalizer-00.tx= t > > (Actually, this is how we did solve the problem in our implementatin of i= ntelligent dropping, > so this is not theoretical). In the case of the fq_codel algorithm I can see a "delayed drop" mechanism happening, where upon deciding to drop, it could defer a drop up to a few packets based on the classification of the packet, say 3 packets at most. Since flows are already identified, this is kind of easy by adding another state variable... At the moment what I have deployed and tested most is a simple 3 tier fq_codel based shaper, which has a priority, best effort, and background queue. The priority queue is generally only DNS traffic, the background is only CS1, and fq_codel does such a good job with sparse streams in the general case that for VOIP, etc on the networks I fiddle with, there is no point in having much more than the BE queue. And presently all other markings are ignored. video is another story. (or could be, I don't know enough about webrtc's behaviors to "see" what will happen) So I can see trying to utilize the AF markings as you describe in your draft in codel's drop decision. While this is also subject to being gamed, the disincentives are slight. This is a little different from using "drop probability" as the decider, however, but I would hope that this mapping of the old AF style random drop ideas into the new style delay ideas could work... And what codel depends on is a definition of "TCP friendly". That if a stream is not going to behave in a tcp friendly manner, then an entirely different strategy for such flows seems necessary, and glomming on some additional state isn't going to be the right thing. > Now granted, the problem of fairness is but one element of building a com= plete ssytem > around the idea of intelligent dropping, so if folks here on the lists wo= uld like to > see for example > > a) how well can it work in routers to shift packet drops to low-prio pa= ckets I guess where I fall apart here is how to shift the encoders to send thinne= r streams at any level of packet drop. > b) whats the evidence that it's good for video quality > c) How should we do the marking best going forward > Then please let us know. We'd be very interested to provide insight into = the parts of > those pieces that we have also worked out or discuss the ones we have not= (primarily c ;-) I'd be interested in specific codecs, example video streams, and test scripts to try and fiddle with this, as well as viable metrics. > > Thanks! > Toerless > > In-Reply-To: > > On Sat, Feb 09, 2013 at 03:00:48AM +0000, Cheng-Jia Lai (chelai) wrote: >> Hi all, >> >> We have submitted a new Internet draft to describe a Normalization Marke= r (NM) for DiffServ AF PHB groups, based on our work at Cisco. The goal of = NM deployment is to create a new incentive for video encoders to generate m= ore discardable packets when using AF PHB in DIffServ. We are looking forwa= rd to your review comments. >> >> Best regards, >> CJ >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Friday, February 08, 2013 6:25 PM >> To: Cheng-Jia Lai (chelai) >> Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (eckert= ); Fred Yip (fyip) >> Subject: New Version Notification for draft-lai-tsvwg-normalizer-00.txt >> >> >> A new version of I-D, draft-lai-tsvwg-normalizer-00.txt >> has been successfully submitted by Cheng-Jia Lai and posted to the >> IETF repository. >> >> Filename: draft-lai-tsvwg-normalizer >> Revision: 00 >> Title: Normalization Marker for AF PHB Group in DiffServ >> Creation date: 2013-02-08 >> WG ID: Individual Submission >> Number of pages: 15 >> URL: http://www.ietf.org/internet-drafts/draft-lai-tsvwg-nor= malizer-00.txt >> Status: http://datatracker.ietf.org/doc/draft-lai-tsvwg-normali= zer >> Htmlized: http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-0= 0 >> >> >> Abstract: >> This memo describes a Normalization Marker (NM) at DiffServ (DS) >> nodes to normalize the distribution of DS codepoint (DSCP) markings >> for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM is >> useful for traffic conditioning with Active Queue Management (AQM) >> when the AF PHB group is deployed for multimedia service classes that >> carry video packets with advanced codec technologies. Using NM can >> offer an incentive that is however missing in today's ecosystem of >> practical deployment, i.e., when congestion occurs in the AF PHB >> group, the network should allow a video codec to benefit from its >> effort of generating finer layers of intra-flow precedence (IFP) with >> discardable packets in a more balanced distribution. >> >> >> >> >> The IETF Secretariat >> > > -- > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From chelai@cisco.com Wed Jul 10 16:43:00 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D04D11E814E; Wed, 10 Jul 2013 16:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYnkvpgVEuWp; Wed, 10 Jul 2013 16:42:56 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEB121F9B38; Wed, 10 Jul 2013 16:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8199; q=dns/txt; s=iport; t=1373499775; x=1374709375; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JD1mJnu2lnchGEMAxov2z+JrzktK+Y27xua2GBg46/Y=; b=g4C/OCFf3raKEiTQ04BzB1ks6Jnar3d59EIWMZsGaO6NbD4+fSzC/qZF jSQduEJqhNe1IW6ovcndB0AjabDx6N3HzRK8bXU+d2InvDf9N6R3p/YOm UfL7I6V8K7dx5aF5bA6ajFrU2ZPGwlDc1u8u4nXjd8noXG2gEB4tbUDE8 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAOXw3VGtJV2b/2dsb2JhbABagwkyTcEngQ4WdIIjAQEBAQIBZRQFBwQCAQgRAQMBAQEKAhcEBzIUAwYIAgQBDQEECAGIAAYMt16PMgYrAgUGgwNsA4hvkBSQIYFYgTmCKA X-IronPort-AV: E=Sophos;i="4.87,1039,1363132800"; d="scan'208";a="233346935" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 10 Jul 2013 23:42:54 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6ANgr0q016324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Jul 2013 23:42:53 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.51]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Wed, 10 Jul 2013 18:42:53 -0500 From: "Cheng-Jia Lai (chelai)" To: Dave Taht , "Toerless Eckert (eckert)" Thread-Topic: [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) Thread-Index: AQHOfaBDTO2Q2/ChiUO6fKWGKHceJZleig/Q Date: Wed, 10 Jul 2013 23:42:52 +0000 Message-ID: References: <20130710180147.GA614@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.161.170] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rmcat@ietf.org" , "rtcweb@ietf.org" , "tsvwg@ietf.org" , "aqm@ietf.org" Subject: Re: [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 23:43:00 -0000 Yes, NM could also work with ECN (and it should be made so). In fact, we di= d implementation using WRED on routers that support ECN markings. If RTP en= dpoints support ECN markings, WRED will mark ECN instead of dropping the pa= ckets as avg Q size is between min & max threshold. But it still suffers fr= om unfairness at congestion, where the avg Q size starts to exceed the max = threshold for the lowest priority packet class... We did experience a hard time trying to properly configure WRED parameters = for preferential dropping of video packets with our NM implementation... It= is a good insight you said here: maybe it is worth exploring how our work = can perhaps use other AQM algorithms like CoDel, PIE, etc. In fact, NM doesn't need specific AQM to drop by probabilities... it will b= e interesting to see how it can work with delay-based dropping. However, NM= does require some "weighted" version of those AQMs. Hopefully a weighted v= ersion (if any) won't introduce new parameters (or too many) to configure t= he AQM. Regards, CJ -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of D= ave Taht Sent: Wednesday, July 10, 2013 12:02 PM To: Toerless Eckert (eckert) Cc: rmcat@ietf.org; rtcweb@ietf.org; tsvwg@ietf.org Subject: Re: [tsvwg] Using intelligent dropping to improve video quality un= der congestion (draft-lai-tsvwg-normalizer-00.txt) On Wed, Jul 10, 2013 at 11:01 AM, Toerless Eckert (eckert) wrote: > When dealing with congestion for real-time datagram (UDP/RTP) based video= flows, one idea > that we think has shown to provide good value is to intelligently drop in= the network > preferentially the least important packets within a video flow, for examp= le non-referenced > P-frames, because their loss creates the lowest impact to video quality. I've begun to look at webrtc of late in the context of fq_codel. One thing that might work would be ECN marking important frames and not ECN marking others. Problem overall is that ecn can be gamed and is largely not enabled, and so on... > One of the main concerns raised against such schemes was one of fairness.= If flows > would start to indicate different priorities for packets in them, how wou= ld we > be able to avoid that flows would indicate all their packets to be of hig= h priority > to shift packet drops to other flows. Or even more importantly: how could= we motivate > flows to indicate that some of their packets are low priority without the= m having to > fear that they would experience more loss than than flows that don't do t= his. same gaming problem... > So, there is one draft that we would like to present (presumably in TSVWG= ) explaining > how we think this problem can be solved: draft-lai-tsvwg-normalizer-00.tx= t > > (Actually, this is how we did solve the problem in our implementatin of i= ntelligent dropping, > so this is not theoretical). In the case of the fq_codel algorithm I can see a "delayed drop" mechanism happening, where upon deciding to drop, it could defer a drop up to a few packets based on the classification of the packet, say 3 packets at most. Since flows are already identified, this is kind of easy by adding another state variable... At the moment what I have deployed and tested most is a simple 3 tier fq_codel based shaper, which has a priority, best effort, and background queue. The priority queue is generally only DNS traffic, the background is only CS1, and fq_codel does such a good job with sparse streams in the general case that for VOIP, etc on the networks I fiddle with, there is no point in having much more than the BE queue. And presently all other markings are ignored. video is another story. (or could be, I don't know enough about webrtc's behaviors to "see" what will happen) So I can see trying to utilize the AF markings as you describe in your draft in codel's drop decision. While this is also subject to being gamed, the disincentives are slight. This is a little different from using "drop probability" as the decider, however, but I would hope that this mapping of the old AF style random drop ideas into the new style delay ideas could work... And what codel depends on is a definition of "TCP friendly". That if a stream is not going to behave in a tcp friendly manner, then an entirely different strategy for such flows seems necessary, and glomming on some additional state isn't going to be the right thing. > Now granted, the problem of fairness is but one element of building a com= plete ssytem > around the idea of intelligent dropping, so if folks here on the lists wo= uld like to > see for example > > a) how well can it work in routers to shift packet drops to low-prio pa= ckets I guess where I fall apart here is how to shift the encoders to send thinne= r streams at any level of packet drop. > b) whats the evidence that it's good for video quality > c) How should we do the marking best going forward > Then please let us know. We'd be very interested to provide insight into = the parts of > those pieces that we have also worked out or discuss the ones we have not= (primarily c ;-) I'd be interested in specific codecs, example video streams, and test scripts to try and fiddle with this, as well as viable metrics. > > Thanks! > Toerless > > In-Reply-To: > > On Sat, Feb 09, 2013 at 03:00:48AM +0000, Cheng-Jia Lai (chelai) wrote: >> Hi all, >> >> We have submitted a new Internet draft to describe a Normalization Marke= r (NM) for DiffServ AF PHB groups, based on our work at Cisco. The goal of = NM deployment is to create a new incentive for video encoders to generate m= ore discardable packets when using AF PHB in DIffServ. We are looking forwa= rd to your review comments. >> >> Best regards, >> CJ >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Friday, February 08, 2013 6:25 PM >> To: Cheng-Jia Lai (chelai) >> Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (eckert= ); Fred Yip (fyip) >> Subject: New Version Notification for draft-lai-tsvwg-normalizer-00.txt >> >> >> A new version of I-D, draft-lai-tsvwg-normalizer-00.txt >> has been successfully submitted by Cheng-Jia Lai and posted to the >> IETF repository. >> >> Filename: draft-lai-tsvwg-normalizer >> Revision: 00 >> Title: Normalization Marker for AF PHB Group in DiffServ >> Creation date: 2013-02-08 >> WG ID: Individual Submission >> Number of pages: 15 >> URL: http://www.ietf.org/internet-drafts/draft-lai-tsvwg-nor= malizer-00.txt >> Status: http://datatracker.ietf.org/doc/draft-lai-tsvwg-normali= zer >> Htmlized: http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-0= 0 >> >> >> Abstract: >> This memo describes a Normalization Marker (NM) at DiffServ (DS) >> nodes to normalize the distribution of DS codepoint (DSCP) markings >> for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM is >> useful for traffic conditioning with Active Queue Management (AQM) >> when the AF PHB group is deployed for multimedia service classes that >> carry video packets with advanced codec technologies. Using NM can >> offer an incentive that is however missing in today's ecosystem of >> practical deployment, i.e., when congestion occurs in the AF PHB >> group, the network should allow a video codec to benefit from its >> effort of generating finer layers of intra-flow precedence (IFP) with >> discardable packets in a more balanced distribution. >> >> >> >> >> The IETF Secretariat >> > > -- > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From eckert@cisco.com Wed Jul 10 18:00:36 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0CD21F9983 for ; Wed, 10 Jul 2013 18:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.198 X-Spam-Level: X-Spam-Status: No, score=-10.198 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4kFkCZidGAS for ; Wed, 10 Jul 2013 18:00:30 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8B08121F9CAB for ; Wed, 10 Jul 2013 18:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6638; q=dns/txt; s=iport; t=1373504423; x=1374714023; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=LuTy504PBpHZjYVy5sYnvfWaMRvn0nJSVv4cMbUS3Yg=; b=JD/V6cSpwHs9O0Glv2ltXL7KPyRGf7z+gciyq2I5ek/zQQXtA52fgU1Y 0P1nEOumlby+gv93xFm1xEuUqzImBhylm5zZaBJVdeFiSvBT/2+1oDLE0 i716fzl7r4NLj+YkT/z6rPW+mM0Nr0DDuXeMsjWQdhepKddUMixw6xGui I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAOkC3lGrRDoH/2dsb2JhbABaDoJ7wiOBDxZ0giMBAQEBAzoyCgMQCxIGCSUPBTUUExuHc7dMjiEKgTgHgwlsA4knjjIBkUqCU14cgSwJFw X-IronPort-AV: E=Sophos;i="4.87,1040,1363132800"; d="scan'208";a="82644194" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 11 Jul 2013 01:00:20 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6B10J4H010418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jul 2013 01:00:19 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r6B10IoK023701; Wed, 10 Jul 2013 18:00:18 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r6B10HTo023699; Wed, 10 Jul 2013 18:00:17 -0700 Date: Wed, 10 Jul 2013 18:00:17 -0700 From: Toerless Eckert To: Gorry Fairhurst Message-ID: <20130711010017.GA20860@cisco.com> References: <51DA80B5.7060008@erg.abdn.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51DA80B5.7060008@erg.abdn.ac.uk> User-Agent: Mutt/1.4.2.2i Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Some comments on draft-shepherd-multicast-udp-guidelines-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 01:00:36 -0000 Not wanting to speak for Greg, but i think the reason for the document is to summarize that IP multicast traffic can pefectly well comply with Internet congestion control requirements, and that there are a bunch of documents that explain how. I have no strong opinion on the process, so 5405 could be normative or informational, i guess personally speaking i'd certainly hope that its clear that ALC based rate control is in general better than sender-rate control for Internet multicast, so everything worked out by RMT and referred to by Gregs doc would in general superceed the unicast centric 5405. That's how i would read those documents and resolve conflicts between them. Cheers Toerless On Mon, Jul 08, 2013 at 10:04:53AM +0100, Gorry Fairhurst wrote: > > Greg, > > I like the idea of publishing something on the topic in this draft, and > think this a valuable addition to what is said in RFC 5405. It's not > that multicast is hard - it's just slightly different. > > However I do see the need for additional/different congestion control > requirements for multicast. Was that the intention, and that the basic > guidance for using UDP in RFC 5405 also applies? - I'd have expected > that RFC 5405 is normatively cited as a list of basic UDP requirements? > > This email was as a TSVWG contributor, I'm interested in multicast > transport/infrastructure (not as a WG Chair). > > Gorry > > > --- > > Introduction: > I suspect any advice also applies to use of UDP-Lite with multicast? > > --- > > At the end of section 2.1 I see the assertion here that multicast > tunnels should not be congestion-controlled, making this the > responsibility of applications that use the tunnels. > > While I can see this has been the case with traditional tunnels, the key > question that needs to be thought about here (I think raised by Magnus?) > is whether this is right also for automatic multicast tunnels - or > whether a circuit-breaker approach, as discussed for example with PW3E, > is more appropriate. > > I'm not sure if the IETF should simply ignore protocols designed for > "private" well-managed networks. For unicast, such traffic now > frequently traverses VPNs and tunnels via the general Internet. Good > advice is important, although we may of course be unable to place > "requirements". > > As above for both unicast and multicast, I think the issue here is that > if the "private" traffic is not CC'ed then the tunnels between private > networks do not use CC. This then means that we need to think about how > to protect the unicast CC traffic from this impact. Is this a network > operational responsibility (e.g. alarms and rate limits) or a transport > responsibility (e.g. circuit-breakers and CC)? > > As I recall, the aggregate multicast tunnel traffic may be argued to > result in a significant proportion of the internet traffic through a > home gateway. This question therefore seems relevant to various drafts > including: AMT and draft-ietf-pwe3-p2mp-pw-requirements-02.txt !!! > > --- > > The multicast congestion control space faces similar challenges to the > multicast reliability space. > > I think the solution space is slightly bigger than the present draft > says. To me, the key issue with Multicast in the General Internet is > that there are (at least) three fundamental differences: > > * The multicast tree is often not heterogeneous - this implies there may > be a wide range of path characteristics. This has implications on the > methods used for RMT e.g. in 3.1 of RFC 5405, it says many applications > "cannot maintain a reliable RTT estimate for a destination". This often > applies to the set of destinations in an RMT session or a multicast RTP > session. > > * The heterogeneity also means that some receivers may be receiving > significantly more loss than the rest of the group. In talks on > multicast I've called these "crying babies" (by which I mean recipients > that can gain the attention of the sender and may need special care). It > seems to me that many multicast apps try to exclude these from the group > - e.g. start a unicast session to this particular endpoint, or simply > don't distribute a security key to these receivers. > > * Any receiver *anywhere* can potentially try to receive any group. > That's not a transport problem. It may imply the need for rate limits on > the aggregate multicast service, but there is no way at the transport > layer to stop a join message propagating to the next hop router. It also > points to the need for multicast operators to monitor their > infrastructure (which we do, and I'm sure others do - since specific > multicast transport issues can only be debugged when you understand the > health of the underlying network infrastructure). > > While all this may initially seem problematic, the overall goal of > multicast is for users to get useful data. This implies there is an > incentive for apps to not to do silly things that will render their > service useless. > > --- > > Effective MTU: I saw Lars' comment on path MTU discovery (relating to > 3.2 of RFC 5405) - somehow this needs to be combined with the 1200 byte > rule of thumb that many of us have been using for multicast for years. > > I recall some multicast deployments shying away from using PMTUD because > it was hard to protect the infrastructure when there was no specific > destination endpoint. Hence this was a DoS vulnerability. (Just because > a receiver can see a packet from a multicast tree doesn't mean it should > be allowed to drive-down the sender MTU to a trivial value). Could the > draft explain whether this is an issue or non-issue? > > --- > > Security > > See above on the responsibility for sharing the limited capacity > available in a typical home gateway. > > One of the great things about multicast is RPF checks - a great way to > protect from some DOS attacks. RPF checks in multicast REALLY help to > make this manageable! > > IPsec and other security mechanisms work with multicast - but they need > multicast key management techniques. > > Maybe the draft should say something about firewalls - pointing them to > support multicast! > > --- > > NITS > > I suspect you do not need to cite this? > [I-D.narten-iana-considerations-rfc2434bis]. > -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From jsaldana@unizar.es Thu Jul 11 02:19:24 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F6521F9F58; Thu, 11 Jul 2013 02:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.313 X-Spam-Level: X-Spam-Status: No, score=-6.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTWdOpxxTf-b; Thu, 11 Jul 2013 02:19:19 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id E758C21F9EFE; Thu, 11 Jul 2013 02:19:18 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r6B9JE4o010082; Thu, 11 Jul 2013 11:19:14 +0200 From: "Jose Saldana" To: Date: Thu, 11 Jul 2013 11:19:16 +0200 Organization: Universidad de Zaragoza Message-ID: <003f01ce7e17$b7c80650$275812f0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5+F6MX4jDUXY/OS0Cr+ea+zD8mig== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tcmtf@ietf.org, tsv-area@ietf.org, tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-saldana-tsvwg-tcmtf-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 09:19:24 -0000 A new version of I-D, draft-saldana-tsvwg-tcmtf-05.txt has been successfully submitted by Jose Saldana and posted to the IETF repository. Filename: draft-saldana-tsvwg-tcmtf Revision: 05 Title: Tunneling Compressed Multiplexed Traffic Flows (TCM-TF) Creation date: 2013-07-11 Group: Individual Submission Number of pages: 21 URL: http://www.ietf.org/internet-drafts/draft-saldana-tsvwg-tcmtf-05.txt Status: http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf Htmlized: http://tools.ietf.org/html/draft-saldana-tsvwg-tcmtf-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-saldana-tsvwg-tcmtf-05 Abstract: Tunneling Compressed and Multiplexed Traffic Flows (TCM-TF) is a method for improving the bandwidth utilization of network segments that carry multiple flows in parallel sharing a common path. The method combines standard protocols for header compression, multiplexing, and tunneling over a network path for the purpose of reducing the bandwidth used when multiple flows are carried over that path. The amount of packets per second can also be reduced. This document describes the TCM-TF framework and the different options which can be used for each layer (header compression, multiplexing and tunneling). The IETF Secretariat From Martin.Stiemerling@neclab.eu Thu Jul 11 03:23:52 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D4721F9F5C for ; Thu, 11 Jul 2013 03:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.47 X-Spam-Level: X-Spam-Status: No, score=-103.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v74Nh0gq4+ez for ; Thu, 11 Jul 2013 03:23:48 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id A0B0721F9F59 for ; Thu, 11 Jul 2013 03:23:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 7E2EC104A62; Thu, 11 Jul 2013 12:23:12 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlQHCgPhjzmk; Thu, 11 Jul 2013 12:23:12 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 4CEA8104A59; Thu, 11 Jul 2013 12:22:27 +0200 (CEST) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 11 Jul 2013 12:23:00 +0200 Message-ID: <51DE8784.7000406@neclab.eu> Date: Thu, 11 Jul 2013 12:23:00 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Black, David" , Mirja Kuehlewind References: <20130604133009.5CF5EB1E003@rfc-editor.org> <8D3D17ACE214DC429325B2B98F3AE712980C9B6E@MX15A.corp.emc.com> <201306041621.58362.mirja.kuehlewind@ikr.uni-stuttgart.de> <8D3D17ACE214DC429325B2B98F3AE712980C9C7F@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712980C9C7F@MX15A.corp.emc.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.1.1.190] Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" , "floyd@aciri.org" , "kk@teraoptic.com" , "jmpolk@cisco.com" , RFC Errata System Subject: Re: [tsvwg] [Editorial Errata Reported] RFC3168 (3636) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 10:23:52 -0000 Hi all, On 06/04/2013 09:00 PM, Black, David wrote: > For more context, here's the entire paragraph that contains the sentence > in question: > > 6.1.1 TCP Initialization > > In the TCP connection setup phase, the source and destination TCPs > exchange information about their willingness to use ECN. Subsequent > to the completion of this negotiation, the TCP sender sets an ECT > codepoint in the IP header of data packets to indicate to the network > that the transport is capable and willing to participate in ECN for > this packet. This indicates to the routers that they may mark this > packet with the CE codepoint, if they would like to use that as a > method of congestion notification. If the TCP connection does not > wish to use ECN notification for a particular packet, the sending TCP > sets the ECN codepoint to not-ECT, and the TCP receiver ignores the > CE codepoint in the received packet. > > That's not stating that "an ECN receiver can choose for every received > CE to ignore it" - rather (at least as I read the text), it's stating that > for a small specific fraction of the packets ("particular") the sender and > receiver somehow know or have agreed in advance that ECN is not to be used, > and such packets are sent as not-ECT with CE ignored on receipt. > > This is all rather hypothetical, as I agree with Mirja's underlying sense > that once ECN is enabled on a TCP connection, it SHOULD be used with every > packet. All in all, it may be better to pursue some sort of technical > that as opposed to trying to clean up this text editorially. > > It is dangerous for receivers to ignore CE markings if there is any > possibility that the CE marking was applied as a congestion indication, > and the original sentence can be read as allowing that dangerous behavior. > The simplest way out of this may be to re-classify the errata (which > removes the text that refers to that receiver behavior) as technical, > and proceed from there. I will reject the errata no. 3636. Either Mirja or David, or someone else, should submit a new errata. Process-wise it is the better way forward. Thanks, Martin > > Thanks, > --David > >> -----Original Message----- >> From: Mirja Kuehlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de] >> Sent: Tuesday, June 04, 2013 10:22 AM >> To: Black, David >> Cc: RFC Errata System; kk@teraoptic.com; floyd@aciri.org; >> spencerdawkins.ietf@gmail.com; martin.stiemerling@neclab.eu; >> gorry@erg.abdn.ac.uk; jmpolk@cisco.com; tsvwg@ietf.org >> Subject: Re: [Editorial Errata Reported] RFC3168 (3636) >> >> That means the sentence should say that an ECN receiver can choose for every >> received CE to ignore it? What's the sense behind this? (Maybe this is a >> technical erratum then, as e.g. ECN Nonce was designed to prevent exactly >> this behavior.) >> >> If not, the sentence is still not very clear. Maybe splitting it up into two >> sentences would help: >> >> Original Text >> ------------- >> If the TCP connection does not >> wish to use ECN notification for a particular packet, the sending TCP >> sets the ECN codepoint to not-ECT, and the TCP receiver ignores the >> CE codepoint in the received packet. >> >> Corrected Text >> -------------- >> If the sending TCP does not >> wish to use ECN notification for a particular packet, it >> sets the ECN codepoint to not-ECT. If the TCP receiver independently does >> not wish to use ECN notification for a particular packet, it ignores a CE >> codepoint in the received packet. >> >> >> Mirja >> >> >> On Tuesday 04 June 2013 15:49:48 Black, David wrote: >>> While the basic facts are correct, specifically that the receiver cannot >>> determine whether CE has been erroneously set on a not-ECT-marked packet, >>> I don't think this errata should be applied. >>> >>> The original sentence was intended to refer to independent actions by >>> the sender and receiver, and was not supposed to imply that the receiver >>> would ignore a received CE marking as a consequence of a not-ECT being >>> applied by the sender. >>> >>> The following editorial clarification would improve the text (add >>> "endpoint", and insert the word "independently"): >>> >>> Original Text >>> ------------- >>> If the TCP connection does not >>> wish to use ECN notification for a particular packet, the sending TCP >>> sets the ECN codepoint to not-ECT, and the TCP receiver ignores the >>> CE codepoint in the received packet. >>> >>> Corrected Text >>> -------------- >>> If either endpoint of the TCP connection does not >>> wish to use ECN notification for a particular packet, the sending TCP >>> sets the ECN codepoint to not-ECT, and the TCP receiver independently >>> ignores a CE codepoint in the received packet. >>> >>> Thanks, >>> --David >>> >>>> -----Original Message----- >>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>>> Sent: Tuesday, June 04, 2013 9:30 AM >>>> To: kk@teraoptic.com; floyd@aciri.org; Black, David; >>>> spencerdawkins.ietf@gmail.com; martin.stiemerling@neclab.eu; >>>> gorry@erg.abdn.ac.uk; Black, David; jmpolk@cisco.com >>>> Cc: mirja.kuehlewind@ikr.uni-stuttgart.de; tsvwg@ietf.org; >>>> rfc-editor@rfc- editor.org >>>> Subject: [Editorial Errata Reported] RFC3168 (3636) >>>> >>>> The following errata report has been submitted for RFC3168, >>>> "The Addition of Explicit Congestion Notification (ECN) to IP". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=3168&eid=3636 >>>> >>>> -------------------------------------- >>>> Type: Editorial >>>> Reported by: Mirja Kühlewind >>>> >>>> Section: 6.1.1. >>>> >>>> Original Text >>>> ------------- >>>> If the TCP connection does not >>>> wish to use ECN notification for a particular packet, the sending TCP >>>> sets the ECN codepoint to not-ECT, and the TCP receiver ignores the >>>> CE codepoint in the received packet. >>>> >>>> Corrected Text >>>> -------------- >>>> If the TCP connection does not >>>> wish to use ECN notification for a particular packet, the sending TCP >>>> sets the ECN codepoint to not-ECT. >>>> >>>> Notes >>>> ----- >>>> CE should not be set on not-ECT capable packets. If this happens anyway, >>>> the CE codepoint would overwrite the ECT codepoint. Thus there is no way >>>> for the receiver to know it should ignore the CE codepoint; the sentence >>>> is therefore nonsensical. >>>> >>>> Instructions: >>>> ------------- >>>> This errata is currently posted as "Reported". If necessary, please >>>> use "Reply All" to discuss whether it should be verified or >>>> rejected. When a decision is reached, the verifying party (IESG) >>>> can log in to change the status and edit the report, if necessary. >>>> >>>> -------------------------------------- >>>> RFC3168 (draft-ietf-tsvwg-ecn-04) >>>> -------------------------------------- >>>> Title : The Addition of Explicit Congestion Notification >>>> (ECN) to IP >>>> Publication Date : September 2001 >>>> Author(s) : K. Ramakrishnan, S. Floyd, D. Black >>>> Category : PROPOSED STANDARD >>>> Source : Transport Area Working Group >>>> Area : Transport >>>> Stream : IETF >>>> Verifying Party : IESG >> >> >> >> -- >> ------------------------------------------------------------------- >> Dipl.-Ing. Mirja Kühlewind >> Institute of Communication Networks and Computer Engineering (IKR) >> University of Stuttgart, Germany >> Pfaffenwaldring 47, D-70569 Stuttgart >> >> tel: +49(0)711/685-67973 >> email: mirja.kuehlewind@ikr.uni-stuttgart.de >> web: www.ikr.uni-stuttgart.de >> ------------------------------------------------------------------- > -- martin.stiemerling@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 From carlberg@g11.org.uk Thu Jul 11 09:05:32 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A01921F9C6D; Thu, 11 Jul 2013 09:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pqbv-+O-XZ3S; Thu, 11 Jul 2013 09:05:27 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2916621F9F4C; Thu, 11 Jul 2013 09:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=zZNnM09X3aVQDZwGbcmvuadW1XS1GoF3JpGeUovatK8=; b=h23GCqdPprhQ2OoEgPk6Uiego+EIVZUlpBS/FeyIE/NGNsSe64wCjQRNZgczw5Y3oWqJi8/3jgWMR1XX1qG2llpWqwm5zRlOwOqOr1lT7s9Eaz6qzfK1F0cD7dNIddpq; Received: from c-98-218-170-72.hsd1.va.comcast.net ([98.218.170.72]:37990 helo=[10.0.1.20]) by portland.eukhosting.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UxJMZ-003R6H-4J; Thu, 11 Jul 2013 17:04:59 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: ken carlberg In-Reply-To: <20130710180147.GA614@cisco.com> Date: Thu, 11 Jul 2013 12:04:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <34BE8BE0-E863-4F69-8D45-18F5B97DE392@g11.org.uk> References: <20130710180147.GA614@cisco.com> To: Toerless Eckert (eckert) X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Get-Message-Sender-Via: portland.eukhosting.net: acl_c_relayhosts_text_entry: carlberg@g11.org.uk|g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: rmcat@ietf.org, rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 16:05:32 -0000 Toerless, some food for thought... about 10 years ago, I put together a draft that added an optional TLV = prioritization header to RTP to accomplish something similar in terms of = having the app decide which was the better RTP packet to drop during = times of congestion. My aim was to have these decisions made at = forwarding application-layer gateways that did not act as a RTP/RTCP = endpoint. The strength of the approach (in my opinion :-) was that it = could span pockets of non-diff-serv regions and still carry significance = downstream. The weakness was the need for DPI if one wanted to make a = more informed decision along the path about dropping a packet. I wonder if such a dual-layer design might be helpful in your efforts. = In any case, I have an interest in the normalizer draft. -ken On Jul 10, 2013, at 2:01 PM, Toerless Eckert (eckert) = wrote: > When dealing with congestion for real-time datagram (UDP/RTP) based = video flows, one idea > that we think has shown to provide good value is to intelligently drop = in the network > preferentially the least important packets within a video flow, for = example non-referenced > P-frames, because their loss creates the lowest impact to video = quality. >=20 > One of the main concerns raised against such schemes was one of = fairness. If flows=20 > would start to indicate different priorities for packets in them, how = would we > be able to avoid that flows would indicate all their packets to be of = high priority > to shift packet drops to other flows. Or even more importantly: how = could we motivate > flows to indicate that some of their packets are low priority without = them having to > fear that they would experience more loss than than flows that don't = do this. >=20 > So, there is one draft that we would like to present (presumably in = TSVWG) explaining > how we think this problem can be solved: = draft-lai-tsvwg-normalizer-00.txt >=20 > (Actually, this is how we did solve the problem in our implementatin = of intelligent dropping, > so this is not theoretical). >=20 > Now granted, the problem of fairness is but one element of building a = complete ssytem > around the idea of intelligent dropping, so if folks here on the lists = would like to > see for example=20 >=20 > a) how well can it work in routers to shift packet drops to low-prio = packets > b) whats the evidence that it's good for video quality > c) How should we do the marking best going forward >=20 > Then please let us know. We'd be very interested to provide insight = into the parts of > those pieces that we have also worked out or discuss the ones we have = not (primarily c ;-) >=20 > Thanks! > Toerless >=20 > In-Reply-To: = >=20 > On Sat, Feb 09, 2013 at 03:00:48AM +0000, Cheng-Jia Lai (chelai) = wrote: >> Hi all, >>=20 >> We have submitted a new Internet draft to describe a Normalization = Marker (NM) for DiffServ AF PHB groups, based on our work at Cisco. The = goal of NM deployment is to create a new incentive for video encoders to = generate more discardable packets when using AF PHB in DIffServ. We are = looking forward to your review comments. >>=20 >> Best regards, >> CJ >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 >> Sent: Friday, February 08, 2013 6:25 PM >> To: Cheng-Jia Lai (chelai) >> Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert = (eckert); Fred Yip (fyip) >> Subject: New Version Notification for = draft-lai-tsvwg-normalizer-00.txt >>=20 >>=20 >> A new version of I-D, draft-lai-tsvwg-normalizer-00.txt >> has been successfully submitted by Cheng-Jia Lai and posted to the >> IETF repository. >>=20 >> Filename: draft-lai-tsvwg-normalizer >> Revision: 00 >> Title: Normalization Marker for AF PHB Group in = DiffServ >> Creation date: 2013-02-08 >> WG ID: Individual Submission >> Number of pages: 15 >> URL: = http://www.ietf.org/internet-drafts/draft-lai-tsvwg-normalizer-00.txt >> Status: = http://datatracker.ietf.org/doc/draft-lai-tsvwg-normalizer >> Htmlized: = http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-00 >>=20 >>=20 >> Abstract: >> This memo describes a Normalization Marker (NM) at DiffServ (DS) >> nodes to normalize the distribution of DS codepoint (DSCP) markings >> for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM is >> useful for traffic conditioning with Active Queue Management (AQM) >> when the AF PHB group is deployed for multimedia service classes = that >> carry video packets with advanced codec technologies. Using NM can >> offer an incentive that is however missing in today's ecosystem of >> practical deployment, i.e., when congestion occurs in the AF PHB >> group, the network should allow a video codec to benefit from its >> effort of generating finer layers of intra-flow precedence (IFP) = with >> discardable packets in a more balanced distribution. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >=20 > --=20 > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! >=20 From chelai@cisco.com Thu Jul 11 15:12:53 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64A711E81B8; Thu, 11 Jul 2013 15:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkV7TGImtcal; Thu, 11 Jul 2013 15:12:48 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 878A121F9F71; Thu, 11 Jul 2013 15:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7145; q=dns/txt; s=iport; t=1373580768; x=1374790368; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NUnOPGj7zzwp20P6uiTxzgY1YkvIZDpAnv+QSQYKbiQ=; b=eEwnJIK47h+N2O6rxImHnqu8lXo6APSzs0CINzpwp3jItXvh3omTgvwv cBhkJAk/ho1nyOVMTzPcptmSA/qv0smcJo3IZOfxtruR9sDMKzpCQuj7H lvGm1w7Ch+rmjbemK6wT+Uvdqegz+Asewa4f5oJYVvhYBUvfzym0n2Ynm k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAJYs31GtJV2a/2dsb2JhbABagwY0T8FWgQcWdIIjAQEBAwE6KwIEDgUHBAIBCBEBAwEBAQoUBQQHMhQDBggCBAENBQgBiAAGDLdpjimBBwYrBwaDA2wDmQaQJIFYgTmBaEA X-IronPort-AV: E=Sophos;i="4.89,647,1367971200"; d="scan'208";a="233612568" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 11 Jul 2013 22:12:47 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6BMClOL011042 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Jul 2013 22:12:47 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.51]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 17:12:47 -0500 From: "Cheng-Jia Lai (chelai)" To: ken carlberg , "Toerless Eckert (eckert)" Thread-Topic: [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) Thread-Index: AQHOflB/BP/LxZhvSUuqg6JURoTBKJlgAPVA Date: Thu, 11 Jul 2013 22:12:46 +0000 Message-ID: References: <20130710180147.GA614@cisco.com> <34BE8BE0-E863-4F69-8D45-18F5B97DE392@g11.org.uk> In-Reply-To: <34BE8BE0-E863-4F69-8D45-18F5B97DE392@g11.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.161.170] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rmcat@ietf.org" , "rtcweb@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 22:12:53 -0000 Ken, Thanks very much for the comment and showing an interest in our draft. Yes, I agree it is beneficial if the intra-flow priorities info can be carr= ied in some bit field other than DSCP markings. I guess we need to better c= larify that NM is not necessarily specific to AF PHB but potentially applic= able to other service classes. (In fact, our implementation did try DPI in = RTP and H.264 NAL unit header for that, with some limited overheads in pack= et processing.) We know there can be a lot of intelligent ways to carrying priorities in pa= ckets (e.g. your TLV in RTP hdr) which are likely beyond our knowledge and = expertise, so we just introduced the CB mode in Section 3.1, quoted as foll= ows: "When NM operates in "color-blind" (CB) mode, which is optionally supported, it reads certain bits field(s) other than the AF-markings in the packets to determine the actual drop precedence of that packet. This implies that NM may need DPI in the packets, e.g. parsing into H.264 AVC header in each RTP packets, or alternatively use some method where the drop precedence is carried from the encoder in a customized bits field other than the AF-marking in each packet." CB might not be the best name... sorry if confusing. Anyway, we hope this a= llows NM to collaborate better with video endpoints. Regards, CJ -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of k= en carlberg Sent: Thursday, July 11, 2013 9:05 AM To: Toerless Eckert (eckert) Cc: rmcat@ietf.org; rtcweb@ietf.org; tsvwg@ietf.org Subject: Re: [tsvwg] Using intelligent dropping to improve video quality un= der congestion (draft-lai-tsvwg-normalizer-00.txt) Toerless, some food for thought... about 10 years ago, I put together a draft that added an optional TLV prior= itization header to RTP to accomplish something similar in terms of having = the app decide which was the better RTP packet to drop during times of cong= estion. My aim was to have these decisions made at forwarding application-= layer gateways that did not act as a RTP/RTCP endpoint. The strength of th= e approach (in my opinion :-) was that it could span pockets of non-diff-se= rv regions and still carry significance downstream. The weakness was the n= eed for DPI if one wanted to make a more informed decision along the path a= bout dropping a packet. I wonder if such a dual-layer design might be helpful in your efforts. In = any case, I have an interest in the normalizer draft. -ken On Jul 10, 2013, at 2:01 PM, Toerless Eckert (eckert) wr= ote: > When dealing with congestion for real-time datagram (UDP/RTP) based video= flows, one idea > that we think has shown to provide good value is to intelligently drop in= the network > preferentially the least important packets within a video flow, for examp= le non-referenced > P-frames, because their loss creates the lowest impact to video quality. >=20 > One of the main concerns raised against such schemes was one of fairness.= If flows=20 > would start to indicate different priorities for packets in them, how wou= ld we > be able to avoid that flows would indicate all their packets to be of hig= h priority > to shift packet drops to other flows. Or even more importantly: how could= we motivate > flows to indicate that some of their packets are low priority without the= m having to > fear that they would experience more loss than than flows that don't do t= his. >=20 > So, there is one draft that we would like to present (presumably in TSVWG= ) explaining > how we think this problem can be solved: draft-lai-tsvwg-normalizer-00.tx= t >=20 > (Actually, this is how we did solve the problem in our implementatin of i= ntelligent dropping, > so this is not theoretical). >=20 > Now granted, the problem of fairness is but one element of building a com= plete ssytem > around the idea of intelligent dropping, so if folks here on the lists wo= uld like to > see for example=20 >=20 > a) how well can it work in routers to shift packet drops to low-prio pac= kets > b) whats the evidence that it's good for video quality > c) How should we do the marking best going forward >=20 > Then please let us know. We'd be very interested to provide insight into = the parts of > those pieces that we have also worked out or discuss the ones we have not= (primarily c ;-) >=20 > Thanks! > Toerless >=20 > In-Reply-To: >=20 > On Sat, Feb 09, 2013 at 03:00:48AM +0000, Cheng-Jia Lai (chelai) wrote: >> Hi all, >>=20 >> We have submitted a new Internet draft to describe a Normalization Marke= r (NM) for DiffServ AF PHB groups, based on our work at Cisco. The goal of = NM deployment is to create a new incentive for video encoders to generate m= ore discardable packets when using AF PHB in DIffServ. We are looking forwa= rd to your review comments. >>=20 >> Best regards, >> CJ >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 >> Sent: Friday, February 08, 2013 6:25 PM >> To: Cheng-Jia Lai (chelai) >> Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (eckert= ); Fred Yip (fyip) >> Subject: New Version Notification for draft-lai-tsvwg-normalizer-00.txt >>=20 >>=20 >> A new version of I-D, draft-lai-tsvwg-normalizer-00.txt >> has been successfully submitted by Cheng-Jia Lai and posted to the >> IETF repository. >>=20 >> Filename: draft-lai-tsvwg-normalizer >> Revision: 00 >> Title: Normalization Marker for AF PHB Group in DiffServ >> Creation date: 2013-02-08 >> WG ID: Individual Submission >> Number of pages: 15 >> URL: http://www.ietf.org/internet-drafts/draft-lai-tsvwg-nor= malizer-00.txt >> Status: http://datatracker.ietf.org/doc/draft-lai-tsvwg-normali= zer >> Htmlized: http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-0= 0 >>=20 >>=20 >> Abstract: >> This memo describes a Normalization Marker (NM) at DiffServ (DS) >> nodes to normalize the distribution of DS codepoint (DSCP) markings >> for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM is >> useful for traffic conditioning with Active Queue Management (AQM) >> when the AF PHB group is deployed for multimedia service classes that >> carry video packets with advanced codec technologies. Using NM can >> offer an incentive that is however missing in today's ecosystem of >> practical deployment, i.e., when congestion occurs in the AF PHB >> group, the network should allow a video codec to benefit from its >> effort of generating finer layers of intra-flow precedence (IFP) with >> discardable packets in a more balanced distribution. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >=20 > --=20 > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! >=20 From eckert@cisco.com Thu Jul 11 17:30:11 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B977011E81CD; Thu, 11 Jul 2013 17:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.48 X-Spam-Level: X-Spam-Status: No, score=-10.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuO9b9KJv9uj; Thu, 11 Jul 2013 17:30:07 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF6D11E814B; Thu, 11 Jul 2013 17:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6647; q=dns/txt; s=iport; t=1373589007; x=1374798607; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=sdMEUzGCmqchvnyBL+sbXziVn3KVC7c8kICxgmS5pBo=; b=ZKy66lRG1QCElEDaZyZ+Z1H24LlmRQRqLta9tM2Fr1JdrW+4AdJ44Fbx tJPZf0lf+AK3xh4hjCAwoqRdPofJ+OuPU9Gn3syXdnFCZpq30PCFlmppx 7s5moaYo7yYtS39AOsRIo0MYwCx30Jt+eMi5Ol249P2L1ewtKjscDHP5n s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAKBN31GrRDoI/2dsb2JhbABagwY0wiWBBxZ0giMBAQEEOisUDAQLEQEDAQEBCRoEBw8FMgMGDhMJiAUNtnSPYQcGgwNsA4knjjQBgSqQJIFYgVkc X-IronPort-AV: E=Sophos;i="4.89,649,1367971200"; d="scan'208";a="82739177" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 12 Jul 2013 00:30:03 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6C0U2Bb010157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 00:30:02 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r6C0U2ac003309; Thu, 11 Jul 2013 17:30:02 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r6C0U232003308; Thu, 11 Jul 2013 17:30:02 -0700 Date: Thu, 11 Jul 2013 17:30:02 -0700 From: Toerless Eckert To: ken carlberg Message-ID: <20130712003002.GA30036@cisco.com> References: <20130710180147.GA614@cisco.com> <34BE8BE0-E863-4F69-8D45-18F5B97DE392@g11.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34BE8BE0-E863-4F69-8D45-18F5B97DE392@g11.org.uk> User-Agent: Mutt/1.4.2.2i Cc: rmcat@ietf.org, rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 00:30:11 -0000 Thanks, Ken Indeed yes, that's exactly the line of thought that we would like to see proceed as well. Any URL still existing for that draft ? "application layer gateway" could specifically mean switching MCU using intelligent dropping in conjunction with outbound congestion control. I definitely would like to see RTP headers as the ultimatele marking option even for routers to do intelligent dropping (or other packet processing "beyond DSCP)). Intra-flow (per-packet) DSCP is just a big pain (aka: impossible) for applications. Many OSs don't have any APIs to support this. And DSCP management in networks is already difficult enough as it stands. Would certainly like to see if there is interest to write up r present more pieces of this puzzle, especially an RTP extension. We just felt that the fairness in intelligent dropping was the biggest concern our video application folks had, that's why we wanted to explain how that piece could work first. Cheers Toerless On Thu, Jul 11, 2013 at 12:04:58PM -0400, ken carlberg wrote: > Toerless, > > some food for thought... > > about 10 years ago, I put together a draft that added an optional TLV prioritization header to RTP to accomplish something similar in terms of having the app decide which was the better RTP packet to drop during times of congestion. My aim was to have these decisions made at forwarding application-layer gateways that did not act as a RTP/RTCP endpoint. The strength of the approach (in my opinion :-) was that it could span pockets of non-diff-serv regions and still carry significance downstream. The weakness was the need for DPI if one wanted to make a more informed decision along the path about dropping a packet. > > I wonder if such a dual-layer design might be helpful in your efforts. In any case, I have an interest in the normalizer draft. > > -ken > > > On Jul 10, 2013, at 2:01 PM, Toerless Eckert (eckert) wrote: > > > When dealing with congestion for real-time datagram (UDP/RTP) based video flows, one idea > > that we think has shown to provide good value is to intelligently drop in the network > > preferentially the least important packets within a video flow, for example non-referenced > > P-frames, because their loss creates the lowest impact to video quality. > > > > One of the main concerns raised against such schemes was one of fairness. If flows > > would start to indicate different priorities for packets in them, how would we > > be able to avoid that flows would indicate all their packets to be of high priority > > to shift packet drops to other flows. Or even more importantly: how could we motivate > > flows to indicate that some of their packets are low priority without them having to > > fear that they would experience more loss than than flows that don't do this. > > > > So, there is one draft that we would like to present (presumably in TSVWG) explaining > > how we think this problem can be solved: draft-lai-tsvwg-normalizer-00.txt > > > > (Actually, this is how we did solve the problem in our implementatin of intelligent dropping, > > so this is not theoretical). > > > > Now granted, the problem of fairness is but one element of building a complete ssytem > > around the idea of intelligent dropping, so if folks here on the lists would like to > > see for example > > > > a) how well can it work in routers to shift packet drops to low-prio packets > > b) whats the evidence that it's good for video quality > > c) How should we do the marking best going forward > > > > Then please let us know. We'd be very interested to provide insight into the parts of > > those pieces that we have also worked out or discuss the ones we have not (primarily c ;-) > > > > Thanks! > > Toerless > > > > In-Reply-To: > > > > On Sat, Feb 09, 2013 at 03:00:48AM +0000, Cheng-Jia Lai (chelai) wrote: > >> Hi all, > >> > >> We have submitted a new Internet draft to describe a Normalization Marker (NM) for DiffServ AF PHB groups, based on our work at Cisco. The goal of NM deployment is to create a new incentive for video encoders to generate more discardable packets when using AF PHB in DIffServ. We are looking forward to your review comments. > >> > >> Best regards, > >> CJ > >> > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Friday, February 08, 2013 6:25 PM > >> To: Cheng-Jia Lai (chelai) > >> Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (eckert); Fred Yip (fyip) > >> Subject: New Version Notification for draft-lai-tsvwg-normalizer-00.txt > >> > >> > >> A new version of I-D, draft-lai-tsvwg-normalizer-00.txt > >> has been successfully submitted by Cheng-Jia Lai and posted to the > >> IETF repository. > >> > >> Filename: draft-lai-tsvwg-normalizer > >> Revision: 00 > >> Title: Normalization Marker for AF PHB Group in DiffServ > >> Creation date: 2013-02-08 > >> WG ID: Individual Submission > >> Number of pages: 15 > >> URL: http://www.ietf.org/internet-drafts/draft-lai-tsvwg-normalizer-00.txt > >> Status: http://datatracker.ietf.org/doc/draft-lai-tsvwg-normalizer > >> Htmlized: http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-00 > >> > >> > >> Abstract: > >> This memo describes a Normalization Marker (NM) at DiffServ (DS) > >> nodes to normalize the distribution of DS codepoint (DSCP) markings > >> for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM is > >> useful for traffic conditioning with Active Queue Management (AQM) > >> when the AF PHB group is deployed for multimedia service classes that > >> carry video packets with advanced codec technologies. Using NM can > >> offer an incentive that is however missing in today's ecosystem of > >> practical deployment, i.e., when congestion occurs in the AF PHB > >> group, the network should allow a video codec to benefit from its > >> effort of generating finer layers of intra-flow precedence (IFP) with > >> discardable packets in a more balanced distribution. > >> > >> > >> > >> > >> The IETF Secretariat > >> > > > > -- > > --- > > Toerless Eckert, eckert@cisco.com > > Cisco NSSTG Systems & Technology Architecture > > SDN: Let me play with the network, mommy! > > > -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From eckert@cisco.com Thu Jul 11 17:59:38 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8882811E824B; Thu, 11 Jul 2013 17:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.49 X-Spam-Level: X-Spam-Status: No, score=-10.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgvWWiyiQHbf; Thu, 11 Jul 2013 17:59:34 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 796A911E80D7; Thu, 11 Jul 2013 17:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7279; q=dns/txt; s=iport; t=1373590774; x=1374800374; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=rng01PAmE220ZiRAmBpWAp4N6BZfP+Fg3gTDUeiHZEk=; b=Ix7ERua4f4o01bi2JsVpKC9pmcrvsKleBfWUp3ltxyT2uWxZKqYRvAYw Xjn9zwgXYwTvOXw+URzy1ODCnIN0rcubDhFLBksJyzGuQ3x6UJb71DIOO jwrUB07evh4oX0nNjrOU6S4e9KHinIY7cFrFumw/58bWNCX51HVsNTBO6 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgJAPZT31GrRDoJ/2dsb2JhbABagwY0wiAEAYEHFnSCIwEBAQMBMgEyFAUHBAsRAQMBAQEJAxcEBw8FMgMGDg8ECYgABQ23A45KgRcHBoMDbAOJJ440AYEqkCSBWIFZHA X-IronPort-AV: E=Sophos;i="4.89,649,1367971200"; d="scan'208";a="85758034" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 12 Jul 2013 00:59:31 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6C0xUBk001901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 00:59:30 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r6C0xUTF004788; Thu, 11 Jul 2013 17:59:30 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r6C0xU6u004787; Thu, 11 Jul 2013 17:59:30 -0700 Date: Thu, 11 Jul 2013 17:59:30 -0700 From: "Toerless Eckert (eckert)" To: Dave Taht Message-ID: <20130712005930.GB30036@cisco.com> References: <20130710180147.GA614@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: rmcat@ietf.org, rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 00:59:38 -0000 On Wed, Jul 10, 2013 at 12:02:26PM -0700, Dave Taht wrote: > I've begun to look at webrtc of late in the context of fq_codel. > > One thing that might work would be ECN marking important frames and > not ECN marking others. True. But i think there are at least 3 layers of priority that would really be great to have: really important packet (long term reference frames), "normal" packets, and low-proirity-packets (eg: discardable P). And ECN could only do two. Most of the time when you would want intelligent dropping, your drop rate should be fairly low, eg< 20% instantaneous within the queue. If you can do discardable P-frames it's of course best to drop those first. Only when you instantaneously have really big bursts would you want to drop "normal" packets and refrain to protection really important packets. This does work really well with different queue-length (or WRED profiles). If you only had two priorities (via ECN) it's hard to say how you would best assign these two priorities to at least those three priority levels. > Problem overall is that ecn can be gamed and is largely not > enabled, and so on... Well. The gaming could be inhibited exactly by this draft because it would try to guarantee the same amount of drops on a per-flow or "class" basis, so if you're trying to game the system, you would be put into your own class and would still see the same amount of drops as other flows. Well, the main issue is really to redesignate ECN for a different semantic than what it has today. And indicating packet priority is just not quite the same as congestion feedback. > In the case of the fq_codel algorithm I can see a "delayed drop" > mechanism happening, > where upon deciding to drop, it could defer a drop up to a few packets > based on the classification > of the packet, say 3 packets at most. Since flows are already > identified, this is kind of easy > by adding another state variable... Yes, this is all quite interesting. We also played around with droppping during enqueuing vs. during dequeuing, so there are a bunch of things that could optimize intelligent dropping if you can build a more intelligent queue. [...] > > So I can see trying to utilize the AF markings as you describe in your > draft in codel's > drop decision. While this is also subject to being gamed, the > disincentives are slight. Lets separate the marking from the mechanism to inhibit gaming. This draft really is about the latter, and the marking described with AF is really just an example. Yes, it would be lovely to agree on markings too. > And what codel depends on is a definition of "TCP friendly". That if a > stream is not going to behave in a tcp friendly manner, then an entirely > different strategy for such flows seems necessary, and glomming on some > additional state isn't going to be the right thing. Who stood up at RMCAT some time back and claimed to have worked for > 10 years on TCP and declared TCP not self friendly to itself, so RMCAT shouldn't bother ? ;-)) Kidding aside: Intelligent dropping IMHO makes perfect sense when being applied to RT traffic sharing a queue friendly with TCP. And intelligent dropping can then still improve the performance. I am pretty positive though that RMCAT traffic in general will behave better and get lower delay and more video-appropriate loss if it can have its own queue. Primarily because it will just take decates to root out all the bad TCP traffic. I don't think that the strategies if you do or if you don't share the queue with TCP would be fundamentally be different. > a) how well can it work in routers to shift packet drops to low-prio packets > > I guess where I fall apart here is how to shift the encoders to send thinner > streams at any level of packet drop. Video codec coders are known to be able to do crazy cool things. There are a bunch of known mechanisms and probably more proprietary ones. > I'd be interested in specific codecs, example video streams, and test > scripts to try and fiddle with this, as well as viable metrics. Sure. Best done in person. If we're going to be at the WG for this, we can talk on the side how we've been doing this. Cheers Toerless > > Thanks! > > Toerless > > > > In-Reply-To: > > > > On Sat, Feb 09, 2013 at 03:00:48AM +0000, Cheng-Jia Lai (chelai) wrote: > >> Hi all, > >> > >> We have submitted a new Internet draft to describe a Normalization Marker (NM) for DiffServ AF PHB groups, based on our work at Cisco. The goal of NM deployment is to create a new incentive for video encoders to generate more discardable packets when using AF PHB in DIffServ. We are looking forward to your review comments. > >> > >> Best regards, > >> CJ > >> > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Friday, February 08, 2013 6:25 PM > >> To: Cheng-Jia Lai (chelai) > >> Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (eckert); Fred Yip (fyip) > >> Subject: New Version Notification for draft-lai-tsvwg-normalizer-00.txt > >> > >> > >> A new version of I-D, draft-lai-tsvwg-normalizer-00.txt > >> has been successfully submitted by Cheng-Jia Lai and posted to the > >> IETF repository. > >> > >> Filename: draft-lai-tsvwg-normalizer > >> Revision: 00 > >> Title: Normalization Marker for AF PHB Group in DiffServ > >> Creation date: 2013-02-08 > >> WG ID: Individual Submission > >> Number of pages: 15 > >> URL: http://www.ietf.org/internet-drafts/draft-lai-tsvwg-normalizer-00.txt > >> Status: http://datatracker.ietf.org/doc/draft-lai-tsvwg-normalizer > >> Htmlized: http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-00 > >> > >> > >> Abstract: > >> This memo describes a Normalization Marker (NM) at DiffServ (DS) > >> nodes to normalize the distribution of DS codepoint (DSCP) markings > >> for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM is > >> useful for traffic conditioning with Active Queue Management (AQM) > >> when the AF PHB group is deployed for multimedia service classes that > >> carry video packets with advanced codec technologies. Using NM can > >> offer an incentive that is however missing in today's ecosystem of > >> practical deployment, i.e., when congestion occurs in the AF PHB > >> group, the network should allow a video codec to benefit from its > >> effort of generating finer layers of intra-flow precedence (IFP) with > >> discardable packets in a more balanced distribution. > >> > >> > >> > >> > >> The IETF Secretariat > >> > > > > -- > > --- > > Toerless Eckert, eckert@cisco.com > > Cisco NSSTG Systems & Technology Architecture > > SDN: Let me play with the network, mommy! > > > > > > -- > Dave Täht > > Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From wwwrun@rfc-editor.org Fri Jul 12 04:17:36 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB8321F9DF2 for ; Fri, 12 Jul 2013 04:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.237 X-Spam-Level: X-Spam-Status: No, score=-102.237 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lYSnVg3DDjX for ; Fri, 12 Jul 2013 04:17:35 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id A3E2E21F9D80 for ; Fri, 12 Jul 2013 04:17:35 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3B8B66211A; Fri, 12 Jul 2013 04:15:16 -0700 (PDT) To: kk@teraoptic.com, floyd@aciri.org, black_david@emc.com, spencerdawkins.ietf@gmail.com, martin.stiemerling@neclab.eu, gorry@erg.abdn.ac.uk, david.black@emc.com, jmpolk@cisco.com From: RFC Errata System Message-Id: <20130712111516.3B8B66211A@rfc-editor.org> Date: Fri, 12 Jul 2013 04:15:16 -0700 (PDT) Cc: tsvwg@ietf.org, rfc-editor@rfc-editor.org Subject: [tsvwg] [Technical Errata Reported] RFC3168 (3680) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 11:17:36 -0000 The following errata report has been submitted for RFC3168, "The Addition of Explicit Congestion Notification (ECN) to IP". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3168&eid=3680 -------------------------------------- Type: Technical Reported by: Mirja Kühlewind Section: 6.1.1. Original Text ------------- If the TCP connection does not wish to use ECN notification for a particular packet, the sending TCP sets the ECN codepoint to not-ECT, and the TCP receiver ignores the CE codepoint in the received packet. Corrected Text -------------- If the TCP connection does not wish to use ECN notification for a particular packet, the sending TCP sets the ECN codepoint to not-ECT. Notes ----- The receiver should not ignore any CE codepoint. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3168 (draft-ietf-tsvwg-ecn-04) -------------------------------------- Title : The Addition of Explicit Congestion Notification (ECN) to IP Publication Date : September 2001 Author(s) : K. Ramakrishnan, S. Floyd, D. Black Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From mramalho@cisco.com Fri Jul 12 06:49:38 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C2811E813A for ; Fri, 12 Jul 2013 06:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pBed1ESJbL8 for ; Fri, 12 Jul 2013 06:49:32 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 69D9821F9D8E for ; Fri, 12 Jul 2013 06:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3485; q=dns/txt; s=iport; t=1373636972; x=1374846572; h=from:to:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=ynJrIcEy1995Y/++N5+nfos2bUrDDuaZwynNzkAMhFI=; b=QYFXIP6I6mFRJFmJ3kgvysaYpopKAOzqPVZBjqX0qiew86b5lmv0tYNe ugSSqFYBgiW2Ccl2yNYN4p/mUuNNg/1GbAVURzCddD6WssH97ml1/2DgV PS3bBdtdaJMGoQhSl2wgAHTnuBw9HaREablJ5mP86J8R570dnRvuM1kau U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFACMJ4FGtJV2b/2dsb2JhbABagwaBA8FRgQkWdIIjAQEBBDpLBAIBCBEEAQELFAkHMhQHAQEFAwIEEwiIB7c3jzA+gwVsA6kpgxKCKA X-IronPort-AV: E=Sophos;i="4.89,653,1367971200"; d="scan'208";a="231047210" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 12 Jul 2013 13:49:30 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6CDnTBB012141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 12 Jul 2013 13:49:29 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.54]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Fri, 12 Jul 2013 08:49:29 -0500 From: "Michael Ramalho (mramalho)" To: "tsvwg@ietf.org" Thread-Topic: [rmcat] Shared Congestion state & draft-dhesikan-tsvwg-rtcweb-qos Thread-Index: AQHOfHzwAC6mDhb6mEWGtbT3f/hofZlhCj9QgAAJnWA= Date: Fri, 12 Jul 2013 13:49:28 +0000 Message-ID: References: <79d9662b6063b3b671ee5f2674b9bf9f.squirrel@www.erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.125.234] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [tsvwg] FW: [rmcat] Shared Congestion state & draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 13:49:38 -0000 (Re)sending to tsvwg@ietf.org ... instead of tsvwg@tools.ietf.org ... Micha= el Ramalho -----Original Message----- From: Michael Ramalho (mramalho)=20 Sent: Friday, July 12, 2013 9:47 AM To: 'gorry@erg.abdn.ac.uk'; rmcat@ietf.org Cc: tsvwg@tools.ietf.org Subject: RE: [rmcat] Shared Congestion state & draft-dhesikan-tsvwg-rtcweb-= qos Gorry, Your recollection regarding the desire for a separate DSCP code point for "= RMCAT flows" is correct. To review for everyone else here, when a RMCAT flow competes in a bottlenec= k queue where the dominant traffic flows into that queue possess congestion= control that adapts based on loss (e.g., long-lived TCP flows), the RMCAT = flow is stuck with a delay of whatever the maximum queuing delay through th= e queue is. This situation is not desirable because the interactive applica= tions that desire RMCAT transport desire low delay (i.e., to minimize any p= otential bufferbloat). So, while it is a given that a RMCAT flow must live (survive) when it finds= itself in such a traffic aggregate, the RMCAT flow would "prefer" to exist= in a traffic aggregate that does not require queue overflow when the other= flows adapt. This is desirable because a lower delay is possible relative = to the former. It is for this reason that RMCAT desires a separate DSCP code point. And so= me RMCAT participants voiced that desire at the Orlando IETF transport work= ing group meeting. Draft draft-dhesikan-tsvwg-rtcweb-qos is a draft whose intension was to map= the EXISTING DSCPs into something RTCWeb could use today (draft authors ma= y correct me if I am wrong). Given the recent nature of the RMCAT request (= for a separate DSCP codepoint) to the transport WG - that request has not b= een incorporated into the Dhesikan draft yet. I have offered to craft a few sentences for inclusion into the Dhesikan dra= ft explicitly stating the desire for a new codepoint is recognized, but tha= t the draft only deals with the EXISTING codepoints (i.e., those defined by= RFC 4594). I think this is the correct approach, as I think it is wise to provide RTCW= eb applications designers with some guidance prior to the completion of RMC= AT work. Comments are welcome. My $0.02, Michael Ramalho -----Original Message----- From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of g= orry@erg.abdn.ac.uk Sent: Tuesday, July 09, 2013 4:18 AM To: rmcat@ietf.org Cc: tsvwg@tools.ietf.org Subject: [rmcat] Shared Congestion state & draft-dhesikan-tsvwg-rtcweb-qos I's like to solicit feedback on draft-dhesikan-tsvwg-rtcweb-qos, proposed a= s a work item in tsvwg. This was brought to TSVWG for consideration because it discusses transport = mappings to QoS intended for RTCweb. At a previous RMCAT WG meeting it was mentioned that this advocates use of = separate QoS code points for different streaming components. At that time = it was suggested that use of several QoS code points for different streamin= g components would result in flow-isolation between the different RTCWeb su= bflows and that this could potentially conflict with design goals in RMCAT = that seek to use coupled congestion state between subflows. It would be hel= pful to know if this draft does impact this and what issues need to be cons= idered. Please *do* provide feedback to tsvwg on this topic. We plan to discuss thi= s in Berlin. Gorry (TSVWG Co-Chair) From hadi@mojatatu.com Wed Jul 10 02:49:08 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09BE21F9F75 for ; Wed, 10 Jul 2013 02:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.933 X-Spam-Level: X-Spam-Status: No, score=-102.933 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dg0nmrkUUBSa for ; Wed, 10 Jul 2013 02:49:03 -0700 (PDT) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id 6296021F9F90 for ; Wed, 10 Jul 2013 02:49:03 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id lf11so5088337vcb.26 for ; Wed, 10 Jul 2013 02:48:57 -0700 (PDT) X-Google-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:x-gm-message-state; bh=oaSKPGiK/jLG9mBaspRo2X7lXVsRV9Cgr4pge6eCm+E=; b=a0AZA3QbFkfrtqVTyN6ASVkww4iDSDN1zcwNbtAX0+DZW9/lHXevPIc3GMVU0GYSAF mCp7VSmc+95oTXEnVrd+QAvG+oyDlkjJ21EKaNZlvniLZyrTBA9WXDUI8OswT1srx9he ypPAO+mFfdagR7F/x59TsB+YMrvg69XheBeF8GuJWZ+3hn/TZPRFRtghXl9fko/apWpU IuOblTuziihR9knSjdvzVjqQ3JylcL8Eaqto/pIqMNaDk2l3pQQ1CjZrdBsOtj+7ldQ7 iGsfkqdYpP4f0+ESh2jeuho+YHnUfG72sks0jRfwwFUXgzmvBfuuBNIY7dMKYJZGl+38 eAcQ== X-Received: by 10.58.29.111 with SMTP id j15mr18509537veh.76.1373449737233; Wed, 10 Jul 2013 02:48:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.215.19 with HTTP; Wed, 10 Jul 2013 02:48:37 -0700 (PDT) In-Reply-To: <27BA1FEC-AE84-412F-8D8A-4857FF283149@fh-muenster.de> References: <27BA1FEC-AE84-412F-8D8A-4857FF283149@fh-muenster.de> From: Jamal Hadi Salim Date: Wed, 10 Jul 2013 05:48:37 -0400 Message-ID: To: Michael Tuexen Content-Type: multipart/alternative; boundary=047d7b6d9de0b4ae4004e1252fa4 X-Gm-Message-State: ALoCoQkvEu2DyR+fQq1d+huOzYLGu+7Y3Ysz1w9wKA/xfsE1O1Oh3mhsyG0V7M7E6SoCx7p4vZT6 X-Mailman-Approved-At: Fri, 12 Jul 2013 08:06:12 -0700 Cc: tsvwg , "robin.seggelmann" Subject: Re: [tsvwg] comments draft-tuexen-tsvwg-sctp-prpolicies-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 09:49:08 -0000 --047d7b6d9de0b4ae4004e1252fa4 Content-Type: text/plain; charset=ISO-8859-1 Hi Michael, On Wed, Jul 10, 2013 at 3:42 AM, Michael Tuexen wrote: > > Assume the sender sends a user message which is approximately of size > 3*MTU. > So SCTP will fragment it into 3 DATA chunk and send them. If the user > has specified that the number of retransmissions is limited to 0 and > the last fragment gets lost in the network, the sender will increment > sprstat_abandoned_sent. > Ok, so the last fragment essentially doesnt get acknowledged before we abandon ship. And the other stat indicates we abandoned while we still had some sitting locally. Is the intersection of the two (some are sent but not acked and some are still sitting locally) implying both stats will be incremented? Other than the perceived ambiguity - why do i care to know about the two types of abandoned messages in a user app? I will have to sum those two, so why not just give me one stat? BTW: the doc will benefit from such a small description as you gave me above. What will happen at the receiver side if you assume that the first two > fragments have been received. If partial delivery was started, you will > get a SCTP_PARTIAL_DELIVERY_EVENT event indicating > SCTP_PARTIAL_DELIVERY_ABORTED. > Without partial delivery being started, the receiver could also drop the > first part of the message. > > You answered the essence of my question. Silly follow up: I am assuming that event will come with an EOR? To use your example (at receiver): EPOLLIN, recvmsg chunk1, chunk2, EAGAIN EPOLLIN, recvmsg SCTP_PARTIAL_DELIVERY_EVENT, EOR cheers, jamal --047d7b6d9de0b4ae4004e1252fa4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Michael,

On Wed, Jul 10, 2013 at 3:42 AM, Michael Tuexen <tu= exen@fh-muenster.de> wrote:

Assume the sender sends a user message which is approximately of size 3*MTU= .
So SCTP will fragment it into 3 DATA chunk and send them. If the user
has specified that the number of retransmissions is limited to 0 and
the last fragment gets lost in the network, the sender will increment
sprstat_abandoned_sent.

Ok, =A0so the l= ast fragment essentially doesnt get acknowledged before we=A0
aba= ndon ship. And the other stat indicates we abandoned while we still had som= e
sitting locally. Is the intersection of the two (some are sent but not= acked and
some are still sitting locally) implying both stats wi= ll be incremented?

Other than the perceived ambiguity - =A0why do i care to know about th= e
two types of abandoned messages in a user app? I =A0will have t= o sum
those two, so why not just give me one stat?
=A0<= /div>
BTW: the doc will benefit from such a small description as you gave me=
above.

What will happen at the receiver side if you assume that the first two
fragments have been received. If partial delivery was started, you will
get a SCTP_PARTIAL_DELIVERY_EVENT event indicating SCTP_PARTIAL_DELIVERY_AB= ORTED.
Without partial delivery being started, the receiver could also drop the first part of the message.


You answered the essence of my questio= n.
Silly follow up: I am assuming that event will come with an EO= R?
To use your example (at receiver):
EPOLLIN, recvmsg = chunk1, chunk2, EAGAIN
EPOLLIN, recvmsg=A0SCTP_PARTIAL_DELIVERY_EVENT, EOR
cheers,
jamal
--047d7b6d9de0b4ae4004e1252fa4-- From tuexen@fh-muenster.de Fri Jul 12 08:22:19 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75FF121E80AD for ; Fri, 12 Jul 2013 08:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQmAt6B9bwZA for ; Fri, 12 Jul 2013 08:22:18 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id D59BA21F9E13 for ; Fri, 12 Jul 2013 08:21:59 -0700 (PDT) Received: from [10.225.4.237] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id E2F601C0C0692; Fri, 12 Jul 2013 17:21:57 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Tuexen In-Reply-To: Date: Fri, 12 Jul 2013 17:21:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <27BA1FEC-AE84-412F-8D8A-4857FF283149@fh-muenster.de> To: Jamal Hadi Salim X-Mailer: Apple Mail (2.1508) Cc: tsvwg , "robin.seggelmann" Subject: Re: [tsvwg] comments draft-tuexen-tsvwg-sctp-prpolicies-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 15:22:19 -0000 On Jul 10, 2013, at 11:48 AM, Jamal Hadi Salim = wrote: >=20 > Hi Michael, >=20 > On Wed, Jul 10, 2013 at 3:42 AM, Michael Tuexen = wrote: >=20 > Assume the sender sends a user message which is approximately of size = 3*MTU. > So SCTP will fragment it into 3 DATA chunk and send them. If the user > has specified that the number of retransmissions is limited to 0 and > the last fragment gets lost in the network, the sender will increment > sprstat_abandoned_sent. >=20 > Ok, so the last fragment essentially doesnt get acknowledged before = we=20 > abandon ship. And the other stat indicates we abandoned while we still = had some > sitting locally. Is the intersection of the two (some are sent but not = acked and > some are still sitting locally) implying both stats will be = incremented? >=20 > Other than the perceived ambiguity - why do i care to know about the > two types of abandoned messages in a user app? I will have to sum > those two, so why not just give me one stat? > =20 > BTW: the doc will benefit from such a small description as you gave me > above. The new revision contains some clarification: http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-prpolicies-02 Best regards Michael >=20 > What will happen at the receiver side if you assume that the first two > fragments have been received. If partial delivery was started, you = will > get a SCTP_PARTIAL_DELIVERY_EVENT event indicating = SCTP_PARTIAL_DELIVERY_ABORTED. > Without partial delivery being started, the receiver could also drop = the > first part of the message. >=20 >=20 > You answered the essence of my question. > Silly follow up: I am assuming that event will come with an EOR? > To use your example (at receiver): > EPOLLIN, recvmsg chunk1, chunk2, EAGAIN > EPOLLIN, recvmsg SCTP_PARTIAL_DELIVERY_EVENT, EOR >=20 > cheers, > jamal From mzanaty@cisco.com Fri Jul 12 08:19:22 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22AE021E808D for ; Fri, 12 Jul 2013 08:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.406 X-Spam-Level: X-Spam-Status: No, score=-10.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2mn1KQWpwkP for ; Fri, 12 Jul 2013 08:19:17 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 37D7511E810E for ; Fri, 12 Jul 2013 08:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4111; q=dns/txt; s=iport; t=1373642357; x=1374851957; h=from:to:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=GoEorKZSvl6yOKAnEGZHwF3a7Wdn1OJJqZstomd0E0Q=; b=BdiVsIYLLo0OyAo7ppvYoQPpSb8Us2OFGRvx/N+uCPTvajEzHTyaD3zQ m9xUNcCJGvH0tiSZrCwrCvjgJYPJRAkA3lyv/1x7jBueTDI5biSdzzx9T jT7zvglv86rmApZcW0uixWT3aMtZHCDH/KHpooCxXDl9O/xAFp85KQaJ8 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAEQd4FGtJXHB/2dsb2JhbABagwY0T8FRgQkWdIIjAQEBBDpLBAIBCBEEAQELFAkHMhQJCAIEEwiIBwy3TY8wPoMFbAOZBZAkgxKCKA X-IronPort-AV: E=Sophos;i="4.89,653,1367971200"; d="scan'208";a="234060826" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 12 Jul 2013 15:19:17 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6CFJGFd006589 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 12 Jul 2013 15:19:16 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Fri, 12 Jul 2013 10:19:16 -0500 From: "Mo Zanaty (mzanaty)" To: "tsvwg@ietf.org" Thread-Topic: [rmcat] Shared Congestion state & draft-dhesikan-tsvwg-rtcweb-qos Thread-Index: AQHOfHzwAC6mDhb6mEWGtbT3f/hofZlhCj9QgAAfcWCAAANOIA== Date: Fri, 12 Jul 2013 15:19:15 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D492EAE@xmb-rcd-x14.cisco.com> References: <79d9662b6063b3b671ee5f2674b9bf9f.squirrel@www.erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.29.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 12 Jul 2013 13:57:20 -0700 Subject: Re: [tsvwg] [rmcat] Shared Congestion state & draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 15:19:22 -0000 Correcting tsvwg mailer. -----Original Message----- From: Mo Zanaty (mzanaty)=20 Sent: Friday, July 12, 2013 11:16 AM To: Michael Ramalho (mramalho); gorry@erg.abdn.ac.uk; James Polk (jmpolk) Cc: tsvwg@tools.ietf.org; rmcat@ietf.org Subject: RE: [rmcat] Shared Congestion state & draft-dhesikan-tsvwg-rtcweb-= qos Folks should also be aware that RFC 4594 is being updated, and that is the = best place to propose a separate DSCP for RMCAT traffic (or delay-adaptive = traffic in general, although you could argue RMCAT and LEDBAT should also b= e kept separate). http://tools.ietf.org/html/draft-polk-tsvwg-rfc4594-update-03 Mo -----Original Message----- From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of M= ichael Ramalho (mramalho) Sent: Friday, July 12, 2013 9:47 AM To: gorry@erg.abdn.ac.uk; rmcat@ietf.org Cc: tsvwg@tools.ietf.org Subject: Re: [rmcat] Shared Congestion state & draft-dhesikan-tsvwg-rtcweb-= qos Gorry, Your recollection regarding the desire for a separate DSCP code point for "= RMCAT flows" is correct. To review for everyone else here, when a RMCAT flow competes in a bottlenec= k queue where the dominant traffic flows into that queue possess congestion= control that adapts based on loss (e.g., long-lived TCP flows), the RMCAT = flow is stuck with a delay of whatever the maximum queuing delay through th= e queue is. This situation is not desirable because the interactive applica= tions that desire RMCAT transport desire low delay (i.e., to minimize any p= otential bufferbloat). So, while it is a given that a RMCAT flow must live (survive) when it finds= itself in such a traffic aggregate, the RMCAT flow would "prefer" to exist= in a traffic aggregate that does not require queue overflow when the other= flows adapt. This is desirable because a lower delay is possible relative = to the former. It is for this reason that RMCAT desires a separate DSCP code point. And so= me RMCAT participants voiced that desire at the Orlando IETF transport work= ing group meeting. Draft draft-dhesikan-tsvwg-rtcweb-qos is a draft whose intension was to map= the EXISTING DSCPs into something RTCWeb could use today (draft authors ma= y correct me if I am wrong). Given the recent nature of the RMCAT request (= for a separate DSCP codepoint) to the transport WG - that request has not b= een incorporated into the Dhesikan draft yet. I have offered to craft a few sentences for inclusion into the Dhesikan dra= ft explicitly stating the desire for a new codepoint is recognized, but tha= t the draft only deals with the EXISTING codepoints (i.e., those defined by= RFC 4594). I think this is the correct approach, as I think it is wise to provide RTCW= eb applications designers with some guidance prior to the completion of RMC= AT work. Comments are welcome. My $0.02, Michael Ramalho -----Original Message----- From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of g= orry@erg.abdn.ac.uk Sent: Tuesday, July 09, 2013 4:18 AM To: rmcat@ietf.org Cc: tsvwg@tools.ietf.org Subject: [rmcat] Shared Congestion state & draft-dhesikan-tsvwg-rtcweb-qos I's like to solicit feedback on draft-dhesikan-tsvwg-rtcweb-qos, proposed a= s a work item in tsvwg. This was brought to TSVWG for consideration because it discusses transport = mappings to QoS intended for RTCweb. At a previous RMCAT WG meeting it was mentioned that this advocates use of = separate QoS code points for different streaming components. At that time = it was suggested that use of several QoS code points for different streamin= g components would result in flow-isolation between the different RTCWeb su= bflows and that this could potentially conflict with design goals in RMCAT = that seek to use coupled congestion state between subflows. It would be hel= pful to know if this draft does impact this and what issues need to be cons= idered. Please *do* provide feedback to tsvwg on this topic. We plan to discuss thi= s in Berlin. Gorry (TSVWG Co-Chair) From internet-drafts@ietf.org Sat Jul 13 09:11:14 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9133321F9A90; Sat, 13 Jul 2013 09:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0idMgvPaoRn; Sat, 13 Jul 2013 09:11:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 255D921F909A; Sat, 13 Jul 2013 09:11:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130713161114.20169.80457.idtracker@ietfa.amsl.com> Date: Sat, 13 Jul 2013 09:11:14 -0700 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-pcn-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 16:11:14 -0000 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 Grou= p of the IETF. Title : Generic Aggregation of Resource ReSerVation Protocol (RS= VP) for IPv4 And IPv6 Reservations over PCN domains Author(s) : Georgios Karagiannis Anurag Bhargava Filename : draft-ietf-tsvwg-rsvp-pcn-05.txt Pages : 27 Date : 2013-07-13 Abstract: This document specifies extensions to Generic Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- Congestion Notification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-pcn-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rsvp-pcn-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bhargava.anurag@gmail.com Sun Jul 14 05:06:38 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16ED721F9948 for ; Sun, 14 Jul 2013 05:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZfMlaGjv-AG for ; Sun, 14 Jul 2013 05:06:37 -0700 (PDT) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9BE21F9931 for ; Sun, 14 Jul 2013 05:06:37 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id f4so14564356oah.21 for ; Sun, 14 Jul 2013 05:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=YAKCqcZ/jN+a94CpsVPkTOht3KcpnWAwoOXY6vSRUMQ=; b=MXPIYrYzj2mtTZpPq+YInFHyblbWb06ZXw4Y/vD8QCgxQMNFJYvrHN6GmKFum2A//U /3/U2dhZDNuqv2/V8OmZNTCTIxD+4yURFgRGSK+MILTWMcNoyk4W0tfKCx82wckGYwm4 NaxrCQlvXP5v9PEcYM+XkOR56dDKeYbf1P1zRFTbpEgMoMqPrxRvVCVCvVv0coxwxRTY eghS6QVgeGC18rhY1nHFqEtYIuVKMZ5d5Wq06z7QVaHRXozdy61k3M1xTWBvzrlQ1BEd 3kwv/ycrTjCwlAR5jS38on1ZLuL21b0dQx/7mSutv0ikcM1iOv2j3rhgdN4u0j9g8qXJ SrTA== MIME-Version: 1.0 X-Received: by 10.60.141.226 with SMTP id rr2mr40713805oeb.12.1373803596732; Sun, 14 Jul 2013 05:06:36 -0700 (PDT) Received: by 10.182.120.167 with HTTP; Sun, 14 Jul 2013 05:06:36 -0700 (PDT) In-Reply-To: <20130713161114.20169.80457.idtracker@ietfa.amsl.com> References: <20130713161114.20169.80457.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 08:06:36 -0400 Message-ID: From: Anurag Bhargava To: "tsvwg@ietf.org" , anuragb@cisco.com, Georgios Karagiannis Content-Type: multipart/alternative; boundary=047d7b41c7465fe00c04e177937e Subject: [tsvwg] Fwd: I-D Action: draft-ietf-tsvwg-rsvp-pcn-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 12:06:38 -0000 --047d7b41c7465fe00c04e177937e Content-Type: text/plain; charset=ISO-8859-1 Hi All, Here is the new draft which incorporates comments A) incorporated Bob's comments: For ex: Added text to be more clearer "Even though these procedures are out of the scope of this document, the PCN-ingress-node can refer to a central decision point which can respond to the PCN ingress as per [RFC2753]." B) incorporated David's comment on misconfiguration and added Section 3.16: "3.16. Misconfiguration of PCN-node In an event where a PCN-node is misconfigured within a PCN-domain, the desired behavior is same as described in Section 3.9. Therefore, the Aggregated Resv messages are simply forwarded as normal IP datagrams." C) Few editorial fixes and some cleanups Thx -Anurag ---------- Forwarded message ---------- From: Date: Sat, Jul 13, 2013 at 12:11 PM Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-pcn-05.txt To: i-d-announce@ietf.org Cc: tsvwg@ietf.org 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 Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 And IPv6 Reservations over PCN domains Author(s) : Georgios Karagiannis Anurag Bhargava Filename : draft-ietf-tsvwg-rsvp-pcn-05.txt Pages : 27 Date : 2013-07-13 Abstract: This document specifies extensions to Generic Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- Congestion Notification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-pcn-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rsvp-pcn-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ -- BR, -Anurag --047d7b41c7465fe00c04e177937e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,
=A0 Here is the new draft which incorporates c= omments

=A0 =A0A) incorporated Bob'= s comments: For ex: Added text to be more clearer

"Even though these procedures are out o= f the scope

of this document, the PCN-ingress-node can refer to a cen= tral

decision point which can respond to the PCN ingress as per

[RFC275= 3]."

=A0

B) incorporated David's comment on mis= configuration and added Section 3.16:

"3.16. Mi= sconfiguration of PCN-node

In an event where a PCN-node is misconfigured within a PCN-domain,

the desired behavior is same as described in Section 3.9. Therefore,

the Aggregated Resv messages are simply forwarded as normal IP

datag= rams."

=A0=A0=A0
C)=A0Few editorial fixes and some cleanups

<= br>
Thx
-Anurag


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Sat, Jul 13, 2013 at 12:11 PM
Subject: [tsvwg] I-D Action: draft-i= etf-tsvwg-rsvp-pcn-05.txt
To: i= -d-announce@ietf.org
Cc: tsvwg@iet= f.org



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

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Generic Aggregation of Resource= ReSerVation Protocol (RSVP) for IPv4 And IPv6 Reservations over PCN domain= s
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Georgios Karagiannis
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Anurag Bhargava
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-tsvwg-rsvp-pcn-05.txt<= br> =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 27
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-13

Abstract:
=A0 =A0This document specifies extensions to Generic Aggregated RSVP
=A0 =A0[RFC4860] for support of the PCN Controlled Load (CL) and Single
=A0 =A0Marking (SM) edge behaviors over a Diffserv cloud using Pre-
=A0 =A0Congestion Notification.





The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-pcn-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rsvp= -pcn-05


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/




--
BR,
-Anurag
--047d7b41c7465fe00c04e177937e-- From bhargava.anurag@gmail.com Sun Jul 14 05:08:50 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E1321F995F for ; Sun, 14 Jul 2013 05:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j03uMAietOd4 for ; Sun, 14 Jul 2013 05:08:50 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id D1EEA21F9931 for ; Sun, 14 Jul 2013 05:08:49 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id o6so14916355oag.27 for ; Sun, 14 Jul 2013 05:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yTImRlwXxbYTR170Imru582sM8gAGqt6cIp8e0YpbVg=; b=eafNDRTcPgrO6VG2DzZunN10N7SS1TQSe2o9Iwu+NGFxONkGQvp32mAyf51n8CBr2k Falbs0XvvWn1hVtAbqMZXuDRaB5fu2NCvwnxaHadcyEYXmmMAim2mfm34JAmXvoxH4jv S3EIGC9jFKnsY/tYWSZnzinL4JfjBUvRLrlRU4vd7k690goyn/QwkhALtKN975E2UFqK GNxb+x/Ap3T/caMoxEPbsxjanPw+G3KZV7tJkJe8pOSFkLdTQZAylqaWNu1t4Mofj0qB fIr7cjtru500pThuZ4xzULaerwOpub965gqlXnOUUOVqGnDk42dalXhUVbYq26bhaW82 DKww== MIME-Version: 1.0 X-Received: by 10.60.56.82 with SMTP id y18mr41141617oep.86.1373803728309; Sun, 14 Jul 2013 05:08:48 -0700 (PDT) Received: by 10.182.120.167 with HTTP; Sun, 14 Jul 2013 05:08:48 -0700 (PDT) In-Reply-To: References: <20130713161114.20169.80457.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 08:08:48 -0400 Message-ID: From: Anurag Bhargava To: "tsvwg@ietf.org" , anuragb@cisco.com, Georgios Karagiannis Content-Type: multipart/alternative; boundary=001a11c20b9437939b04e1779b39 Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-pcn-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 12:08:50 -0000 --001a11c20b9437939b04e1779b39 Content-Type: text/plain; charset=ISO-8859-1 Please note that this resolves all the issues which were brought up in the last WG IETF meet in Orlando last March. Hopefully we can now aim for the next step. Br, -A On Sun, Jul 14, 2013 at 8:06 AM, Anurag Bhargava wrote: > Hi All, > Here is the new draft which incorporates comments > > A) incorporated Bob's comments: For ex: Added text to be more clearer > > "Even though these procedures are out of the scope > > of this document, the PCN-ingress-node can refer to a central > > decision point which can respond to the PCN ingress as per > > [RFC2753]." > > > > B) incorporated David's comment on misconfiguration and added Section 3.16: > > "3.16. Misconfiguration of PCN-node > > In an event where a PCN-node is misconfigured within a PCN-domain, > > the desired behavior is same as described in Section 3.9. Therefore, > > the Aggregated Resv messages are simply forwarded as normal IP > > datagrams." > > > C) Few editorial fixes and some cleanups > > Thx > -Anurag > > > ---------- Forwarded message ---------- > From: > Date: Sat, Jul 13, 2013 at 12:11 PM > Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-pcn-05.txt > To: i-d-announce@ietf.org > Cc: tsvwg@ietf.org > > > > 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 Aggregation of Resource ReSerVation > Protocol (RSVP) for IPv4 And IPv6 Reservations over PCN domains > Author(s) : Georgios Karagiannis > Anurag Bhargava > Filename : draft-ietf-tsvwg-rsvp-pcn-05.txt > Pages : 27 > Date : 2013-07-13 > > Abstract: > This document specifies extensions to Generic Aggregated RSVP > [RFC4860] for support of the PCN Controlled Load (CL) and Single > Marking (SM) edge behaviors over a Diffserv cloud using Pre- > Congestion Notification. > > > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-pcn-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rsvp-pcn-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > > > -- > BR, > -Anurag > -- BR, -Anurag --001a11c20b9437939b04e1779b39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please note that this resolves all the issues which were b= rought up in the last WG IETF meet in Orlando last March.

Hopefully we can now aim for the next step.

Br,<= /div>
-A


On Sun, Jul 14, 2013 at 8:06 AM, Anurag Bhargava &l= t;bhargava.a= nurag@gmail.com> wrote:
Hi All,
=A0 Here is the= new draft which incorporates comments

=A0 =A0A) i= ncorporated Bob's comments: For ex: Added text to be more clearer
=

"Even though these procedures are out of the scope=

of this document, the PCN-ingress-node can refer to a central

decision point which can respond to the PCN ingress as per

[RFC275= 3]."

=A0

B) incorporated David's comment on mis= configuration and added Section 3.16:

"3.16. Mi= sconfiguration of PCN-node

In an event where a PCN-node is misconfigured within a PCN-domain,

the desired behavior is same as described in Section 3.9. Therefore,

the Aggregated Resv messages are simply forwarded as normal IP

datagrams."

=A0=A0=A0
C)=A0Few editorial fixes and some cleanups

<= br>
Thx
-Anurag


---------- Forwarded message ----------=
From: <internet-drafts@ietf= .org>
Date: Sat, Jul 13, 2013 at 12:11 PM
Subject: [tsvwg] I-D Action: draft-i= etf-tsvwg-rsvp-pcn-05.txt
To: i-d-announce@ietf.org
Cc: tsvwg@ietf.org



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

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Generic Aggregation of Resource= ReSerVation Protocol (RSVP) for IPv4 And IPv6 Reservations over PCN domain= s
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Georgios Karagiannis
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Anurag Bhargava
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-tsvwg-rsvp-pcn-05.txt<= br> =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 27
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-13

Abstract:
=A0 =A0This document specifies extensions to Generic Aggregated RSVP
=A0 =A0[RFC4860] for support of the PCN Controlled Load (CL) and Single
=A0 =A0Marking (SM) edge behaviors over a Diffserv cloud using Pre-
=A0 =A0Congestion Notification.





The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-pcn-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rsvp= -pcn-05


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/




--
BR,
-Anurag



--
BR,
-Anur= ag
--001a11c20b9437939b04e1779b39-- From sdhesika@cisco.com Sun Jul 14 11:46:40 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59CDF21F9C1B for ; Sun, 14 Jul 2013 11:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0BrPhzL00bl for ; Sun, 14 Jul 2013 11:46:35 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 245A821F9AC1 for ; Sun, 14 Jul 2013 11:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23749; q=dns/txt; s=iport; t=1373827590; x=1375037190; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rnEj2Yd49NZlh8K6QNaVPSiiv/rlu83gOZGOv7SZOZI=; b=PjgUe+c2ByxekEjiYt4ObR3iz0rqwjVylr1b5QxoOgCMuPUhHUQ9aAbW s4HlrRRIJb8RyAkdvS8PMFoL3+1ewTg48IPoZDJKaBlIBcg3170cR2pxu raQPNe5DdaX/NUOyCxNMS+Nyai15xrtJDhSEVLN8zBoICkBfvFnBnaJ4N k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFABnx4lGtJV2Z/2dsb2JhbABZDoI0RDRPuRiFGIMegQoWdIIjAQEBAQMtQwkQAgEIEQQBAQsLCwcHMhQJCAIEAQ0FCIgIDLVEjiKBETEGAQqDAW0DmQWQJIJUPoFxNw X-IronPort-AV: E=Sophos;i="4.89,664,1367971200"; d="scan'208,217";a="234651594" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 14 Jul 2013 18:46:29 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6EIkTDB016505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Jul 2013 18:46:29 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.98]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Sun, 14 Jul 2013 13:46:28 -0500 From: "Subha Dhesikan (sdhesika)" To: Andrew McGregor , "gorry@erg.abdn.ac.uk" Thread-Topic: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos Thread-Index: AQHOfDPkDNpbXj+NgEGu2r18jaM2u5lcUQSAgAAdRYCACBjFMA== Date: Sun, 14 Jul 2013 18:46:28 +0000 Message-ID: References: <32AE7F11-A06E-40C1-A73C-5C69F252DAF9@iii.ca> <51DBC3D3.3000300@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.19.24.37] Content-Type: multipart/alternative; boundary="_000_AAD74A5C56B6A249AA8C0D3B41F86990154362F4xmbalnx10ciscoc_" MIME-Version: 1.0 Cc: tsvwg Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 18:46:40 -0000 --_000_AAD74A5C56B6A249AA8C0D3B41F86990154362F4xmbalnx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andrew, Thank you for reviewing the draft and pointing out the issue that will aris= e with the deployed base. Just so I am clear, you are proposing a couple of hardships with the curren= t draft: 1. Smaller set of values that will work with the below-mentioned impl= ementations 2. The ordering be different in terms of priority from what is propos= ed not only in this draft but the work prior that my draft is leveraging. F= or example AF2 > AF3 and at the same time > AF1. Defining a smaller set of values may be alright except we lose the granular= ity and then having a mechanism to restore the real value in the network be= comes important. My draft alludes to such a service which will take policy = into account and impact markings if needed. If we restrict the values to a = very small set, such a service will become critical. The other challenge I see is with the relative position of the values being= different from what is traditionally known for DSCP where EF> AF4x >AF3x>.= .. How have you handled it so far in a non-web rtc environment? If I have not understood your comments properly, please correct. Regards, Subha . From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of A= ndrew McGregor Sent: Tuesday, July 09, 2013 2:48 AM To: gorry@erg.abdn.ac.uk Cc: tsvwg Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos So, there is a significant bug in the mappings proposed. That is this: the= re is a substantial deployed base of home routers and other network devices= that use the Linux kernel's default output queue pfifo_fast, which uses a = mapping derived from RFC 1349 (documented in the linux man page tc_prio, se= e for example http://linux.die.net/man/8/tc-prio) If the proposed mapping= s don't work with that queue discipline, they won't work on the deployed ba= se. pfifo_fast has then unfortunate properties of ignoring the top 3 bits = of the tos byte, and sometimes paying attention to one of the ECN bits in c= hoosing a queueing band. In effect, since Linux has produced a de-facto standard codepoint assignmen= t for the edge of the network, we had better recommend something compatible= . The proposed mapping uses EF for all audio, which will create a priority= inversion and have all the Linux devices on the edge classify that traffic= as 'bulk interactive', lower than the interactive video at AF4x in the 'in= teractive' band. This is probably not what we want. I've filled out the linux band numbers in table 1 from the draft; the third= number in each table cell is the linux band, smaller number is higher prio= rity: +-----------------------+-------------+-------------+-------------+ | Media Type | Low | Medium | High | +-----------------------+-------------+-------------+-------------+ | Audio | 46 (EF) 1 | 46 (EF) 1 | 46 (EF) 1 | | Interactive Video | 38 (AF43) 1 | 36 (AF42) 0 | 34 (AF41) 2 | | Non-Interactive Video | 26 (AF33) 1 | 28 (AF32) 0 | 30 (AF31) 2 | | Data | 8 (CS1) 1 | 0 (BE) 1 | 10 (AF11) 2 | +-----------------------+-------------+-------------+-------------+ Table 1 - Media Type, Priority, and DSCP Mapping As can readily be seen, there are a number of priority inversions there. E= ffectively, RFC 4594 doesn't work as designed at the edge of the network, a= nd we have to go back to RFC 1349, or at least a restricted set of RFC 4594= codepoints. Effectively, Linux has given us a priority series that reads: AFx2>AFx3>AFx= 1>(CS1 or BE) So, for the purpose of working with both Linux routers and RFC 4594, the us= eful series of codepoints are AF42>AF33>AF21>(CS1 or BE), and it becomes an= exercise of deciding where to place those codepoints in the table. I'd ra= ther use CS1 than BE because it at least states that the application is doi= ng QoS marking. Aside from fixing the actual mappings, though, the draft is a great idea an= d really should be published as soon as reasonably possible. On Tue, Jul 9, 2013 at 6:03 PM, Gorry Fairhurst > wrote: On 09/07/2013 00:35, Cullen Jennings wrote: The draft-dhesikan-tsvwg-rtcweb-qos draft was discussed extensively when it= was an individual draft then WG draft in another WG and I don't think ther= e is much more to say about it. This is one of the normative dependencies o= f the webrtc work and that stuff is already getting implemented in browsers= so I want to move this along in an expedient fashion. I think it is ready for WGLC. If there are any issues people think need to = be discussed before WGLC, please let us know so we can resolve them in Berl= in. Thanks, Cullen In the email above you ask for WGLC. The first step is for the group to con= sider adoption. As I recall, this draft was brought to TSVWG for considerat= ion because it discusses transport mappings to QoS. I understand from the draft this proposes default mappings for an RTCWeb us= e cases. As I see it, the present draft: * Advocates use of separate QoS code points for different streaming compone= nts * Describes both endpoint handling of priority for the media and transport = priority/precedence (aka DSCP). * Proposes formalising a mapping between specific DSCPs and subnetwork QoS = functions (LTE, WiFi - but not general Ethernet). Please read this draft and comment on the list - we will table this for dis= cussion at the next IETF meeting. Gorry --_000_AAD74A5C56B6A249AA8C0D3B41F86990154362F4xmbalnx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andrew,=

 <= /p>

Thank you for reviewing t= he draft and pointing out the issue that will arise with the deployed base.=  

 <= /p>

Just so I am clear, you a= re proposing a couple of hardships with the current draft:

1. = ;      Smaller set of va= lues that will work with the below-mentioned implementations

2. = ;      The ordering be d= ifferent in terms of priority from what is proposed not only in this draft = but the work prior that my draft is leveraging. For example AF2 > AF3 and at the same time > AF1.

 <= /p>

Defining a smaller set of= values may be alright except we lose the granularity and then having a mec= hanism to restore the real value in the network becomes important. My draft alludes to such a service which will take policy into = account and impact markings if needed. If we restrict the values to a very = small set, such a service will become critical.

 <= /p>

The other challenge I see= is with the relative position of the values being different from what is t= raditionally known for DSCP where EF> AF4x >AF3x>… How have you handled it so far in a non-web rtc environment?

 <= /p>

If I have not understood = your comments properly, please correct.

 <= /p>

Regards,

Subha

 <= /p>

.

 <= /p>

From: tsvwg-bo= unces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of Andrew McGregor
Sent: Tuesday, July 09, 2013 2:48 AM
To: gorry@erg.abdn.ac.uk
Cc: tsvwg
Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos

 

So, there is a significant bug in the mappings propo= sed.  That is this: there is a substantial deployed base of home route= rs and other network devices that use the Linux kernel's default output que= ue pfifo_fast, which uses a mapping derived from RFC 1349 (documented in the linux man page tc_prio, see for exam= ple http://linux.die.net/man/8/tc-prio)   If the proposed mapping= s don't work with that queue discipline, they won't work on the deployed ba= se.  pfifo_fast has then unfortunate properties of ignoring the top 3 = bits of the tos byte, and sometimes paying attention to one of the ECN bits in choosing a queueing band.

 

In effect, since Linux has produced a de-facto stand= ard codepoint assignment for the edge of the network, we had better recomme= nd something compatible.  The proposed mapping uses EF for all audio, = which will create a priority inversion and have all the Linux devices on the edge classify that traffic as 'bulk = interactive', lower than the interactive video at AF4x in the 'interactive'= band.  This is probably not what we want.

 

I've filled out the linux band numbers in table 1 fr= om the draft; the third number in each table cell is the linux band, smalle= r number is higher priority:

+-----------------------+-------------+-= ------------+-------------+

| Media Type           &nbs= p;|    Low      |   Medium    | &nb= sp;  High     |

+-----------------------+-------------+-= ------------+-------------+

| Audio             &n= bsp;   |  46 (EF)  1 |  46 (EF)  1 |  46 (EF)=  1 |

| Interactive Video     | 38 (AF43) 1 | 36= (AF42) 0 | 34 (AF41) 2 |

| Non-Interactive Video | 26 (AF33) 1 | 28 (AF32) 0 = | 30 (AF31) 2 |

| Data             &nb= sp;    |  8 (CS1)  1 |   0 (BE)  1 | 10 (AF11= ) 2 |

+-----------------------+-------------+-= ------------+-------------+

      Table 1 - Media Type, Priority,= and DSCP Mapping

 

As can readily be seen, there are a number of priori= ty inversions there.  Effectively, RFC 4594 doesn't work as designed a= t the edge of the network, and we have to go back to RFC 1349, or at least = a restricted set of RFC 4594 codepoints.

 

Effectively, Linux has given us a priority series th= at reads: AFx2>AFx3>AFx1>(CS1 or BE)

 

So, for the purpose of working with both Linux route= rs and RFC 4594, the useful series of codepoints are AF42>AF33>AF21&g= t;(CS1 or BE), and it becomes an exercise of deciding where to place those = codepoints in the table.  I'd rather use CS1 than BE because it at least states that the application is doing QoS marki= ng.

 

Aside from fixing the actual mappings, though, the d= raft is a great idea and really should be published as soon as reasonably p= ossible.

 

On Tue, Jul 9, 2013 at 6:03 PM, Gorry Fairhurst <= gorry@erg.abdn.ac= .uk> wrote:

On 09/07/2013 00:35, Cullen Jennings wrote:


The draft-dhesikan-tsvwg-rtcweb-qos draft was discussed extensively when it= was an individual draft then WG draft in another WG and I don't think ther= e is much more to say about it. This is one of the normative dependencies o= f the webrtc work and that stuff is already getting implemented in browsers so I want to move this along in= an expedient fashion.

I think it is ready for WGLC. If there are any issues people think need to = be discussed before WGLC, please let us know so we can resolve them in Berl= in.

Thanks, Cullen

 

In the email above yo= u ask for WGLC. The first step is for the group to consider adoption. As I = recall, this draft was brought to TSVWG for consideration because it discus= ses transport mappings to QoS.

I understand from the draft this proposes default mappings for an RTCWeb us= e cases. As I see it, the present draft:

* Advocates use of separate QoS code points for different streaming compone= nts

* Describes both endpoint handling of priority for the media and transport = priority/precedence (aka DSCP).

* Proposes formalising a mapping between specific DSCPs and subnetwork QoS = functions (LTE, WiFi - but not general Ethernet).

Please read this draft and comment on the list - we will table this for dis= cussion at the next IETF meeting.

Gorry

 

--_000_AAD74A5C56B6A249AA8C0D3B41F86990154362F4xmbalnx10ciscoc_-- From sdhesika@cisco.com Sun Jul 14 11:58:29 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABA521F9BA0 for ; Sun, 14 Jul 2013 11:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6utCm8oNoUvV for ; Sun, 14 Jul 2013 11:58:24 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4020521F8BCE for ; Sun, 14 Jul 2013 11:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3207; q=dns/txt; s=iport; t=1373828304; x=1375037904; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sW+/UxxUqBJ6NaDF0AnMbfMiRqJKcu9RDhmeWFVb7cU=; b=Nk3x47wBHtPsC0ex/LRM4ax5yx0zHY8Na3yliiEd1LKGX8kqI9eJFZpr SH8TFQeGlKKkrDKw/c8A/rjh3/MF3YCnU6fa1cqMdtIGHjpeUtdA47xcP 2K7ZA0PBaz49FlqzJNh6IhLoU3Vv4GESq3mqNm0+nYmTtxsrDoLEtg/pj M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAGHz4lGtJV2b/2dsb2JhbABZgwaBA8FOgQsWdIIjAQEBAQM6PwwEAgEIDgMEAQEBChQJBzIUCQgCBAENBQiICLVPjzMxBwaDBW0DqSmDEoIo X-IronPort-AV: E=Sophos;i="4.89,664,1367971200"; d="scan'208";a="234688500" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 14 Jul 2013 18:58:20 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6EIwJEw002224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Jul 2013 18:58:19 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.98]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Sun, 14 Jul 2013 13:58:19 -0500 From: "Subha Dhesikan (sdhesika)" To: Wesley Eddy , Cullen Jennings Thread-Topic: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos Thread-Index: AQHOfDPkDNpbXj+NgEGu2r18jaM2u5ldjZgAgAb/KbA= Date: Sun, 14 Jul 2013 18:58:19 +0000 Message-ID: References: <32AE7F11-A06E-40C1-A73C-5C69F252DAF9@iii.ca> <51DCCD64.2050405@mti-systems.com> In-Reply-To: <51DCCD64.2050405@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.24.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DAN DRUTA , "tsvwg@ietf.org" Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 18:58:29 -0000 Wes, In my view, this draft important since it does provides guidance on a coup= le of fronts such as what the browser needs to do and what the application = Javascript needs to do. Also, it helps to clarify what inputs will be rece= ived from the application and what inputs are provided by the browser to th= e media engine. That is the key value of the draft.=20 I understand that there will be an added complexity when the flow is no lon= ger the traditional 5 tuple but a single flow can have multiple DSCP values= . However, it is not a concept introduced by this draft. When applications = have started allowing multiplexing of different types of traffic into a si= ngle flow, the need has already been created. Not only in the webrtc space = but also in the VDI space it is common to see flow that have multiplexed co= ntent. While we can restrict the QoS for multiplexed flows by saying only o= ne DSCP allowed per flow, my experience has been that it is tremendously ch= allenging for QoS to be relevant in such deployments. =20 Having said the above, my draft does not either mandate a single or multipl= e DSCP for multiplexed flow. One can always negotiate the lack of support = for multiplexed flow in which case single flows will be used with one DSCP = per flow. Unfortunately, I will not be in Berlin. I am hoping that Cullen, Dan and yo= u can chat some more if this continues to be an issue. Regards, Subha -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of W= esley Eddy Sent: Tuesday, July 09, 2013 7:57 PM To: Cullen Jennings Cc: DAN DRUTA; tsvwg@ietf.org Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos On 7/8/2013 7:35 PM, Cullen Jennings wrote: >=20 > The draft-dhesikan-tsvwg-rtcweb-qos draft was discussed extensively when = it was an individual draft then WG draft in another WG and I don't think th= ere is much more to say about it. This is one of the normative dependencies= of the webrtc work and that stuff is already getting implemented in browse= rs so I want to move this along in an expedient fashion.=20 Without checking ... it makes no sense to me that there would be a normativ= e dependency on this since it does not impact the interoperability or corre= ctness of an implementation. It's purely a performance enhancement, if/when it actually causes the inten= ded things to happen in the network. That said, I think the interesting facet of this document is that packets w= ithin the same flow (defined by 5-tuple of address-port pairs and protocol = number) are receiving different codepoints, and the implications of that fo= r a CC that may be on top of them need to be delved into. There isn't real= ly text or recommendations going into that, which seems to be the important= part, as if you can figure that out, these mappings are the more obvious p= art. So, I think it might make sense to do this, but the current document isn't = addressing the implications or how this works in a bigger system sense, and= I don't think the particular marking tables are the hard or important part= . -- Wes Eddy MTI Systems From brian.e.carpenter@gmail.com Sun Jul 14 13:08:14 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A378821F9AF3 for ; Sun, 14 Jul 2013 13:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.218 X-Spam-Level: X-Spam-Status: No, score=-102.218 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsbUJ9PAnMhu for ; Sun, 14 Jul 2013 13:08:14 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id E178221F9133 for ; Sun, 14 Jul 2013 13:08:13 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id q10so10049090pdj.38 for ; Sun, 14 Jul 2013 13:08:11 -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=yjrz7Lv8F3FJZj/e5RpLWuKYpSioLAhFljltboIwSg4=; b=lUMsOwRwI5jV7w5DhXL/agqXHExS6edsfUbsVflg02Z5n6eJQQV5co4rbXMT+WHSJM wCLJ6FTsJ2+vynxK4XwHduoVYevyXZnmmxtg5E1XNief1ssB50BWSK3p80dDM7YGFauZ GLS9LGqoZDppo1lPDIIIxLhpZL2blg2mv5zXFXXBO8+8rJLJpuTaeHNPIkYU3wjbJ/MX Jvzmek/yj5MActJt5nlxXPFPduZhAOrJB67c85HKD5wLbrjEAdKrj90QQmt5HZRvMy9b 4jnjKcCb6g3VB2dKLG+30v4sb3R2md9iSgTMQ7+p7TYZlG3VwnMnjKmhg5Z96wpIc+cj 1aPA== X-Received: by 10.66.160.74 with SMTP id xi10mr53026618pab.8.1373832491860; Sun, 14 Jul 2013 13:08:11 -0700 (PDT) Received: from [192.168.178.23] (163.194.69.111.dynamic.snap.net.nz. [111.69.194.163]) by mx.google.com with ESMTPSA id p2sm60259456pag.22.2013.07.14.13.08.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Jul 2013 13:08:11 -0700 (PDT) Message-ID: <51E30523.2090805@gmail.com> Date: Mon, 15 Jul 2013 08:08:03 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Subha Dhesikan (sdhesika)" References: <32AE7F11-A06E-40C1-A73C-5C69F252DAF9@iii.ca> <51DBC3D3.3000300@erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "gorry@erg.abdn.ac.uk" , tsvwg , Andrew McGregor Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 20:08:14 -0000 On 15/07/2013 06:46, Subha Dhesikan (sdhesika) wrote: ... > The other challenge I see is with the relative position of the values being different from what is traditionally known for DSCP where EF> AF4x >AF3x>... How have you handled it so far in a non-web rtc environment? I don't track rtcweb and have no intention of doing so, but what on earth do you mean by writing an inequality for DSCPs? DSCPs do not specify a priority order; they identify (locally) a PHB, which is essentially a queuing disciplime. Suggesting that EF is "greater" than an AF behaviour is just wrong. Brian From andrewmcgr@google.com Sun Jul 14 13:25:14 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70DF21F922A for ; Sun, 14 Jul 2013 13:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cQVEIwEZyXj for ; Sun, 14 Jul 2013 13:25:14 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA6421F9D50 for ; Sun, 14 Jul 2013 13:25:13 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id hu16so1250766qab.15 for ; Sun, 14 Jul 2013 13:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w8Nimjwe3XmQHySgcoecDeYIsf0+sNgkcjGXMcxlSl4=; b=HxCd9CUvvOEOWkYwr55ovtY2d2RzfEpPq0B7mfKVls+YsNV9rK2EDHam3be2ojWboi p2v9S2tfAXUT58fyRa8qFmKt7YmzQtuwheft7XyId6hbgyLVVAv0BGvlXg/YBwzDOfm4 VlKHd7TmW2sWapZSSUDf7T2jKHVkPeM3ToOYMfudfxcXK7HtpqcQOcFFvOEDMmSKrDoD Rps5mVASTt6imr+JXF0Yt0Y1MjjpvykiGfPnDlWyAtbkpSdKMsiLdbVrn0n82URWveZn wZaj/pqpC85GXlwfftW0D4io/QczPQn/pgtljKDwlxeMDVN/lyTyYtoJNpQVHK3UTYTo io+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=w8Nimjwe3XmQHySgcoecDeYIsf0+sNgkcjGXMcxlSl4=; b=LRjWvTEus6B8p8LznkHt3plLqM0ct1/rKXge7QKneqSHfuAZL9MYy2qgpWvSPZRy3c sxJNYEEvpggBC1Djk1WO8QTn5Kwv6meMtOVWQaKOHW08/17+Xs3aHPy/QYswkGaPZcHn +YIzehRYGRG9mRhKfym5sunPoTasgGxPtbjTHjNk3HoDN6vErJFanuxBpfTkFb6A6Src 4TkHPdKqoiT2JO1WsDRBRkmz3cMCw4K5cKbhLpyduDqrKQEWCQTnzjmitZ9xcbvXIqQN CzhSzUkxdK2atpuMawiJB4hJ67ODLaPVR2pjoD5XC0/xyUeDxAb20F2TIYkFbAp84QH7 /oyQ== MIME-Version: 1.0 X-Received: by 10.224.4.133 with SMTP id 5mr49244199qar.109.1373833513429; Sun, 14 Jul 2013 13:25:13 -0700 (PDT) Received: by 10.224.137.196 with HTTP; Sun, 14 Jul 2013 13:25:13 -0700 (PDT) In-Reply-To: <51E30523.2090805@gmail.com> References: <32AE7F11-A06E-40C1-A73C-5C69F252DAF9@iii.ca> <51DBC3D3.3000300@erg.abdn.ac.uk> <51E30523.2090805@gmail.com> Date: Mon, 15 Jul 2013 06:25:13 +1000 Message-ID: From: Andrew Mcgregor To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a11c221088c83d604e17e8abc X-Gm-Message-State: ALoCoQlYcU/cIYcNpLbCe90j3gGo4PR1Wu+5TIgXAnctSl3DXnfnm8xbbJOy8aQp48ne4vnVsRDhfeo57SzoKMVh+udP2Zbc566zT5qjFGdNqqJ4fEfEOpqnSg3x9sCTi4NNdxPwiIOieO8czq4bQ3vhEgqRY4tXnZK6QHtFiQOE8+kOH2EYrMccNUokr6brTIIP+GKdtQfV Cc: "gorry@erg.abdn.ac.uk" , tsvwg , Andrew McGregor Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 20:25:15 -0000 --001a11c221088c83d604e17e8abc Content-Type: text/plain; charset=ISO-8859-1 Nevertheless, specifying a priority order is exactly what tc_prio and pfifo_fast do... I agree it's wrong, but that's what a very large number of existing devices do right now, and ignoring that fact is likely to cause problems. Yes, this is unfortunately a mess, and I can't see a way to avoid that completely. The smaller set of codepoints I mention, AF42>AF33>AF21>(CS1 or BE), is not comprehensive, but is at least consistently ordered; the tc_prio map unfortunately makes EF unusable because it ends up equivalent to BE. To clarify a little, I'm saying that AF42, AF32, AF22 and AF12 are all the same so far as tc_prio is concerned, same for AF41, AF31, AF21 and AF11, and the same for AF[1234]3. So to get some consistency between the schemes, I have chosen for example AF42, which is in the highest priority band for both, AF33 for the second, AF21 for the third, and CS1 for the fourth, although even that is not ideal because it puts AF21 in a less-than-best-effort class while CS1 is equivalent to best-effort on the linux-based devices. There is considerable established practice within the game industry of using QoS codepoints that do map to tc_prio bands. Therefore there's a commonly deployed base of both low-end routers and code that depend on that behaviour, and attempting to standardise something that is inconsistent with it seems like an exercise in futility. I should point out that not every linux-based router does this, it is certainly possible to get 4594 behaviour, or ignore the TOS bits entirely, or do DPI to assign TOS, or remark, or pretty much any behaviour you might imagine. However, the majority of linux-based devices use very close to the default configuration of the IP stack. I believe rtcweb should be pragmatic about this, and accept that very fine-grained marking is not going to fly in the majority of cases on the edge of the internet, and take the benefits available from a restricted set of codepoints that are at least widely available, reasonably consistent in semantics, and commonly also result in correct behaviour from lower layers, particularly 802.1p and 802.11e MAC QoS. Andrew On 15 July 2013 06:08, Brian E Carpenter wrote: > On 15/07/2013 06:46, Subha Dhesikan (sdhesika) wrote: > ... > > The other challenge I see is with the relative position of the values > being different from what is traditionally known for DSCP where EF> AF4x > >AF3x>... How have you handled it so far in a non-web rtc environment? > > I don't track rtcweb and have no intention of doing so, but what on earth > do you > mean by writing an inequality for DSCPs? DSCPs do not specify a priority > order; they identify (locally) a PHB, which is essentially a queuing > disciplime. > Suggesting that EF is "greater" than an AF behaviour is just wrong. > > Brian > -- Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 --001a11c221088c83d604e17e8abc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Nevertheless, specifying a priority order is exactly = what tc_prio and pfifo_fast do... I agree it's wrong, but that's wh= at a very large number of existing devices do right now, and ignoring that = fact is likely to cause problems.

Yes, this is unfortunately a mess, and I can't see = a way to avoid that completely. =A0The smaller set of codepoints I mention,= AF42>AF33>AF21>(CS1 or BE), is not comprehensive, but is at least= consistently ordered; the tc_prio map unfortunately makes EF unusable beca= use it ends up equivalent to BE.

To clarify a little, I'm saying that AF42, AF32, AF= 22 and AF12 are all the same so far as tc_prio is concerned, same for AF41,= AF31, AF21 and AF11, and the same for AF[1234]3. =A0So to get some consist= ency between the schemes, I have chosen for example AF42, which is in the h= ighest priority band for both, AF33 for the second, AF21 for the third, and= CS1 for the fourth, although even that is not ideal because it puts AF21 i= n a less-than-best-effort class while CS1 is equivalent to best-effort on t= he linux-based devices.

There is considerable established practice within the g= ame industry of using QoS codepoints that do map to tc_prio bands. =A0There= fore there's a commonly deployed base of both low-end routers and code = that depend on that behaviour, and attempting to standardise something that= is inconsistent with it seems like an exercise in futility.

I should point out that not every linux-based router do= es this, it is certainly possible to get 4594 behaviour, or ignore the TOS = bits entirely, or do DPI to assign TOS, or remark, or pretty much any behav= iour you might imagine. =A0However, the majority of linux-based devices use= very close to the default configuration of the IP stack.

I believe rtcweb should be pragmatic about this, = and accept that very fine-grained marking is not going to fly in the majori= ty of cases on the edge of the internet, and take the benefits available fr= om a restricted set of codepoints that are at least widely available, reaso= nably consistent in semantics, and commonly also result in correct behaviou= r from lower layers, particularly 802.1p and 802.11e MAC QoS.

Andrew

=
On 15 July 2013 06:08, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 15/07/2013 06:46, Subha Dhesikan (sdhesik= a) wrote:
...
> The other challenge I see is with the relative position of the values = being different from what is traditionally known for DSCP where EF> AF4x= >AF3x>... How have you handled it so far in a non-web rtc environmen= t?

I don't track rtcweb and have no intention of doing so, but what on ear= th do you
mean by writing an inequality for DSCPs? DSCPs do not specify a priority order; they identify (locally) a PHB, which is essentially a queuing discip= lime.
Suggesting that EF is "greater" than an AF behaviour is just wron= g.

=A0 =A0Brian



--
Andrew McG= regor=A0|=A0SRE=A0|=A0andrewmcgr@google.com=A0|=A0+61 4 8143 7128
--001a11c221088c83d604e17e8abc-- From brian.e.carpenter@gmail.com Sun Jul 14 13:51:45 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32D521F99A0 for ; Sun, 14 Jul 2013 13:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.207 X-Spam-Level: X-Spam-Status: No, score=-102.207 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ky5jWnN0Q6Os for ; Sun, 14 Jul 2013 13:51:45 -0700 (PDT) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3F67E21F999E for ; Sun, 14 Jul 2013 13:51:45 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id un1so10636206pbc.29 for ; Sun, 14 Jul 2013 13:51:44 -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=RKUzyAIuM99ufeeEXOQrYjL7uE6a+i0bAifLIGd2ewQ=; b=PypRK8wEybrsoljoxDx/9nHIf6SSzY3YiMhGxX2UtaslkMOuoNw/zhs2eDgURPiHOf 4yZ71jg1MFMgT+/7GrBMiT5Le+N4rM0FRF9bJuFqEjdF2e9ddegWMQeJihioNUJ9M9lH vYnERcX1Kq0bZhdLmLMmKIJ+01tXpusyQdDKHyXSpuFYnB8oDavthFV7ixSBIzVRWEQ7 IwR5yu/PQDAJwY5XkiEG+GQ/EFC4gNdkZegGc+Hm0evSz4exxpH44ALkNW0Awsnj8qip XZAwQvrKzUJf/qBLu/buGld0wDC2wAcaMLZa8FFNTSmu4mcYF2vYF6MllMWyxv75O0+b FXKA== X-Received: by 10.68.170.227 with SMTP id ap3mr50408703pbc.194.1373835103978; Sun, 14 Jul 2013 13:51:43 -0700 (PDT) Received: from [192.168.178.23] (163.194.69.111.dynamic.snap.net.nz. [111.69.194.163]) by mx.google.com with ESMTPSA id eg3sm60449354pac.1.2013.07.14.13.51.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Jul 2013 13:51:43 -0700 (PDT) Message-ID: <51E30F5B.3080603@gmail.com> Date: Mon, 15 Jul 2013 08:51:39 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andrew Mcgregor References: <32AE7F11-A06E-40C1-A73C-5C69F252DAF9@iii.ca> <51DBC3D3.3000300@erg.abdn.ac.uk> <51E30523.2090805@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "gorry@erg.abdn.ac.uk" , tsvwg , Andrew McGregor Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 20:51:45 -0000 On 15/07/2013 08:25, Andrew Mcgregor wrote: > Nevertheless, specifying a priority order is exactly what tc_prio and > pfifo_fast do... I agree it's wrong, but that's what a very large number of > existing devices do right now, and ignoring that fact is likely to cause > problems. > > Yes, this is unfortunately a mess, and I can't see a way to avoid that > completely. The smaller set of codepoints I mention, AF42>AF33>AF21>(CS1 > or BE), is not comprehensive, but is at least consistently ordered; the > tc_prio map unfortunately makes EF unusable because it ends up equivalent > to BE. > > To clarify a little, I'm saying that AF42, AF32, AF22 and AF12 are all the > same so far as tc_prio is concerned, same for AF41, AF31, AF21 and AF11, > and the same for AF[1234]3. So to get some consistency between the > schemes, I have chosen for example AF42, which is in the highest priority > band for both, AF33 for the second, AF21 for the third, and CS1 for the > fourth, although even that is not ideal because it puts AF21 in a > less-than-best-effort class while CS1 is equivalent to best-effort on the > linux-based devices. In that case, the error is using the PHB names in the first place. The behaviours you're describing are *not* the PHBs whose names you are using. They need new names that describe them correctly. To reiterate, the binding between a behaviour such as EF or AFxy and a particular DSCP value is locally defined. If the behaviour is in fact simple preemptive priority, please don't call it something else. The fact that Linux gets it wrong doesn't mean IETF documents should be wrong too. Brian > > There is considerable established practice within the game industry of > using QoS codepoints that do map to tc_prio bands. Therefore there's a > commonly deployed base of both low-end routers and code that depend on that > behaviour, and attempting to standardise something that is inconsistent > with it seems like an exercise in futility. > > I should point out that not every linux-based router does this, it is > certainly possible to get 4594 behaviour, or ignore the TOS bits entirely, > or do DPI to assign TOS, or remark, or pretty much any behaviour you might > imagine. However, the majority of linux-based devices use very close to > the default configuration of the IP stack. > > I believe rtcweb should be pragmatic about this, and accept that very > fine-grained marking is not going to fly in the majority of cases on the > edge of the internet, and take the benefits available from a restricted set > of codepoints that are at least widely available, reasonably consistent in > semantics, and commonly also result in correct behaviour from lower layers, > particularly 802.1p and 802.11e MAC QoS. > > Andrew > > > On 15 July 2013 06:08, Brian E Carpenter wrote: > >> On 15/07/2013 06:46, Subha Dhesikan (sdhesika) wrote: >> ... >>> The other challenge I see is with the relative position of the values >> being different from what is traditionally known for DSCP where EF> AF4x >>> AF3x>... How have you handled it so far in a non-web rtc environment? >> I don't track rtcweb and have no intention of doing so, but what on earth >> do you >> mean by writing an inequality for DSCPs? DSCPs do not specify a priority >> order; they identify (locally) a PHB, which is essentially a queuing >> disciplime. >> Suggesting that EF is "greater" than an AF behaviour is just wrong. >> >> Brian >> > > > From sdhesika@cisco.com Sun Jul 14 13:56:12 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DDD21F9974 for ; Sun, 14 Jul 2013 13:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXBlZAtZdgyl for ; Sun, 14 Jul 2013 13:56:07 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A291B21F9943 for ; Sun, 14 Jul 2013 13:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1946; q=dns/txt; s=iport; t=1373835365; x=1375044965; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6bVWfpUoyTnNgeIq7v0JnDJPdfY2Ggt3BV1PLu1CX4A=; b=OEaxGw4FOkAboTVtX9DH/yLHvkuIgl5tpj5Ho6YJZuJuvxul9zxUav5r wRaZ7ir5mH6gWWXNGU4Mmjsl5y/sm1x1DtVHMfOHaqpQpTG4snz6IkQDO FsXFsDlckBe3ynSt3IvMZqkyvSfol5rlUokq3jtch5PosaU9dM+fvO7xD 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAPAP41GtJV2a/2dsb2JhbABQCoMGgQODBr5IF3UWdIIjAQEBAQMjET4HDAQCAQgRBAEBAwIGHQMCAgIfERQBCAgCBA4FCId2Aw+kaId2DYhegSaLVIEugQsWGwcGglIzbQOUBYFujhCFJoMSgig X-IronPort-AV: E=Sophos;i="4.89,664,1367971200"; d="scan'208";a="234506693" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 14 Jul 2013 20:56:05 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6EKu57v016202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Jul 2013 20:56:05 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.98]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Sun, 14 Jul 2013 15:56:04 -0500 From: "Subha Dhesikan (sdhesika)" To: Brian E Carpenter Thread-Topic: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos Thread-Index: AQHOfDPkDNpbXj+NgEGu2r18jaM2u5lcUQSAgAAdRYCACBjFMIAAcAyA//+2JnA= Date: Sun, 14 Jul 2013 20:56:03 +0000 Message-ID: References: <32AE7F11-A06E-40C1-A73C-5C69F252DAF9@iii.ca> <51DBC3D3.3000300@erg.abdn.ac.uk> <51E30523.2090805@gmail.com> In-Reply-To: <51E30523.2090805@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.24.37] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "gorry@erg.abdn.ac.uk" , tsvwg , Andrew McGregor Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 20:56:12 -0000 QnJpYW4sDQoNCldoYXQgSSBtZWFuIGJ5IGluZXF1YWxpdHkgYW5kIHByaW9yaXR5ICBpcyBtZXJl bHkgdXNpbmcgd29yZHMgdG8gZGVzY3JpYmUgdGhlIHJlbGF0aW9uc2hpcCBkZXNjcmliZWQgYnkg QW5kcmV3LiAgVGhlIHBvaW50IGlzIHRoYXQgaWYgSSBtYXJrIHNvbWV0aGluZyBhcyBFRiBJIGFt IGV4cGVjdGluZyBzdHJpY3QgcHJpb3JpdHksIGEgUEhCIHRoYXQgaXMgbm90IGRlbGl2ZXJlZCBi eSB0aGUgQUYgY2xhc3MuIEFsc28sIEkgZG9uJ3QgZXhwZWN0IHRoYXQgYSBwYWNrZXQgbWFya2Vk IHdpdGggRUYgUEhCIHRvIGdldCBhIEFGMnggUEhCLiAgSGVuY2UsIHBlcmhhcHMsIGEgcG9vciBj aG9pY2Ugb2Ygd29yZHMgYnV0IHRoZSBlc3NlbmNlIHJlZmVycyB0byB0aGUgYmVoYXZpb3Igb2Yg d2hhdCBoYXMgYmVlbiBkZXNjcmliZWQgYXMgcG9wdWxhcmx5IGRlcGxveWVkLiANCg0KVGhpcyBp cyB3aHkgSSBoYXZlIHNvdWdodCB0byB1bmRlcnN0YW5kIGZyb20gQW5kcmV3IGhvdyB0aGlzIGlz IGJlaW5nIGhhbmRsZWQgdG9kYXkuDQoNClJlZ2FyZHMsDQpTdWJoYQ0KDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4u ZS5jYXJwZW50ZXJAZ21haWwuY29tXSANClNlbnQ6IFN1bmRheSwgSnVseSAxNCwgMjAxMyAxOjA4 IFBNDQpUbzogU3ViaGEgRGhlc2lrYW4gKHNkaGVzaWthKQ0KQ2M6IEFuZHJldyBNY0dyZWdvcjsg Z29ycnlAZXJnLmFiZG4uYWMudWs7IHRzdndnDQpTdWJqZWN0OiBSZTogW3RzdndnXSBkcmFmdC1k aGVzaWthbi10c3Z3Zy1ydGN3ZWItcW9zDQoNCk9uIDE1LzA3LzIwMTMgMDY6NDYsIFN1YmhhIERo ZXNpa2FuIChzZGhlc2lrYSkgd3JvdGU6DQouLi4NCj4gVGhlIG90aGVyIGNoYWxsZW5nZSBJIHNl ZSBpcyB3aXRoIHRoZSByZWxhdGl2ZSBwb3NpdGlvbiBvZiB0aGUgdmFsdWVzIGJlaW5nIGRpZmZl cmVudCBmcm9tIHdoYXQgaXMgdHJhZGl0aW9uYWxseSBrbm93biBmb3IgRFNDUCB3aGVyZSBFRj4g QUY0eCA+QUYzeD4uLi4gSG93IGhhdmUgeW91IGhhbmRsZWQgaXQgc28gZmFyIGluIGEgbm9uLXdl YiBydGMgZW52aXJvbm1lbnQ/DQoNCkkgZG9uJ3QgdHJhY2sgcnRjd2ViIGFuZCBoYXZlIG5vIGlu dGVudGlvbiBvZiBkb2luZyBzbywgYnV0IHdoYXQgb24gZWFydGggZG8geW91IG1lYW4gYnkgd3Jp dGluZyBhbiBpbmVxdWFsaXR5IGZvciBEU0NQcz8gRFNDUHMgZG8gbm90IHNwZWNpZnkgYSBwcmlv cml0eSBvcmRlcjsgdGhleSBpZGVudGlmeSAobG9jYWxseSkgYSBQSEIsIHdoaWNoIGlzIGVzc2Vu dGlhbGx5IGEgcXVldWluZyBkaXNjaXBsaW1lLg0KU3VnZ2VzdGluZyB0aGF0IEVGIGlzICJncmVh dGVyIiB0aGFuIGFuIEFGIGJlaGF2aW91ciBpcyBqdXN0IHdyb25nLg0KDQogICBCcmlhbg0K From sdhesika@cisco.com Sun Jul 14 14:03:05 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2BE521F9BC0 for ; Sun, 14 Jul 2013 14:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkRETrZh8a6n for ; Sun, 14 Jul 2013 14:03:00 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAC821F997D for ; Sun, 14 Jul 2013 14:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5884; q=dns/txt; s=iport; t=1373835780; x=1375045380; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RAcsw1VcQVBZcTv91t6XG/7ozlo3Ei8NBTRROkP66KY=; b=hC4l4/8HozRTCrJrATd21wcEfl5wrq/35d7+eWjvK/v5y7fzRhBGGBEi OILaQftDUzGugBNNcQVa9IvDK/U3rf9U6fOadO+CL0SzYLYSxf56fbfx5 ILbeRfU2HzijrBdayNZvEIjHnvXqeGIltzTHk+B2gHsoz4o1I5po92rk4 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAHsQ41GtJXG8/2dsb2JhbABQCoMGgQODBr5IF3UWdIIjAQEBAQIBIxFFDAQCAQgRBAEBAQICBh0DAgICHxEUAQgIAgQBDQUIh3YDCQakaId2DYhegSaLVIEugQsWGwcGglIzbQOUBYFujhCFJoMSgig X-IronPort-AV: E=Sophos;i="4.89,664,1367971200"; d="scan'208";a="231703370" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 14 Jul 2013 21:02:59 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6EL2xI9030349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Jul 2013 21:02:59 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.98]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Sun, 14 Jul 2013 16:02:59 -0500 From: "Subha Dhesikan (sdhesika)" To: Brian E Carpenter , Andrew Mcgregor Thread-Topic: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos Thread-Index: AQHOfDPkDNpbXj+NgEGu2r18jaM2u5lcUQSAgAAdRYCACBjFMIAAcAyAgAAEzICAAAdjgP//rjkg Date: Sun, 14 Jul 2013 21:02:58 +0000 Message-ID: References: <32AE7F11-A06E-40C1-A73C-5C69F252DAF9@iii.ca> <51DBC3D3.3000300@erg.abdn.ac.uk> <51E30523.2090805@gmail.com> <51E30F5B.3080603@gmail.com> In-Reply-To: <51E30F5B.3080603@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.24.37] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "gorry@erg.abdn.ac.uk" , tsvwg , Andrew McGregor Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 21:03:05 -0000 SW5saW5lOg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQnJpYW4gRSBDYXJw ZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dIA0KU2VudDogU3VuZGF5 LCBKdWx5IDE0LCAyMDEzIDE6NTIgUE0NClRvOiBBbmRyZXcgTWNncmVnb3INCkNjOiBTdWJoYSBE aGVzaWthbiAoc2RoZXNpa2EpOyBnb3JyeUBlcmcuYWJkbi5hYy51azsgdHN2d2c7IEFuZHJldyBN Y0dyZWdvcg0KU3ViamVjdDogUmU6IFt0c3Z3Z10gZHJhZnQtZGhlc2lrYW4tdHN2d2ctcnRjd2Vi LXFvcw0KDQpPbiAxNS8wNy8yMDEzIDA4OjI1LCBBbmRyZXcgTWNncmVnb3Igd3JvdGU6DQo+IE5l dmVydGhlbGVzcywgc3BlY2lmeWluZyBhIHByaW9yaXR5IG9yZGVyIGlzIGV4YWN0bHkgd2hhdCB0 Y19wcmlvIGFuZCANCj4gcGZpZm9fZmFzdCBkby4uLiBJIGFncmVlIGl0J3Mgd3JvbmcsIGJ1dCB0 aGF0J3Mgd2hhdCBhIHZlcnkgbGFyZ2UgDQo+IG51bWJlciBvZiBleGlzdGluZyBkZXZpY2VzIGRv IHJpZ2h0IG5vdywgYW5kIGlnbm9yaW5nIHRoYXQgZmFjdCBpcyANCj4gbGlrZWx5IHRvIGNhdXNl IHByb2JsZW1zLg0KPiANCj4gWWVzLCB0aGlzIGlzIHVuZm9ydHVuYXRlbHkgYSBtZXNzLCBhbmQg SSBjYW4ndCBzZWUgYSB3YXkgdG8gYXZvaWQgdGhhdCANCj4gY29tcGxldGVseS4gIFRoZSBzbWFs bGVyIHNldCBvZiBjb2RlcG9pbnRzIEkgbWVudGlvbiwgDQo+IEFGNDI+QUYzMz5BRjIxPihDUzEg b3IgQkUpLCBpcyBub3QgY29tcHJlaGVuc2l2ZSwgYnV0IGlzIGF0IGxlYXN0IA0KPiBjb25zaXN0 ZW50bHkgb3JkZXJlZDsgdGhlIHRjX3ByaW8gbWFwIHVuZm9ydHVuYXRlbHkgbWFrZXMgRUYgdW51 c2FibGUgDQo+IGJlY2F1c2UgaXQgZW5kcyB1cCBlcXVpdmFsZW50IHRvIEJFLg0KPiANCj4gVG8g Y2xhcmlmeSBhIGxpdHRsZSwgSSdtIHNheWluZyB0aGF0IEFGNDIsIEFGMzIsIEFGMjIgYW5kIEFG MTIgYXJlIGFsbCANCj4gdGhlIHNhbWUgc28gZmFyIGFzIHRjX3ByaW8gaXMgY29uY2VybmVkLCBz YW1lIGZvciBBRjQxLCBBRjMxLCBBRjIxIGFuZCANCj4gQUYxMSwgYW5kIHRoZSBzYW1lIGZvciBB RlsxMjM0XTMuICBTbyB0byBnZXQgc29tZSBjb25zaXN0ZW5jeSBiZXR3ZWVuIA0KPiB0aGUgc2No ZW1lcywgSSBoYXZlIGNob3NlbiBmb3IgZXhhbXBsZSBBRjQyLCB3aGljaCBpcyBpbiB0aGUgaGln aGVzdCANCj4gcHJpb3JpdHkgYmFuZCBmb3IgYm90aCwgQUYzMyBmb3IgdGhlIHNlY29uZCwgQUYy MSBmb3IgdGhlIHRoaXJkLCBhbmQgDQo+IENTMSBmb3IgdGhlIGZvdXJ0aCwgYWx0aG91Z2ggZXZl biB0aGF0IGlzIG5vdCBpZGVhbCBiZWNhdXNlIGl0IHB1dHMgDQo+IEFGMjEgaW4gYSBsZXNzLXRo YW4tYmVzdC1lZmZvcnQgY2xhc3Mgd2hpbGUgQ1MxIGlzIGVxdWl2YWxlbnQgdG8gDQo+IGJlc3Qt ZWZmb3J0IG9uIHRoZSBsaW51eC1iYXNlZCBkZXZpY2VzLg0KDQpJbiB0aGF0IGNhc2UsIHRoZSBl cnJvciBpcyB1c2luZyB0aGUgUEhCIG5hbWVzIGluIHRoZSBmaXJzdCBwbGFjZS4gVGhlIGJlaGF2 aW91cnMgeW91J3JlIGRlc2NyaWJpbmcgYXJlICpub3QqIHRoZSBQSEJzIHdob3NlIG5hbWVzIHlv dSBhcmUgdXNpbmcuDQpUaGV5IG5lZWQgbmV3IG5hbWVzIHRoYXQgZGVzY3JpYmUgdGhlbSBjb3Jy ZWN0bHkuDQoNClRvIHJlaXRlcmF0ZSwgdGhlIGJpbmRpbmcgYmV0d2VlbiBhIGJlaGF2aW91ciBz dWNoIGFzIEVGIG9yIEFGeHkgYW5kIGEgcGFydGljdWxhciBEU0NQIHZhbHVlIGlzIGxvY2FsbHkg ZGVmaW5lZC4gSWYgdGhlIGJlaGF2aW91ciBpcyBpbiBmYWN0IHNpbXBsZSBwcmVlbXB0aXZlIHBy aW9yaXR5LCBwbGVhc2UgZG9uJ3QgY2FsbCBpdCBzb21ldGhpbmcgZWxzZS4gVGhlIGZhY3QgdGhh dCBMaW51eCBnZXRzIGl0IHdyb25nIGRvZXNuJ3QgbWVhbiBJRVRGIGRvY3VtZW50cyBzaG91bGQg YmUgd3JvbmcgdG9vLg0KDQpTRDogQW5kcmV3LCBteSBvcmlnaW5hbCByZWFjdGlvbiB3YXMgdGhl IHNhbWUgYXMgYWJvdmUuIEdpdmVuIHRoYXQgdGhlIHNvbWUgb2YgdGhlc2UgUEhCIGhhdmUgYmVl biBkZWZpbmVkIGZvciBvdmVyIGEgZGVjYWRlIGFuZCBSRkMgNDU5NCBoYXMgYWxzbyBiZWVuIGFy b3VuZCBmb3Igc29tZSB0aW1lLCBJIGNvdWxkIG5vdCBpbWFnaW5lIHdoYXQgY29uY2Vzc2lvbiBt eSBkb2N1bWVudCBjYW4gbWFrZSB0byBhbGxldmlhdGUgdGhlIHByb2JsZW0gd2l0aG91dCBpbXBh Y3RpbmcgYWxsIG90aGVyIGFwcGxpY2F0aW9uIGVudmlyb25tZW50cy4gSG93ZXZlciwgaWYgdGhl cmUgaXMgYSBwcmVjZWRlbmNlIG9mIGhvdyBpdCBpcyBiZWluZyBoYW5kbGVkLCBwbGVhc2Ugc2hh cmUuDQoNClJlZ2FyZHMsDQpTdWJoYQ0KDQogICBCcmlhbg0KDQo+IA0KPiBUaGVyZSBpcyBjb25z aWRlcmFibGUgZXN0YWJsaXNoZWQgcHJhY3RpY2Ugd2l0aGluIHRoZSBnYW1lIGluZHVzdHJ5IG9m IA0KPiB1c2luZyBRb1MgY29kZXBvaW50cyB0aGF0IGRvIG1hcCB0byB0Y19wcmlvIGJhbmRzLiAg VGhlcmVmb3JlIHRoZXJlJ3MgDQo+IGEgY29tbW9ubHkgZGVwbG95ZWQgYmFzZSBvZiBib3RoIGxv dy1lbmQgcm91dGVycyBhbmQgY29kZSB0aGF0IGRlcGVuZCANCj4gb24gdGhhdCBiZWhhdmlvdXIs IGFuZCBhdHRlbXB0aW5nIHRvIHN0YW5kYXJkaXNlIHNvbWV0aGluZyB0aGF0IGlzIA0KPiBpbmNv bnNpc3RlbnQgd2l0aCBpdCBzZWVtcyBsaWtlIGFuIGV4ZXJjaXNlIGluIGZ1dGlsaXR5Lg0KPiAN Cj4gSSBzaG91bGQgcG9pbnQgb3V0IHRoYXQgbm90IGV2ZXJ5IGxpbnV4LWJhc2VkIHJvdXRlciBk b2VzIHRoaXMsIGl0IGlzIA0KPiBjZXJ0YWlubHkgcG9zc2libGUgdG8gZ2V0IDQ1OTQgYmVoYXZp b3VyLCBvciBpZ25vcmUgdGhlIFRPUyBiaXRzIA0KPiBlbnRpcmVseSwgb3IgZG8gRFBJIHRvIGFz c2lnbiBUT1MsIG9yIHJlbWFyaywgb3IgcHJldHR5IG11Y2ggYW55IA0KPiBiZWhhdmlvdXIgeW91 IG1pZ2h0IGltYWdpbmUuICBIb3dldmVyLCB0aGUgbWFqb3JpdHkgb2YgbGludXgtYmFzZWQgDQo+ IGRldmljZXMgdXNlIHZlcnkgY2xvc2UgdG8gdGhlIGRlZmF1bHQgY29uZmlndXJhdGlvbiBvZiB0 aGUgSVAgc3RhY2suDQo+IA0KPiBJIGJlbGlldmUgcnRjd2ViIHNob3VsZCBiZSBwcmFnbWF0aWMg YWJvdXQgdGhpcywgYW5kIGFjY2VwdCB0aGF0IHZlcnkgDQo+IGZpbmUtZ3JhaW5lZCBtYXJraW5n IGlzIG5vdCBnb2luZyB0byBmbHkgaW4gdGhlIG1ham9yaXR5IG9mIGNhc2VzIG9uIA0KPiB0aGUg ZWRnZSBvZiB0aGUgaW50ZXJuZXQsIGFuZCB0YWtlIHRoZSBiZW5lZml0cyBhdmFpbGFibGUgZnJv bSBhIA0KPiByZXN0cmljdGVkIHNldCBvZiBjb2RlcG9pbnRzIHRoYXQgYXJlIGF0IGxlYXN0IHdp ZGVseSBhdmFpbGFibGUsIA0KPiByZWFzb25hYmx5IGNvbnNpc3RlbnQgaW4gc2VtYW50aWNzLCBh bmQgY29tbW9ubHkgYWxzbyByZXN1bHQgaW4gDQo+IGNvcnJlY3QgYmVoYXZpb3VyIGZyb20gbG93 ZXIgbGF5ZXJzLCBwYXJ0aWN1bGFybHkgODAyLjFwIGFuZCA4MDIuMTFlIE1BQyBRb1MuDQo+IA0K PiBBbmRyZXcNCj4gDQo+IA0KPiBPbiAxNSBKdWx5IDIwMTMgMDY6MDgsIEJyaWFuIEUgQ2FycGVu dGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+d3JvdGU6DQo+IA0KPj4gT24gMTUvMDcv MjAxMyAwNjo0NiwgU3ViaGEgRGhlc2lrYW4gKHNkaGVzaWthKSB3cm90ZToNCj4+IC4uLg0KPj4+ IFRoZSBvdGhlciBjaGFsbGVuZ2UgSSBzZWUgaXMgd2l0aCB0aGUgcmVsYXRpdmUgcG9zaXRpb24g b2YgdGhlIA0KPj4+IHZhbHVlcw0KPj4gYmVpbmcgZGlmZmVyZW50IGZyb20gd2hhdCBpcyB0cmFk aXRpb25hbGx5IGtub3duIGZvciBEU0NQIHdoZXJlIEVGPiANCj4+IEFGNHgNCj4+PiBBRjN4Pi4u LiBIb3cgaGF2ZSB5b3UgaGFuZGxlZCBpdCBzbyBmYXIgaW4gYSBub24td2ViIHJ0YyBlbnZpcm9u bWVudD8NCj4+IEkgZG9uJ3QgdHJhY2sgcnRjd2ViIGFuZCBoYXZlIG5vIGludGVudGlvbiBvZiBk b2luZyBzbywgYnV0IHdoYXQgb24gDQo+PiBlYXJ0aCBkbyB5b3UgbWVhbiBieSB3cml0aW5nIGFu IGluZXF1YWxpdHkgZm9yIERTQ1BzPyBEU0NQcyBkbyBub3QgDQo+PiBzcGVjaWZ5IGEgcHJpb3Jp dHkgb3JkZXI7IHRoZXkgaWRlbnRpZnkgKGxvY2FsbHkpIGEgUEhCLCB3aGljaCBpcyANCj4+IGVz c2VudGlhbGx5IGEgcXVldWluZyBkaXNjaXBsaW1lLg0KPj4gU3VnZ2VzdGluZyB0aGF0IEVGIGlz ICJncmVhdGVyIiB0aGFuIGFuIEFGIGJlaGF2aW91ciBpcyBqdXN0IHdyb25nLg0KPj4NCj4+ICAg IEJyaWFuDQo+Pg0KPiANCj4gDQo+IA0K From andrewmcgr@google.com Sun Jul 14 17:15:59 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1430721F9BF2 for ; Sun, 14 Jul 2013 17:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvj8Hdmh69FQ for ; Sun, 14 Jul 2013 17:15:58 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BDF0E21F9B8E for ; Sun, 14 Jul 2013 17:15:57 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id m15so5980274qcq.33 for ; Sun, 14 Jul 2013 17:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K3auZROxGd3QKgdN/+K9FoN3bSH69eyAQt44I2XkjNA=; b=lW/1QDYvjRazn0kSayXNGoYHvW4vgA3WbMmDUkSb1Nq8SHChlQysWrqfAKTXZMXNAa P87W+nQzyd7yczE95Lr4AMMKuWUwM8wJeUB/R3OZkcJ/ArlcI5jPpWdzUCwam1yip9yR cX/9gDun/pj0iYqQtnmyJewR4sXNmfrwginc/tz4UINjydxg1PvWwbpvksRvAU7QwRdH waUkFZ0EOxV4KaeqW+T0oMmY6Jyk3SMqQBjUbAI+KcpDl325xG+RGQE6Dkb/2bJ9SJEv hvtf8lRaHG5hdvboZP/DQWrWo/8apQ0BtO9TwbqIWinmdfNC4X4hrbBRB0NoA6Wyx1he nj6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=K3auZROxGd3QKgdN/+K9FoN3bSH69eyAQt44I2XkjNA=; b=ClQROaSY3+jzReH6Fu8yNfpjz+2aXejhGYaeCPk7OcBD/imHnMJOyRQprcXu22ZkGW HJDjzxrLfi5O4xKW0vtW807foFrAPuQ8V0cISH0P6wL+8E/Xib/+eoExOUMFAOMoVl27 MCA0YIMOf2ahUr2kdeViufrFIUwQm2RewSaAc8wM0YlM4G2KxLnmxB2Er+xYy/5qEC9k 9TSqvFb1qEk5rvrKbGOnpATi42zk6N/e4n0CALO/acDGvM/Zq+AdEqvgk9vqSdl8s8fx glFhuDnsDPlk5Ob6vuA6KZkwxaul2TCanq9ShQD46mHoSqdlu85qu1fj4D7SWyI34sbe ecQQ== MIME-Version: 1.0 X-Received: by 10.224.33.141 with SMTP id h13mr48576440qad.21.1373847356885; Sun, 14 Jul 2013 17:15:56 -0700 (PDT) Received: by 10.224.137.196 with HTTP; Sun, 14 Jul 2013 17:15:56 -0700 (PDT) In-Reply-To: <51E30F5B.3080603@gmail.com> References: <32AE7F11-A06E-40C1-A73C-5C69F252DAF9@iii.ca> <51DBC3D3.3000300@erg.abdn.ac.uk> <51E30523.2090805@gmail.com> <51E30F5B.3080603@gmail.com> Date: Mon, 15 Jul 2013 10:15:56 +1000 Message-ID: From: Andrew Mcgregor To: Brian E Carpenter Content-Type: multipart/alternative; boundary=20cf3074d2e4aee0df04e181c356 X-Gm-Message-State: ALoCoQmo//xk7b3c5UiAEjXhD/gjMFRgVClvuMesnA6VjNS8hVFJYUckQOwD3MUrU5gHJGkmtirNkh7OTJgTkvVT5aRuNOwLW2+1nGUjr0IN4DsYDaQV1Orctk+G3x2GYtTOHLT36kETWb/xkL7aogTS4wafgL5cb17oZmC9B9PgMlCvaUDPqdQ7CAKn0X/QURDUjovzSbTH Cc: "gorry@erg.abdn.ac.uk" , tsvwg , Andrew McGregor Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 00:15:59 -0000 --20cf3074d2e4aee0df04e181c356 Content-Type: text/plain; charset=ISO-8859-1 On 15 July 2013 06:51, Brian E Carpenter wrote: > On 15/07/2013 08:25, Andrew Mcgregor wrote: > > Nevertheless, specifying a priority order is exactly what tc_prio and > > pfifo_fast do... I agree it's wrong, but that's what a very large number > of > > existing devices do right now, and ignoring that fact is likely to cause > > problems. > > > > Yes, this is unfortunately a mess, and I can't see a way to avoid that > > completely. The smaller set of codepoints I mention, AF42>AF33>AF21>(CS1 > > or BE), is not comprehensive, but is at least consistently ordered; the > > tc_prio map unfortunately makes EF unusable because it ends up equivalent > > to BE. > > > > To clarify a little, I'm saying that AF42, AF32, AF22 and AF12 are all > the > > same so far as tc_prio is concerned, same for AF41, AF31, AF21 and AF11, > > and the same for AF[1234]3. So to get some consistency between the > > schemes, I have chosen for example AF42, which is in the highest priority > > band for both, AF33 for the second, AF21 for the third, and CS1 for the > > fourth, although even that is not ideal because it puts AF21 in a > > less-than-best-effort class while CS1 is equivalent to best-effort on the > > linux-based devices. > > In that case, the error is using the PHB names in the first place. The > behaviours you're describing are *not* the PHBs whose names you are using. > They need new names that describe them correctly. > Well, perhaps they do. However, using the RFC 4594 names for the bit patterns in the packets per figure 3 of that RFC, rather than the PHB definitions, those particular bit patterns get vaguely compatible treatment between some router behaving per RFC 4594 PHB definitions and something running pfifo_fast. That is my point. Perhaps we need another description of what is going on here, that's a separate question, but we have those five codepoints (and perhaps a few more, I didn't do an exhaustive search) that produce sensible behaviour in both RFC 4594 recommended behaviour and the more widely deployed pfifo_fast. More sensible names might well be those originally from 802.11e or 802.1p, whichever of those coined these, those being VO ('voice'), VI ('video/interactive'), BE ('best effort') and BK ('background'), in which case we have from my earlier example: RFC 4594 name -> 802 name (TOS bit pattern) AF42 -> VO (100100) AF33 -> VI (011110) AF21 -> BK (010010) BE -> BE (000000) CS1 -> BE (001000) (possibly, the different code point in this case saying 'BE, and I really mean that, this is not just default') Using this set of bit patterns, the queueing behaviour will be correct on many, perhaps most, existing access networks AND the 802 layer queueing will be correct as well on a subset of those. This would be a win, in general. It will also cause something sensible to happen in a network using the mapping from RFC 4594 figure 3. To reiterate, the binding between a behaviour such as EF or AFxy and a > particular > DSCP value is locally defined. If the behaviour is in fact simple > preemptive > priority, please don't call it something else. The fact that Linux gets it > wrong doesn't mean IETF documents should be wrong too. > I believe that that local definition of the binding is a catastrophic bug in the diffserv specs, and should never have been published in that form. However, too late now. There is absolutely no way to tell an application correctly what it should do with those bits unless there is an agreed set of default meanings for at least some of the codepoints; maybe not total specification of the exact behaviour, that's impractical, but at least a way of setting some expectations. If rtcweb continues with the code point recommendations in the draft as it stands, code written to those recommendations will be quite seriously broken when deployed. The predictable outcome will be 'so turn off the marking', and yet again an opportunity to do something sensible and pragmatic with this feature is missed. Let's not allow that to happen simply because of terminology. By saying 5 out of 64 codepoints should have reasonable default behaviours, we might actually get this deployed. > > Brian > > > > > There is considerable established practice within the game industry of > > using QoS codepoints that do map to tc_prio bands. Therefore there's a > > commonly deployed base of both low-end routers and code that depend on > that > > behaviour, and attempting to standardise something that is inconsistent > > with it seems like an exercise in futility. > > > > I should point out that not every linux-based router does this, it is > > certainly possible to get 4594 behaviour, or ignore the TOS bits > entirely, > > or do DPI to assign TOS, or remark, or pretty much any behaviour you > might > > imagine. However, the majority of linux-based devices use very close to > > the default configuration of the IP stack. > > > > I believe rtcweb should be pragmatic about this, and accept that very > > fine-grained marking is not going to fly in the majority of cases on the > > edge of the internet, and take the benefits available from a restricted > set > > of codepoints that are at least widely available, reasonably consistent > in > > semantics, and commonly also result in correct behaviour from lower > layers, > > particularly 802.1p and 802.11e MAC QoS. > > > > Andrew > > > > > > On 15 July 2013 06:08, Brian E Carpenter >wrote: > > > >> On 15/07/2013 06:46, Subha Dhesikan (sdhesika) wrote: > >> ... > >>> The other challenge I see is with the relative position of the values > >> being different from what is traditionally known for DSCP where EF> AF4x > >>> AF3x>... How have you handled it so far in a non-web rtc environment? > >> I don't track rtcweb and have no intention of doing so, but what on > earth > >> do you > >> mean by writing an inequality for DSCPs? DSCPs do not specify a priority > >> order; they identify (locally) a PHB, which is essentially a queuing > >> disciplime. > >> Suggesting that EF is "greater" than an AF behaviour is just wrong. > >> > >> Brian > >> > > > > > > > -- Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 --20cf3074d2e4aee0df04e181c356 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 15 July 2013 06:51, Brian E Carpenter <brian.e.carpen= ter@gmail.com> wrote:
On 15/07/2013 08:25, Andrew Mcgregor wro= te:
> Nevertheless, specifying a priority order is exactly what tc_prio and<= br> > pfifo_fast do... I agree it's wrong, but that's what a very la= rge number of
> existing devices do right now, and ignoring that fact is likely to cau= se
> problems.
>
> Yes, this is unfortunately a mess, and I can't see a way to avoid = that
> completely. =A0The smaller set of codepoints I mention, AF42>AF33&g= t;AF21>(CS1
> or BE), is not comprehensive, but is at least consistently ordered; th= e
> tc_prio map unfortunately makes EF unusable because it ends up equival= ent
> to BE.
>
> To clarify a little, I'm saying that AF42, AF32, AF22 and AF12 are= all the
> same so far as tc_prio is concerned, same for AF41, AF31, AF21 and AF1= 1,
> and the same for AF[1234]3. =A0So to get some consistency between the<= br> > schemes, I have chosen for example AF42, which is in the highest prior= ity
> band for both, AF33 for the second, AF21 for the third, and CS1 for th= e
> fourth, although even that is not ideal because it puts AF21 in a
> less-than-best-effort class while CS1 is equivalent to best-effort on = the
> linux-based devices.

In that case, the error is using the PHB names in the first place. Th= e
behaviours you're describing are *not* the PHBs whose names you are usi= ng.
They need new names that describe them correctly.

=
Well, perhaps they do. =A0However, using the RFC 4594 name= s for the bit patterns in the packets per figure 3 of that RFC, rather than= the PHB definitions, those particular bit patterns get vaguely compatible = treatment between some router behaving per RFC 4594 PHB definitions and som= ething running pfifo_fast. =A0That is my point.

Perhaps we need another description of what= is going on here, that's a separate question, but we have those five c= odepoints (and perhaps a few more, I didn't do an exhaustive search) th= at produce sensible behaviour in both RFC 4594 recommended behaviour and th= e more widely deployed pfifo_fast.

More sensible names might well be those ori= ginally from 802.11e or 802.1p, whichever of those coined these, those bein= g VO ('voice'), VI ('video/interactive'), BE ('best eff= ort') and BK ('background'), in which case we have from my earl= ier example:

RFC 4594 name -> 802 name (TOS bit patte= rn)
AF42 -> VO (100100)
AF33 -> VI (011110)
AF21 -> BK (010010)
BE -> BE (000000)=
CS1 -> BE (001000) (possibly, the dif= ferent code point in this case saying 'BE, and I really mean that, this= is not just default')
<= br>
Using this set of bit patte= rns, the queueing behaviour will be correct on many, perhaps most, existing= access networks AND the 802 layer queueing will be correct as well on a su= bset of those. =A0This would be a win, in general. =A0It will also cause so= mething sensible to happen in a network using the mapping from RFC 4594 fig= ure 3.

To reiterate, the binding between a behaviour such as EF or AFxy and a part= icular
DSCP value is locally defined. If the behaviour is in fact simple preemptiv= e
priority, please don't call it something else. The fact that Linux gets= it
wrong doesn't mean IETF documents should be wrong too.
=

I believe that that local definition of the bindi= ng is a catastrophic bug in the diffserv specs, and should never have been = published in that form. =A0However, too late now. =A0There is absolutely no= way to tell an application correctly what it should do with those bits unl= ess there is an agreed set of default meanings for at least some of the cod= epoints; maybe not total specification of the exact behaviour, that's i= mpractical, but at least a way of setting some expectations.

If rtcweb continues with the code point rec= ommendations in the draft as it stands, code written to those recommendatio= ns will be quite seriously broken when deployed. =A0The predictable outcome= will be 'so turn off the marking', and yet again an opportunity to= do something sensible and pragmatic with this feature is missed. =A0Let= 9;s not allow that to happen simply because of terminology. =A0By saying 5 = out of 64 codepoints should have reasonable default behaviours, we might ac= tually get this deployed.
=A0

=A0 =A0Brian

>
> There is considerable established practice within the game industry of=
> using QoS codepoints that do map to tc_prio bands. =A0Therefore there&= #39;s a
> commonly deployed base of both low-end routers and code that depend on= that
> behaviour, and attempting to standardise something that is inconsisten= t
> with it seems like an exercise in futility.
>
> I should point out that not every linux-based router does this, it is<= br> > certainly possible to get 4594 behaviour, or ignore the TOS bits entir= ely,
> or do DPI to assign TOS, or remark, or pretty much any behaviour you m= ight
> imagine. =A0However, the majority of linux-based devices use very clos= e to
> the default configuration of the IP stack.
>
> I believe rtcweb should be pragmatic about this, and accept that very<= br> > fine-grained marking is not going to fly in the majority of cases on t= he
> edge of the internet, and take the benefits available from a restricte= d set
> of codepoints that are at least widely available, reasonably consisten= t in
> semantics, and commonly also result in correct behaviour from lower la= yers,
> particularly 802.1p and 802.11e MAC QoS.
>
> Andrew
>
>
> On 15 July 2013 06:08, Brian E Carpenter <brian.e.carpenter@gmail.com>wrote:
>
>> On 15/07/2013 06:46, Subha Dhesikan (sdhesika) wrote:
>> ...
>>> The other challenge I see is with the relative position of the= values
>> being different from what is traditionally known for DSCP where EF= > AF4x
>>> AF3x>... How have you handled it so far in a non-web rtc en= vironment?
>> I don't track rtcweb and have no intention of doing so, but wh= at on earth
>> do you
>> mean by writing an inequality for DSCPs? DSCPs do not specify a pr= iority
>> order; they identify (locally) a PHB, which is essentially a queui= ng
>> disciplime.
>> Suggesting that EF is "greater" than an AF behaviour is = just wrong.
>>
>> =A0 =A0Brian
>>
>
>
>



--
=
Andrew McGre= gor=A0|=A0SRE=A0|=A0andrewmcgr@google.com=A0|=A0+61 4 8143 7128
--20cf3074d2e4aee0df04e181c356-- From brian.e.carpenter@gmail.com Sun Jul 14 22:02:17 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1FF21F9B4B for ; Sun, 14 Jul 2013 22:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnKX4NFRvPvl for ; Sun, 14 Jul 2013 22:02:17 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id DAA5321F8526 for ; Sun, 14 Jul 2013 22:02:16 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id um15so10915338pbc.10 for ; Sun, 14 Jul 2013 22:02:16 -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=glXx04Za3RP9wHybIj25QSMyCVAc5fOnWzpp+DVhkko=; b=j9Lt+wcOcszolbwW1LrxODmvSd3gA05+YKvpALyarmkAFg9eyllaAwKhn5qOI13yLc eVHy+JmKtWXbZXnmamz54va5y5U4IksUaelU9ZtMsIaDAlj/Ec+8j7kAI7d0meEzA+r5 Hm15bh9X/TAL1SgdzG1ySarqmMVPqIHcg8X1JKD4mspNwa6avOjPueapQfWl4sFMx0NU MZ84HRoRYKK6l1sBM8ycHZP1v69MeevrZnc9dl/yLTM5AVEtox67MJqDqATU/H7pXCeK F6sUSgMZKqpHGA0622nd4XQx9jo4+IyxNLqxpNXDVOTuW+LI7S+tcj9rqYLBxOEhII79 ZpLA== X-Received: by 10.68.212.229 with SMTP id nn5mr52033979pbc.44.1373864536532; Sun, 14 Jul 2013 22:02:16 -0700 (PDT) Received: from [192.168.178.23] (163.194.69.111.dynamic.snap.net.nz. [111.69.194.163]) by mx.google.com with ESMTPSA id vu5sm62139898pab.10.2013.07.14.22.02.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Jul 2013 22:02:15 -0700 (PDT) Message-ID: <51E38253.10209@gmail.com> Date: Mon, 15 Jul 2013 17:02:11 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andrew Mcgregor References: <32AE7F11-A06E-40C1-A73C-5C69F252DAF9@iii.ca> <51DBC3D3.3000300@erg.abdn.ac.uk> <51E30523.2090805@gmail.com> <51E30F5B.3080603@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "gorry@erg.abdn.ac.uk" , tsvwg , Andrew McGregor Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 05:02:17 -0000 Andrew, Just a few more points from me: On 15/07/2013 12:15, Andrew Mcgregor wrote: ... > Perhaps we need another description of what is going on here, that's a > separate question, Indeed we do, and it's called PHB Identifiers, which are intended for naming PHBs in a globally unique way independent of the 6 bit DSCP (RFC 3140). It's a shame nobody uses them. > but we have those five codepoints (and perhaps a few > more, I didn't do an exhaustive search) that produce sensible behaviour in > both RFC 4594 recommended behaviour and the more widely deployed pfifo_fast. Fair enough, but 4594 only works across provider boundaries if there is mutual agreement. ... > > I believe that that local definition of the binding is a catastrophic bug > in the diffserv specs, and should never have been published in that form. It was (at the time) an essentially non-negotiable requirement from those in the diffserv WG who claimed to be operators who wanted freedom to use the TOS field as they wished. If today's operators have a different view, I don't see why this couldn't be revisited, but that's off topic here and now. > However, too late now. There is absolutely no way to tell an application > correctly what it should do with those bits unless there is an agreed set > of default meanings for at least some of the codepoints; maybe not total > specification of the exact behaviour, that's impractical, but at least a > way of setting some expectations. I agree, and this applies to any cross-domain use of the codepoints. However, there are two caveats: 1. Use phrasing that recognises that the standard formally requires local bindings. 2. Deal with the fact that these bits can be forged in the IP header. Brian From svshah@cisco.com Sun Jul 14 23:29:22 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C065321F9C92 for ; Sun, 14 Jul 2013 23:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kckdoz0oCXkA for ; Sun, 14 Jul 2013 23:29:16 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 4A20F21F8449 for ; Sun, 14 Jul 2013 23:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=839; q=dns/txt; s=iport; t=1373869756; x=1375079356; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=qemK2LQi8M3vKRjlN490FBnd7xtL5w/itEhvIz0vjbs=; b=ej8HchmJQwfVMFgQjhBHVG3FZ0X6gGsBQfKdWCS2grWvGXdoNbnAtb2H FzWa3Y7ldArr8wR6waTSGvdde3n4xsMCjH++YCqWtRyPHrSj9fp0dDdYE 3Mwmu3NeFpSjPQgZktd+dC7Xqgm+RCIvEHF6/UlzIG+hTAeen+xaJByBf E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4FAH6W41GtJV2a/2dsb2JhbABaDoJ4NE+CP78QgQoWdIIlAQEDOlEBCCIUQiUCBAESCIgIDLUcjjKBATiDC20DmQWQJIJUPoFxNw X-IronPort-AV: E=Sophos;i="4.89,667,1367971200"; d="scan'208";a="234800875" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 15 Jul 2013 06:29:10 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6F6T9Ai013984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jul 2013 06:29:09 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.98]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Mon, 15 Jul 2013 01:29:08 -0500 From: "Shitanshu Shah (svshah)" To: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] Preliminary TSVWG Agenda Thread-Index: AQHOfKiiQ/szyO7w2UGrPLhzAdopKJllLl0A Date: Mon, 15 Jul 2013 06:29:08 +0000 Message-ID: In-Reply-To: <63962533299aeee4ae03283e9e9b6b0e.squirrel@www.erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.21.124.184] Content-Type: text/plain; charset="us-ascii" Content-ID: <51A89B9903AC8E4E867AD734C1A045BC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tsvwg] Preliminary TSVWG Agenda X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 06:29:23 -0000 Hi Gorry, An updated draft of sla exchange, based on the feed-back from the last IETF, has been posted to both idr and tsvwg. http://tools.ietf.org/html/draft-ietf-idr-sla-exchange-01 You may want to update the reference in reading material. No plan to present the draft at this IETF either in idr or tsvwg. We can take any concerned discussion on the wg e-mail alias. Looking forward for review/comments. Regards, Shitanshu On 7/9/13 6:31 AM, "gorry@erg.abdn.ac.uk" wrote: >Here is a link to the draft agenda - this is preliminary, we have still to >schedule some talks and we may yet adjust this agenda. > >http://tools.ietf.org/wg/tsvwg/agenda?item=3Dagenda-87-tsvwg.html > >Let us know of corrections, conflicts or omissions. > >Gorry, David and James >(TSVWG Co-Chairs) > From carlberg@g11.org.uk Mon Jul 15 06:41:33 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2DE11E810C; Mon, 15 Jul 2013 06:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhU2PQNhCNM8; Mon, 15 Jul 2013 06:41:28 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id 713C211E8106; Mon, 15 Jul 2013 06:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=4uuGNwkwMEtRoU89d14nNhxJ8Zr7/VugapQ4pVe98/Q=; b=ajERd2nXYuBq0jMBWcrFqmvIIDkXd8iTHgV4mWXIzctLfRARsVUJo6ZH5rqdsQl4ailMGFE8wfc5JjbtnRFNav4oJrr+ouwUowdUBMeCJwJFHb7Ml2HrxrUo/E9cU0+x; Received: from c-98-218-170-72.hsd1.va.comcast.net ([98.218.170.72]:47783 helo=[10.0.1.20]) by portland.eukhosting.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Uyj1l-002GU4-0e; Mon, 15 Jul 2013 14:41:21 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: ken carlberg In-Reply-To: <20130712003002.GA30036@cisco.com> Date: Mon, 15 Jul 2013 09:41:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6D6A9A05-73A6-400A-831D-F4BF14AFAFD0@g11.org.uk> References: <20130710180147.GA614@cisco.com> <34BE8BE0-E863-4F69-8D45-18F5B97DE392@g11.org.uk> <20130712003002.GA30036@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Get-Message-Sender-Via: portland.eukhosting.net: acl_c_relayhosts_text_entry: carlberg@g11.org.uk|g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: rmcat@ietf.org, rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] [rmcat] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 13:41:33 -0000 Toerless, sorry for the tardy reply. I'll dig through my archives and send you a = copy. my draft proposed adding a "classifier" field, but I only did one = rev (which was missing some better rationale after a long talk I had = with Dave Oran) and i suspect that it would need a fair amount of = scrubbing before re-issuing another version. the first order of = business, though, will be to gauge the feedback/comments to your draft. -ken ps, CJ thanks for your clarification in your previous response On Jul 11, 2013, at 8:30 PM, Toerless Eckert wrote: > Thanks, Ken >=20 > Indeed yes, that's exactly the line of thought that we would like to > see proceed as well. Any URL still existing for that draft ? >=20 > "application layer gateway" could specifically mean switching MCU = using > intelligent dropping in conjunction with outbound congestion control. >=20 > I definitely would like to see RTP headers as the ultimatele marking > option even for routers to do intelligent dropping (or other packet > processing "beyond DSCP)). Intra-flow (per-packet) DSCP is just a big = pain=20 > (aka: impossible) for applications. Many OSs don't have any APIs to = support > this. And DSCP management in networks is already difficult enough as = it > stands. >=20 > Would certainly like to see if there is interest to write up r present > more pieces of this puzzle, especially an RTP extension. We just felt = that the > fairness in intelligent dropping was the biggest concern our video > application folks had, that's why we wanted to explain how that piece > could work first.=20 >=20 > Cheers > Toerless >=20 >=20 > On Thu, Jul 11, 2013 at 12:04:58PM -0400, ken carlberg wrote: >> Toerless, >>=20 >> some food for thought... >>=20 >> about 10 years ago, I put together a draft that added an optional TLV = prioritization header to RTP to accomplish something similar in terms of = having the app decide which was the better RTP packet to drop during = times of congestion. My aim was to have these decisions made at = forwarding application-layer gateways that did not act as a RTP/RTCP = endpoint. The strength of the approach (in my opinion :-) was that it = could span pockets of non-diff-serv regions and still carry significance = downstream. The weakness was the need for DPI if one wanted to make a = more informed decision along the path about dropping a packet. >>=20 >> I wonder if such a dual-layer design might be helpful in your = efforts. In any case, I have an interest in the normalizer draft. >>=20 >> -ken >>=20 >>=20 >> On Jul 10, 2013, at 2:01 PM, Toerless Eckert (eckert) = wrote: >>=20 >>> When dealing with congestion for real-time datagram (UDP/RTP) based = video flows, one idea >>> that we think has shown to provide good value is to intelligently = drop in the network >>> preferentially the least important packets within a video flow, for = example non-referenced >>> P-frames, because their loss creates the lowest impact to video = quality. >>>=20 >>> One of the main concerns raised against such schemes was one of = fairness. If flows=20 >>> would start to indicate different priorities for packets in them, = how would we >>> be able to avoid that flows would indicate all their packets to be = of high priority >>> to shift packet drops to other flows. Or even more importantly: how = could we motivate >>> flows to indicate that some of their packets are low priority = without them having to >>> fear that they would experience more loss than than flows that don't = do this. >>>=20 >>> So, there is one draft that we would like to present (presumably in = TSVWG) explaining >>> how we think this problem can be solved: = draft-lai-tsvwg-normalizer-00.txt >>>=20 >>> (Actually, this is how we did solve the problem in our implementatin = of intelligent dropping, >>> so this is not theoretical). >>>=20 >>> Now granted, the problem of fairness is but one element of building = a complete ssytem >>> around the idea of intelligent dropping, so if folks here on the = lists would like to >>> see for example=20 >>>=20 >>> a) how well can it work in routers to shift packet drops to low-prio = packets >>> b) whats the evidence that it's good for video quality >>> c) How should we do the marking best going forward >>>=20 >>> Then please let us know. We'd be very interested to provide insight = into the parts of >>> those pieces that we have also worked out or discuss the ones we = have not (primarily c ;-) >>>=20 >>> Thanks! >>> Toerless >>>=20 >>> In-Reply-To: = >>>=20 >>> On Sat, Feb 09, 2013 at 03:00:48AM +0000, Cheng-Jia Lai (chelai) = wrote: >>>> Hi all, >>>>=20 >>>> We have submitted a new Internet draft to describe a Normalization = Marker (NM) for DiffServ AF PHB groups, based on our work at Cisco. The = goal of NM deployment is to create a new incentive for video encoders to = generate more discardable packets when using AF PHB in DIffServ. We are = looking forward to your review comments. >>>>=20 >>>> Best regards, >>>> CJ >>>>=20 >>>> -----Original Message----- >>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 >>>> Sent: Friday, February 08, 2013 6:25 PM >>>> To: Cheng-Jia Lai (chelai) >>>> Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert = (eckert); Fred Yip (fyip) >>>> Subject: New Version Notification for = draft-lai-tsvwg-normalizer-00.txt >>>>=20 >>>>=20 >>>> A new version of I-D, draft-lai-tsvwg-normalizer-00.txt >>>> has been successfully submitted by Cheng-Jia Lai and posted to the >>>> IETF repository. >>>>=20 >>>> Filename: draft-lai-tsvwg-normalizer >>>> Revision: 00 >>>> Title: Normalization Marker for AF PHB Group in = DiffServ >>>> Creation date: 2013-02-08 >>>> WG ID: Individual Submission >>>> Number of pages: 15 >>>> URL: = http://www.ietf.org/internet-drafts/draft-lai-tsvwg-normalizer-00.txt >>>> Status: = http://datatracker.ietf.org/doc/draft-lai-tsvwg-normalizer >>>> Htmlized: = http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-00 >>>>=20 >>>>=20 >>>> Abstract: >>>> This memo describes a Normalization Marker (NM) at DiffServ (DS) >>>> nodes to normalize the distribution of DS codepoint (DSCP) = markings >>>> for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM = is >>>> useful for traffic conditioning with Active Queue Management (AQM) >>>> when the AF PHB group is deployed for multimedia service classes = that >>>> carry video packets with advanced codec technologies. Using NM = can >>>> offer an incentive that is however missing in today's ecosystem of >>>> practical deployment, i.e., when congestion occurs in the AF PHB >>>> group, the network should allow a video codec to benefit from its >>>> effort of generating finer layers of intra-flow precedence (IFP) = with >>>> discardable packets in a more balanced distribution. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat >>>>=20 >>>=20 >>> --=20 >>> --- >>> Toerless Eckert, eckert@cisco.com >>> Cisco NSSTG Systems & Technology Architecture >>> SDN: Let me play with the network, mommy! >>>=20 >>=20 >=20 > --=20 > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! >=20 From nishida@sfc.wide.ad.jp Mon Jul 15 09:49:30 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD06211E811B for ; Mon, 15 Jul 2013 09:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMRuwcQL75Xn for ; Mon, 15 Jul 2013 09:49:29 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 47DEA21E80F5 for ; Mon, 15 Jul 2013 09:49:07 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2CC95278094 for ; Tue, 16 Jul 2013 01:49:04 +0900 (JST) Received: by mail-la0-f50.google.com with SMTP id ep20so5138428lab.23 for ; Mon, 15 Jul 2013 09:49:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yVu0KzKh/qJFCxqs/wL+4Mu7vKc8MsAwnPEQcTkJHCo=; b=SLj5zZ/L14ppslz6EZCbdUL89YxQ0b4lLCFC22a9XzxtSQd5Cgmfll7ueY80zdIMix RZ/K/sxR8+aRTfhv4cPqUIhIgYE32vY3tPmrKZHOZcU8Wc1mjjdjqw1njojo0BRPns1i V+K7ONHiDGglpiDQB+qBEcX+cbueb2SuDWRovyNFHm1KDSsrf7E4wKqLUAStiAW6CMcE gTYBFOBIWQC4Hqrm2zIjPQ2TWudRjQMK4twAGdszn6P7Bt5j8Krbabhx0jNOEn0t1TIR sPRpkeTur9Gh+nT6/uXkV7VGAasU6LfUR0RHq+C5B4LrGn5B5wggp6FVsEIn54La+THe a/Bg== MIME-Version: 1.0 X-Received: by 10.152.18.202 with SMTP id y10mr24602497lad.80.1373906942557; Mon, 15 Jul 2013 09:49:02 -0700 (PDT) Received: by 10.114.92.238 with HTTP; Mon, 15 Jul 2013 09:49:02 -0700 (PDT) In-Reply-To: References: <51A360E7.7020209@ericsson.com> Date: Mon, 15 Jul 2013 09:49:02 -0700 Message-ID: From: Yoshifumi Nishida To: "Karen E. E. Nielsen" Content-Type: multipart/alternative; boundary=089e01493bf44406a804e18fa303 Cc: tsvwg , draft-ietf-tsvwg-sctp-failover@tools.ietf.org Subject: Re: [tsvwg] draft-ietf-tsvwg-sctp-failover: comments and suggestions X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:49:31 -0000 --089e01493bf44406a804e18fa303 Content-Type: text/plain; charset=ISO-8859-1 Hi Karen, Thanks for your comments. I also added my comments in line. On Thu, Jul 4, 2013 at 8:38 AM, wrote: > Hi All, > > Please find some additional comments inline below. > > > > >- Section 5.1: CWND Handling for Potentially Failed Destinations > > > > > > >I agree with you to stick to the behavior of RFC4960 as default behavior. > We've > >been exploring several possibilities for performance improvement and > discussing > >using 2 MTU might be an idea, although we think we'll need further > discussions. > >Preethi might have some more comments on this point. > > > > Please accept the following addition comments: > > The motivation for the 2MTU, I now understand, is to aim to mitigate > unwanted effects of > path bouncing resulting from a spurious T3-timeout followed by failover > and subsequent "immediate" switchback operation of RFC4960 once HB ACK > is acknowledged within the back-off'ed RTO. > > While I think that one can very well say in this document that the CWND > could be set to 2MTU > in case the first HB sent on a PF path is successfully ack'ed, then I > would like to note that > this then is motivated by a desire, first and foremost, to be backward > compatible with RC4960, more than it > really necessarily addresses how to best mitigate throughput degradation > effects of spurious T3-timeouts. > Indeed for implementations that operate with different switchback modes > than the immediate switchback operation of RFC4960, > (e.g. operate with certain permanent failover modes), then the set of the > CWND to 2 MTU on the previous PF path > is not of a big significance as it can be most optimal, from a performance > perspective, > to stay on the new data carrying path, which at this point in time may > have a CWND of IW, IW+1MTU or even higher. > I think that the motivation for setting the CWND to 2MTU possibly should > be made conditionally on whether the SCTP indeed follows > the immediate switchback operation of RFC4960. > > One further observation is that in a situation where it is only the 2dn or > the 3rd (or 4th..) of the HBs sent on the PF path, that is successful, then > setting the CWND to 2 MTU may actually constitute a decrease of the CWND. > This is the case if the implementation > follows RC4960 and raise the CWND to IW (4MTU) after an idle period of one > RTO following the T3 timeout. > When in the text it is said that the CWND should be set to 1MTU at the > state transition from PF to ACTIVE does this then very explicitly > addresses the fact that unsuccessful HBs, sent on a PF path, shall keep > the CWND down at 1MTU as otherwise data failures would ? > If so then I think that it could be good to add this clarification. > Ok. I see your point. I think we should explicitly say that we should set CWND to 1MTU after unsuccessful HBs. I don't think using 4MTU after seeing HB timeout is good approach. Thanks for pointing out. > Final thoughts: > > We have in real deployment experienced fault situations where HBs > consistently were able to get through on the primary path, > but where the path broke due to congestion once it got loaded with data. > There are different ways in which one can improve the > protocol operation to best tackle such a situation. Our present solution, > which is to deploy a permanent failover mode together with PF > and looking for a way to add reliability to the T3 timeouts, may not be > the ultimate way to solve this, but I would like to note that > in such a situation then consistently returning to the primary path and > setting CWND = 2MTU is not the right thing to do. > > > >- Section 5.3: Permanent Failover > > > >We have good experiences from live networks with running SCTP in a "no > >switchback" mode of operation with no automatic migration back to a > preferred > >primary path. Once the primary path is left due to it being potentially > failed, then a > >selected alternative path automatically becomes the new primary path. > > > >This mode of operation corresponds to a simplified variant of the > permanent > >failover operation proposed in [CAR002] with alpha = beta = > >SCTP_PEER_ADDR:THLDS. The mode of operation is run with notifications of > >change of primary path being provided to upper layers via RFC6458 > >SCTP_PEER_ADDR_CHANGE semantics (SCTP_ADDR_MADE_PRIM). > > > >The mode of operation does not suit all purposes, but in networks > environments > >where a number of equally preferred paths are available, then by this > mode of > >operation one minimizes the effects of unnecessary path bouncing and the > thereby > >associated effects of throughput degradation due to path changes and slow > start > >operation. > > > >Based on our experiences we would recommend and support that the Permanent > >Failover mode of operation, at least in the simple variant described > above, is > >promoted as a valid alternative approach. For the purpose of activation > of this > >mode of operation a switchback (or failover) mode operation parameter > could be > >introduced as configurable by the introduction of an appropriate new > read/write > >socket option in the Socket API. > > > > > >Yes. I agree that there will be a situation where Permanent Failover work > effectively. > >OTOH, supporting this prevents us from keeping RFC4960 behavior as RFC4960 > >doesn't have this mode. > >But, I believe this is a very interesting point and we would like to get > more feedback > >in order to think about this more. > > > > I understand to continue to support RFC4960 behaviour, but I suppose that > one can add to RFC4960 > behaviour :-) We have the simple "no switchback mode" described above > running in deployment. > Yes, I think that's doable. I think the question here is the degree of recommendation for this. The easiest one is just saying "An implementation MAY support no switchback mode", but I'm gueesing some people might prefer more explicit expressions. > >- Section 5.4: The impact of HB timeouts in association error counter > > > >The draft recommends for excluding HB timeouts from contributing to the > >(association) error counter. We fully support this approach for all > timeouts of HBs > >that are send to probe the state of destinations addresses that are in PF > state and > >we would even propose for the draft to demand that generally timeouts > stemming > >from HBs, which are not sent on the Primary Path, will be excluded from > the > >association error counter. > > > >Thereby the association error counter and thus the association fate > reflects the > >forward progress of the data transmission to peer endpoint while at the > same time it > >will be appropriately isolated from timeouts of HBs sent on non-data > carrying paths. > > > >Allowing timeout of HBs sent on the Primary Path to impact the > association error > >counter will serve to validate the aliveness of the peer endpoint when > there is no > >data in transit. > > > >This suggestion follows the thought expressed in > http://www.ietf.org/mail- > >archive/web/tsvwg/current/msg11294.html and it is thus believed to fulfil > the original > >intend of RFC4960. > > > >This is a bit difficult point for me. I don't know much about the > original intention of > >RFC4960, but if we follow what is written there, i think we need to > increment > >association error count. (Please correct me if I misunderstand this > point) So, my > >personal preference is to set bigger AMR to avoid early termination so > that we can > >keep the RFC4960 behavior. > >However, we don't mind discussing to update the logic described in 4960 > for more > >sophisticated solution. > > > > Thanks ! > > Yes, I concur that the text of section 8.1 of RFC4960 stipulates that all > HB Acks and HB timeouts > influence the association error counter. But from the referenced > discussion thread, > http://www.ietf.org/mail-archive/web/tsvwg/current/msg11294.html (simply copying it in here to avoid repeating the arguments) > it also seems that by purpose no keywords were used when writing these > paragraphs. > Further as the Potentially Feature was not defined at the time, I am not > sure that > it would be valid to say that the text of RFC4960 apply (at least) to the > HBs sent as part of this function. > > From our perspective what we would like to support and see happening is > that all HBs, whether sent as part of the PF function or not, influence > the association error counter > if and only if they are transmitted on the Primary Path (and then with > standard logic running making sure that all data transmissions > prevent (or cancel in race conditions) any influence from HBs). > > Thereby the association error counter will be influenced by (and will thus > reflect) the data transmission only. > Except in idle situation where HBs on Primary Path will serve to update > the association error counter in a similar manner as data would. > Thereby one get a very clean and reliable implementation of the > association error counter. By reliable, I mean that one can use > the same AMR value regardless of the level of HB probing that one have > activated and regardless of whether the Potentially Failed feature is > activated or not. > Such an implementation also makes the AMR value be independent from the > number of paths supported in the association context. > One can choose to use a value of AMR proportional with the number of paths > in order to have all paths be tried a number of times before association > closure, but > with the choice suggested, one is not forced to "artificially" raise the > AMR value to make room for the HBs that will fire as part of the > potentially failed feature as well > as for some fraction of the Path Monitoring HBs that can happen to fire > during the same timeframe. > > An additional thought is that in the odd cases where HBs get through > whereas data do not, then I think that it is contra-productive to have the > association error counter be reset > as long as data consistently fail. > > I, personally, does not so much like the suggestion to use a "maximal" or > "bigger" AMR. I think that it will be complex to deduce exactly > what failure time (aka number of data retransmission) that a certain AMR > value will guarantee you, > whereas when only data transmission influences the AMR, things will be > clean, simple and predictable. > I agree that the approach described in the draft is not the best approach. But, since it doesn't violate RFC4960, we recommend it in the draft. I think what you suggest sounds reasonable and prefer to update 4960 based on this, although I guess we'll need more discussions. > > >- Section 5.1 Thoughts on the destination address state machine > > > >In RFC4960 address state machine, notification of cease of use of the > current > >primary path as transmission path for new data is provided to upper layer > via > >(coupled with) the announcement of the destination as being UNREACHABLE. > With > >the introduction of the potentially failed state as a semi-hidden state > (not resulting in > >notified state transition to UL) the information on the fail-over to use > a new data > >carrying path is lost. > >While there may be merits in suppressing notifications on potentially > failed > >addresses, then we believe that it is unfortunate that the notification > of failover from > >usage of the primary path for new data is lost. > >This is especially problematic in path bouncing scenarios where the > primary path is > >unstable but still works some. E.g., HBs may go through, but the path > breaks (data > >transmission fails) as soon as it is more loaded. In such a situation no > notifications > >may be generated to UL, even if new data transmission consistently cycles > to and > >from the primary path. The solution to such path bouncing scenarios will > have to > >come from more advanced path failover mechanism, like [CAR002] (and would > not > >be solved just by notification), but it would be a great help if > appropriate > >notifications were provided. > > > >I think it will be OK to send notification as long as it's a new > notification type. But > >we should not send notifications defined in RFC6458. > > ok - I assume this is for backward compatible reasons. > Yes. As far as I can think that's the reason. >I guess having a new notification type won't cause problems, but I would > like to get > >more feedback on this. > > Ok - we can come back with a suggestion. > Thank you so much for many valuable feedback. We really appreciate! Regards, -- Yoshifumi --089e01493bf44406a804e18fa303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Karen,

Thanks for your comments. I a= lso added my comments in line.

On Thu, Jul 4, 2013 at 8:38 AM, <Karen.Nielsen@tie= to.com> wrote:
Hi All,

Please find some additional comments inline below.

>
>- Section 5.1: CWND Handling for Potentially Failed Destinations
>
<snip>
>
>I agree with you to stick to the behavior of RFC4960 as default behavio= r. We've
>been exploring several possibilities for performance improvement and di= scussing
>using 2 MTU might be an idea, although we think we'll need further = discussions.
>Preethi might have some more comments on this point.
>

Please accept the following addition comments:

The motivation for the 2MTU, I now understand, is to aim to mitigate unwant= ed effects of
path bouncing resulting from a spurious T3-timeout followed by failover
and subsequent "immediate" switchback operation of RFC4960 once H= B ACK
is acknowledged within the back-off'ed RTO.

While I think that one can very well say in this document that the CWND cou= ld be set to 2MTU
in case the first HB sent on a PF path is successfully ack'ed, then I w= ould like to note that
this then is motivated by a desire, first and foremost, to be backward comp= atible with RC4960, more than it
really necessarily addresses how to best mitigate throughput degradation ef= fects of spurious T3-timeouts.
Indeed for implementations that operate with different switchback modes tha= n the immediate switchback operation of RFC4960,
=A0(e.g. operate with certain permanent failover modes), then the set of th= e CWND to 2 MTU on the previous PF path
is not of a big significance as it can be most optimal, from a performance = perspective,
to stay on the new data carrying path, which at this point in time may have= a CWND of IW, IW+1MTU or even higher.
I think that the motivation for setting the CWND to 2MTU possibly should be= made conditionally on whether the SCTP indeed follows
the immediate switchback operation of RFC4960.

One further observation is that in a situation where it is only the 2dn or = the 3rd (or 4th..) of the HBs sent on the PF path, that is successful, then=
setting the CWND to 2 MTU may actually constitute a decrease of the CWND. T= his is the case if the implementation
follows RC4960 and raise the CWND to IW (4MTU) after an idle period of one = RTO following the T3 timeout.
When in the text it is said that the CWND should be set to 1MTU at the stat= e transition from PF to ACTIVE does this then very explicitly
addresses the fact that unsuccessful HBs, sent on a PF path, shall keep the= CWND down at 1MTU as otherwise data failures would ?
If so then I think that it could be good to add this clarification.

Ok. I see your point.
I think we= should explicitly say that we should set CWND to 1MTU after unsuccessful H= Bs.
I don't think using 4MTU after seeing HB timeout is good app= roach. Thanks for pointing out.


Final thoughts:

We have in real deployment experienced fault situations where HBs consisten= tly were able to get through on the primary path,
but where the path broke due to congestion once it got loaded with data. Th= ere are different ways in which one can improve the
protocol operation to best tackle such a situation. Our present solution, w= hich is to deploy a permanent failover mode together with PF
and looking for a way to add reliability to the T3 timeouts, may not be the= ultimate way to solve this, but I would like to note that
in such a situation then consistently returning to the primary path and set= ting CWND =3D 2MTU is not the right thing to do.


>- Section 5.3: Permanent Failover
>
>We have good experiences from live networks with running SCTP in a &quo= t;no
>switchback" mode of operation with no automatic migration back to = a preferred
>primary path. Once the primary path is left due to it being potentially= failed, then a
>selected alternative path automatically becomes the new primary path. >
>This mode of operation corresponds to a simplified variant of the perma= nent
>failover operation proposed in [CAR002] with alpha =3D beta =3D
>SCTP_PEER_ADDR:THLDS. The mode of operation is run with notifications o= f
>change of primary path being provided to upper layers via RFC6458
>SCTP_PEER_ADDR_CHANGE semantics (SCTP_ADDR_MADE_PRIM).
>
>The mode of operation does not suit all purposes, but in networks envir= onments
>where a number of equally preferred paths are available, then by this m= ode of
>operation one minimizes the effects of unnecessary path bouncing and th= e thereby
>associated effects of throughput degradation due to path changes and sl= ow start
>operation.
>
>Based on our experiences we would recommend and support that the Perman= ent
>Failover mode of operation, at least in the simple variant described ab= ove, is
>promoted as a valid alternative approach. For the purpose of activation= of this
>mode of operation a switchback (or failover) mode operation parameter c= ould be
>introduced as configurable by the introduction of an appropriate new re= ad/write
>socket option in the Socket API.
>
>
>Yes. I agree that there will be a situation where Permanent Failover wo= rk effectively.
>OTOH, supporting this=A0prevents us from keeping RFC4960 behavior as RF= C4960
>doesn't have this mode.
>But, I believe this is a very interesting point and we would like to ge= t more feedback
>in order to think about this more.
>

I understand to continue to support RFC4960 behaviour, but I su= ppose that one can add to RFC4960
behaviour :-) We have the simple "no switchback mode" described a= bove running in deployment.

Yes, I thin= k that's doable. I think the question here is the degree of recommendat= ion for this.
The easiest one is just saying "An implementation MAY support no = switchback mode", but I'm gueesing some people might prefer more e= xplicit expressions.=A0



>- Section 5.4: The impact of HB timeouts in association error counter >
>The draft recommends for excluding HB timeouts from contributing to the=
>(association) error counter. We fully support this approach for all tim= eouts of HBs
>that are send to probe the state of destinations addresses that are in = PF state and
>we would even propose for the draft to demand that generally timeouts s= temming
>from HBs, which are not sent on the Primary Path, will be excluded from= the
>association error counter.
>
>Thereby the association error counter and thus the association fate ref= lects the
>forward progress of the data transmission to peer endpoint while at the= same time it
>will be appropriately isolated from timeouts of HBs sent on non-data ca= rrying paths.
>
>Allowing timeout of HBs sent on the Primary Path to impact the associat= ion error
>counter will serve to validate the aliveness of the peer endpoint when = there is no
>data in transit.
>
>This suggestion follows the thought expressed in http://www.ietf.org/mail-
>archive/web/tsvwg/current/msg11294.html and it is thus believed to fulf= il the original
>intend of RFC4960.
>
>This is a bit difficult point for me. I don't know much about the o= riginal intention of
>RFC4960, but if we follow what is written there, i think we need to inc= rement
>association error count. (Please correct me if I misunderstand this poi= nt) So, my
>personal preference is to set bigger AMR to avoid early termination so = that we can
>keep the RFC4960 behavior.
>However, we don't mind discussing to update the logic described in = 4960 for more
>sophisticated solution.
>

Thanks !

Yes, I concur that the text of section 8.1 of RFC4960 stipulates that all H= B Acks and HB timeouts
influence the association error counter. But from the referenced discussion= thread,
=A0http://www.ietf.org/mail-archive/web/tsvwg/current/m= sg11294.html =A0(simply copying it in here to avoid repeating the argum= ents)
=A0it also seems that by purpose no keywords were used when writing these p= aragraphs.
Further as the Potentially Feature was not defined at the time, I am not su= re that
it would be valid to say that the text of RFC4960 apply (at least) to the H= Bs sent as part of this function.

>From our perspective what we would like to support and see happening is
that all HBs, whether sent as part of the PF function or not, influence the= association error counter
if and only if they are transmitted on the Primary Path (and then with stan= dard logic running making sure that all data transmissions
prevent (or cancel in race conditions) any influence from HBs).

Thereby the association error counter will be influenced by (and will thus = reflect) the data transmission only.
Except in idle situation where HBs on Primary Path will serve to update the= association error counter in a similar manner as data would.
Thereby one get a very clean and reliable implementation of the association= error counter. By reliable, I mean that one can use
the same AMR value regardless of the level of HB probing that one have acti= vated and regardless of whether the Potentially Failed feature is activated= or not.
Such an implementation also makes the AMR value be independent from the num= ber of paths supported in the association context.
One can choose to use a value of AMR proportional with the number of paths = in order to have all paths be tried a number of times before association cl= osure, but
with the choice suggested, one is not forced to "artificially" ra= ise the AMR value to make room for the HBs that will fire as part of the po= tentially failed feature as well
as for some fraction of the Path Monitoring HBs that can happen to fire dur= ing the same timeframe.

An additional thought is that in the odd cases where HBs get through wherea= s data do not, then I think that it is contra-productive to have the associ= ation error counter be reset
as long as data consistently fail.

I, personally, does not so much like the suggestion to use a "maximal&= quot; or "bigger" AMR. I think that it will be complex to deduce = exactly
what failure time (aka number of data retransmission) =A0that a certain AMR= value will guarantee you,
whereas when only data transmission influences the AMR, things will be clea= n, simple and predictable.

I agree that= the approach described in the draft is not the best approach. But, since i= t doesn't violate RFC4960, we recommend it in the draft.
I think what you suggest sounds reasonable and prefer to update 4960 b= ased on this, although I guess we'll need more discussions.

>
>- Section 5.1 Thoughts on the destination address state machine
>
>In RFC4960 address state machine, notification of cease of use of the c= urrent
>primary path as transmission path for new data is provided to upper lay= er via
>(coupled with) the announcement of the destination as being UNREACHABLE= . With
>the introduction of the potentially failed state as a semi-hidden state= (not resulting in
>notified state transition to UL) the information on the fail-over to us= e a new data
>carrying path is lost.
>While there may be merits in suppressing notifications on potentially f= ailed
>addresses, then we believe that it is unfortunate that the notification= of failover from
>usage of the primary path for new data is lost.
>This is especially problematic in path bouncing scenarios where the pri= mary path is
>unstable but still works some. E.g., HBs may go through, but the path b= reaks (data
>transmission fails) as soon as it is more loaded. In such a situation n= o notifications
>may be generated to UL, even if new data transmission consistently cycl= es to and
>from the primary path. The solution to such path bouncing scenarios wil= l have to
>come from more advanced path failover mechanism, like [CAR002] (and wou= ld not
>be solved just by notification), but it would be a great help if approp= riate
>notifications were provided.
>
>I think it will be OK to send notification as long as it's a new no= tification type. But
>we should not send notifications defined in RFC6458.

ok - I assume this is for backward compatible reasons.

Yes. As far as I can think that's the reason.

>I guess having a new notification type won't cause problems, but I = would like to get
>more feedback on this.

Ok - we can come back with a suggestion.

Thank you so much for many valuable feedback. We really appreciate!=

Regards,
--
Yoshifumi=A0

--089e01493bf44406a804e18fa303-- From internet-drafts@ietf.org Mon Jul 15 12:23:50 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D5511E8232; Mon, 15 Jul 2013 12:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qry8G5mckfx2; Mon, 15 Jul 2013 12:23:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA9911E8198; Mon, 15 Jul 2013 12:23:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715192346.10408.43266.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 12:23:46 -0700 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 19:23:50 -0000 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 Grou= p of the IETF. Title : DTLS Encapsulation of SCTP Packets Author(s) : Randell Jesup Salvatore Loreto Randall R. Stewart Michael Tuexen Filename : draft-ietf-tsvwg-sctp-dtls-encaps-01.txt Pages : 7 Date : 2013-07-15 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. 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-sctp-dtls-encaps-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From eckelcu@cisco.com Mon Jul 15 14:15:57 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F47421E8105 for ; Mon, 15 Jul 2013 14:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUAiaO+O7s-3 for ; Mon, 15 Jul 2013 14:15:52 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 55CC021E80C3 for ; Mon, 15 Jul 2013 14:15:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3708; q=dns/txt; s=iport; t=1373922952; x=1375132552; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=dqkrsa49W0ur5tB4GN44WcedENfmxxuu3dBoedhZdd8=; b=W8i1WrVuq7E9VAqUPKSYJD12GrzIBJuHhRYvS5bxOgFPeeGzKaE2uJU4 9W/xAFc1qG1qRmFK/d/NcYihd6Tjo9Gk5RRcEk1W7dSxhwUckvSBo5F8f 3AemWEE6gGpWiYd22eyGUejaaeJvWTblJZA0rVktzBlH2xDmt3+fVKiEH A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FADdl5FGtJV2c/2dsb2JhbABagwY0SQaDBr5WF30WdIIjAQEBBCMRQw4GAQgRBAEBAwIGHQMCBDAUAQYBAQUEAQQTCAGIBgEHBZVejn2RS4Emjg0+glIzbQOZBZAkgVmBOYIo X-IronPort-AV: E=Sophos;i="4.89,671,1367971200"; d="scan'208";a="232145639" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 15 Jul 2013 21:15:52 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6FLFpru030855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 15 Jul 2013 21:15:51 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.187]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Mon, 15 Jul 2013 16:15:51 -0500 From: "Charles Eckel (eckelcu)" To: "tsvwg@ietf.org" Thread-Topic: New Version Notification for draft-choukir-tsvwg-flow-metadata-encoding-01.txt Thread-Index: Ac6BoHpFEH6xPTTTQ4iU+XO6wViTIg== Date: Mon, 15 Jul 2013 21:15:50 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828048B4244@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [tsvwg] FW: New Version Notification for draft-choukir-tsvwg-flow-metadata-encoding-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:15:57 -0000 V2UgaGF2ZSBzdWJtaXR0ZWQgYSBtaW5vciB1cGRhdGUgdG8gZHJhZnQtY2hvdWtpci10c3Z3Zy1m bG93LW1ldGFkYXRhLWVuY29kaW5nLiBUaGlzIHVwZGF0ZSBhZGRyZXNzZXMgZWRpdG9yaWFsIGNv bW1lbnQgd2UgaGF2ZSByZWNlaXZlZCBhbmQgaW5jbHVkZXMgYXBwcm9wcmlhdGUgcmVmZXJlbmNl cyB0byByZWxhdGVkIGRyYWZ0cy4NCldlIGhhdmUgcmVxdWVzdGVkIGFnZW5kYSB0aW1lIHRvIHBy ZXNlbnQgdGhpcyBkcmFmdCBhdCBhIFRTVldHIHNlc3Npb24gaW4gQmVybGluLCBhbmQgd2Ugd291 bGQgZ3JlYXRseSBhcHByZWNpYXRlIHlvdXIgZmVlZGJhY2sgb24gaXQgcHJpb3IgdG8gdGhhdC4N Cg0KQ2hlZXJzLA0KQ2hhcmxlcw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn XSANClNlbnQ6IE1vbmRheSwgSnVseSAxNSwgMjAxMyAxOjQxIFBNDQpUbzogVG9lcmxlc3MgRWNr ZXJ0IChlY2tlcnQpOyBBbWluZSBDaG91a2lyIChhbWNob3VraSk7IEFuY2EgWmFtZmlyIChhbmNh eik7IENoYXJsZXMgRWNrZWwgKGVja2VsY3UpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWNob3VraXItdHN2d2ctZmxvdy1tZXRhZGF0YS1lbmNvZGluZy0wMS50 eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtY2hvdWtpci10c3Z3Zy1mbG93LW1l dGFkYXRhLWVuY29kaW5nLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBUb2VybGVzcyBFY2tlcnQgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0K RmlsZW5hbWU6CSBkcmFmdC1jaG91a2lyLXRzdndnLWZsb3ctbWV0YWRhdGEtZW5jb2RpbmcNClJl dmlzaW9uOgkgMDENClRpdGxlOgkJIFByb3RvY29sIEluZGVwZW5kZW50IEVuY29kaW5nIGZvciBT aWduYWxpbmcgRmxvdyBDaGFyYWN0ZXJpc3RpY3MNCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTA3LTE1 DQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTkNClVS TDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt Y2hvdWtpci10c3Z3Zy1mbG93LW1ldGFkYXRhLWVuY29kaW5nLTAxLnR4dA0KU3RhdHVzOiAgICAg ICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNob3VraXItdHN2d2ct Zmxvdy1tZXRhZGF0YS1lbmNvZGluZw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1jaG91a2lyLXRzdndnLWZsb3ctbWV0YWRhdGEtZW5jb2RpbmctMDEN CkRpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt Y2hvdWtpci10c3Z3Zy1mbG93LW1ldGFkYXRhLWVuY29kaW5nLTAxDQoNCkFic3RyYWN0Og0KICAg VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBwcm90b2NvbCBpbmRlcGVuZGVudCBlbmNvZGluZyBm b3IgZmxvdw0KICAgY2hhcmFjdGVyaXN0aWNzIChhLmsuYS4gbWV0YWRhdGEpLiAgQSBmbG93IGlz IGRlZmluZWQgYXMgYSBzZXQgb2YgSVANCiAgIHBhY2tldHMgcGFzc2luZyB0aHJvdWdoIGEgbmV0 d29yayBpbiBhIGdpdmVuIGRpcmVjdGlvbi4gIEFsbCBwYWNrZXRzDQogICBiZWxvbmdpbmcgdG8g YSBwYXJ0aWN1bGFyIGZsb3cgaGF2ZSBhIHNldCBvZiBjb21tb24gcHJvcGVydGllcyAoZS5nLg0K ICAgSVAsIHBvcnQsIHRyYW5zcG9ydCkuICBGbG93IG1ldGFkYXRhIGV4cG9zZXMga2V5IGNoYXJh Y3RlcmlzdGljcyBvZg0KICAgdGhlIGZsb3cgc3VjaCBhcyB0aGUgb3JpZ2luYXRpbmcgYXBwbGlj YXRpb24sIHRoZSB0eXBlIG9mIG1lZGlhIGluDQogICB1c2UgKGUuZy4gIGF1ZGlvLCB2aWRlbykg YW5kIG90aGVycyBhcyBkZWZpbmVkIGluDQogICBbSS1ELmVja2VydC1pbnRhcmVhLWZsb3ctbWV0 YWRhdGEtZnJhbWV3b3JrXS4gIFRoZSBmbG93DQogICBjaGFyYWN0ZXJpc3RpY3MgYXJlIGV4cHJl c3NlZCBpbiB0ZXJtcyBvZiBpbmZvcm1hdGlvbiBlbGVtZW50cy4NCiAgIFRoZXNlIGluZm9ybWF0 aW9uIGVsZW1lbnRzIGFyZSBzaWduYWxlZCBlaXRoZXIgb3V0IG9mIGJhbmQgb3IgaW4gYmFuZA0K ICAgYnV0IGFsd2F5cyBhbG9uZyB0aGUgc2FtZSBwYXRoIG9mIHRoZSBmbG93IGFzc29jaWF0ZWQg d2l0aCB0aGUNCiAgIGFwcGxpY2F0aW9uLg0KDQogICBbSS1ELmVja2VydC1pbnRhcmVhLWZsb3ct bWV0YWRhdGEtZnJhbWV3b3JrXSBkZWZpbmVzIHRoZSBvdmVyYWxsDQogICBmcmFtZXdvcmsgZm9y IGZsb3cgbWV0YWRhdGEgYW5kIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBmbG93DQogICBjaGFyYWN0 ZXJpc3RpY3MsIHdoZXJlYXMgdGhpcyBkb2N1bWVudCBjYXB0dXJlcyB0aGUgZW5jb2Rpbmcgb2Yg dGhlc2UNCiAgIGNoYXJhY3RlcmlzdGljcy4gIFRoZSBtYXBwaW5nIG9mIGZsb3cgbWV0YWRhdGEg ZW5jb2RpbmcgdG8gZGlmZmVyZW50DQogICBzaWduYWxpbmcgcHJvdG9jb2xzIGlzIG91dHNpZGUg dGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN Cg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From internet-drafts@ietf.org Mon Jul 15 14:20:34 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431C921E80CC; Mon, 15 Jul 2013 14:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cV2HasqjXtKO; Mon, 15 Jul 2013 14:20:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1A421F99D7; Mon, 15 Jul 2013 14:20:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715212033.19775.92141.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 14:20:33 -0700 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-port-use-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:20:34 -0000 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 Grou= p of the IETF. Title : Recommendations for Transport Port Uses Author(s) : Joe Touch Filename : draft-ietf-tsvwg-port-use-02.txt Pages : 18 Date : 2013-07-15 Abstract: This document provides recommendations to application and service designers on how to use the transport protocol port number space to help in its preservation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-port-use-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jmpolk@cisco.com Mon Jul 15 23:08:05 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79EA21E81AD for ; Mon, 15 Jul 2013 23:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iO8DoVSWnh6v for ; Mon, 15 Jul 2013 23:08:01 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF3021E81A8 for ; Mon, 15 Jul 2013 23:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=531; q=dns/txt; s=iport; t=1373954881; x=1375164481; h=message-id:date:to:from:subject:mime-version; bh=WPGYfn/BKNYRBsII5V4LMPY6RCLJPCmFIaAKVboCKWc=; b=iY/ZpelEgWzGj+ixFaUc4RG95CBZvSS56EKWh6sbaQa5uWZhZUIwttJD 3PSALSe5P2GZ3GTQwNMPFaUzubxcxYig4F//jUvSm4efvwsiAVmtfjJKc xFKmQ0cLxKnhQMYK1dOGOm8DcXtkTcYbogYkrzBEE+IfUiEjNLNzJjoWC o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFAGzi5FGtJV2b/2dsb2JhbABagwY0gw7ALhZ0gmICViUVHwpgiAcMlWKgTJABg2IDiSegAoMwHg X-IronPort-AV: E=Sophos;i="4.89,674,1367971200"; d="scan'208";a="235293665" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 16 Jul 2013 06:08:01 +0000 Received: from jmpolk-WS.cisco.com ([10.89.8.39]) (authenticated bits=0) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6G680RY026646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Jul 2013 06:08:00 GMT Message-Id: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 16 Jul 2013 01:07:59 -0500 To: tsvwg@ietf.org From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 06:08:05 -0000 (as an author) Toerless and I put together a draft about legacy rate-adaptation based only on loss vs. what RMCAT is looking to (for RTCWEB), which is based on delay and loss. Here's the URL. http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt It's more raw than we had in mind, but we believe this is necessary, based on implementation experience and what users and customers have in their networks, or are planning on having in their networks soon. James & Toerless From mramalho@cisco.com Tue Jul 16 06:36:22 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26A111E80FE for ; Tue, 16 Jul 2013 06:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdM8Xoib+d5Y for ; Tue, 16 Jul 2013 06:36:17 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8499D11E80F4 for ; Tue, 16 Jul 2013 06:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3085; q=dns/txt; s=iport; t=1373981767; x=1375191367; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=qSRDa9UQAvUqXv9FagQ0ereyBRSJ/GTW+0MUqSYPHTA=; b=VRypgizoje/TAduPxzorRUnXFr97FF2H+USQVrlBFZTGVw+JL7tTWZ5y C8WXwiTaZZGJr1ZcFCqWWnm9Ygbpp0pvlWzZJ+wWZi4iH550yG8ECagc3 Re/pWfvYmcXBrTdIqY/KtMjUWcyIk08Y7YCr+pHa5fleoBXZMZseqSOOj c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAO1K5VGtJV2Y/2dsb2JhbABagwY0T8FdgQ8WdIIjAQEBAwE6RAcEAgEIEQMBAQELFAkHMhQHAQEFAwIEEwgBiAEGDLYIjy44BoMGbQOpKYFZgTmCKA X-IronPort-AV: E=Sophos;i="4.89,677,1367971200"; d="scan'208";a="235426595" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 16 Jul 2013 13:36:07 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6GDa7gH030445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 16 Jul 2013 13:36:07 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.54]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 08:36:06 -0500 From: "Michael Ramalho (mramalho)" To: "tsvwg@ietf.org" Thread-Topic: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for DiffServ Thread-Index: AQHOggZ1ibmIYctWIUyl3FUXvgClMZlnRd2QgAAELjA= Date: Tue, 16 Jul 2013 13:36:05 +0000 Message-ID: References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.125.234] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 13:36:22 -0000 TSVWG Members, I should have copied you on my email to the RMCAT mailer below. I strongly support the creation of a new DSCP for transports in which their= congestion control can adapt based on delay. The current ID in support of this (http://www.ietf.org/internet-drafts/draf= t-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt ) is a work in progres= s, but a step in the right direction. It is a given that the ability of the eventual RMCAT adaptation mechanisms = to achieve low delay will be function of the other dominant traffic it is c= ompeting against. If the dominant competing traffic DEPENDS on loss, the RM= CAT packets are held hostage to being delayed by the bottleneck queue delay= maximum. Thus, whenever possible, it will be preferable for RMCAT flows to compete w= ith other congestion control transports that adapt on delay. Even this may = not get us to the desired low-delay goals when a portion of the traffic has= long RTTs (i.e., adaptation control loops that are long in time), or for l= inks that have a highly-time varying capacity, but it will help for a lot = of common bottleneck topologies (e.g., slowly time-varying access bufferblo= at). It is my hope that this topic has some discussion time in the Berlin Transp= ort WG (not the specific codepoint to be chosen, but rather the need for on= e). Off Soapbox, Michael Ramalho, Ph.D. -----Original Message----- From: Michael Ramalho (mramalho)=20 Sent: Tuesday, July 16, 2013 9:06 AM To: rmcat@ietf.org Subject: RE: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. loss-only rate-= adaptive for DiffServ RMCAT Design Team, The draft Lars references below is a formal request for a DSCP dedicated to= "RMCAT-only (or other nice delay-based cc) traffic". It will take a while to become socialized ... and we can progress our RMCAT= work in the interim. Michael Ramalho -----Original Message----- From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of E= ggert, Lars Sent: Tuesday, July 16, 2013 5:26 AM To: WG WG Cc: draft-polk-tsvwg-delay-vs-loss-ds-service-classes@tools.ietf.org Subject: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. loss-only rate-adap= tive for DiffServ Possibly of interest to RMCAT. Begin forwarded message: > From: James Polk > Subject: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for Di= ffServ > Date: July 16, 2013 8:07:59 GMT+02:00 > To: >=20 > (as an author) >=20 > Toerless and I put together a draft about legacy rate-adaptation based on= ly on loss vs. what RMCAT is looking to (for RTCWEB), which is based on del= ay and loss. Here's the URL. >=20 > http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-ser= vice-classes-00.txt >=20 > It's more raw than we had in mind, but we believe this is necessary, base= d on implementation experience and what users and customers have in their n= etworks, or are planning on having in their networks soon. >=20 > James & Toerless >=20 From chelai@cisco.com Tue Jul 16 11:36:41 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC1121F9C12; Tue, 16 Jul 2013 11:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id He0ubQQa0MPG; Tue, 16 Jul 2013 11:36:36 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id AA9E021F9A26; Tue, 16 Jul 2013 11:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3807; q=dns/txt; s=iport; t=1373999796; x=1375209396; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=+6bi9J/MWr0mcBlNVbo6XVYf0TWopgXwptTxNvZXYe8=; b=HSsn+xXu5bylKKHzghB524ps0yNqKnyydtSKeFDIn4aeb04uBiAaMLbZ 2mleE6JG84wSlWhaeW4L4mEnIunaGxu3zcSskTnBpmidmGpLSZlbfCBCM AvabzilY4wuAbcg7P5bwB3G6pnebT6mmi/m2JCpfmcTHdOi5AjQ6k4nJS c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAHGR5VGtJXG+/2dsb2JhbABagwY0T8F0gREWdIIjAQEBAwE6RAcEAgEIEQMBAQELFAkHMhQIAQgCBAESCAGIAQYMtXiPLjgGgwZtA6kpgVmBOYIo X-IronPort-AV: E=Sophos;i="4.89,678,1367971200"; d="scan'208";a="235579660" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 16 Jul 2013 18:36:33 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6GIaXB1011238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 18:36:33 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.51]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 13:36:32 -0500 From: "Cheng-Jia Lai (chelai)" To: "James Polk (jmpolk)" , "Toerless Eckert (eckert)" , "Michael Ramalho (mramalho)" , "tsvwg@ietf.org" , "rmcat@ietf.org" Thread-Topic: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ Thread-Index: AQHOgil6VGqxx9YuYkWplWeJnoICXplnn7LQ Date: Tue, 16 Jul 2013 18:36:31 +0000 Message-ID: References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.161.170] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 18:36:41 -0000 Same here... I feel it makes sense to create a new DSCP / CS4 for transport= of video flows that have rate adaptive behaviors and/or intra-flow prefere= ntial drop priorities as indicated in the I-D. The service provided by the = network may thus be considered new, i.e. different from what exists in AF4x= , so IMHO, using a new or reusing CS4 service class adds clarity for the us= er applications. Regards, CJ -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of M= ichael Ramalho (mramalho) Sent: Tuesday, July 16, 2013 6:36 AM To: tsvwg@ietf.org Subject: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs. loss-only rate-= adaptive for DiffServ TSVWG Members, I should have copied you on my email to the RMCAT mailer below. I strongly support the creation of a new DSCP for transports in which their= congestion control can adapt based on delay. The current ID in support of this (http://www.ietf.org/internet-drafts/draf= t-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt ) is a work in progres= s, but a step in the right direction. It is a given that the ability of the eventual RMCAT adaptation mechanisms = to achieve low delay will be function of the other dominant traffic it is c= ompeting against. If the dominant competing traffic DEPENDS on loss, the RM= CAT packets are held hostage to being delayed by the bottleneck queue delay= maximum. Thus, whenever possible, it will be preferable for RMCAT flows to compete w= ith other congestion control transports that adapt on delay. Even this may = not get us to the desired low-delay goals when a portion of the traffic has= long RTTs (i.e., adaptation control loops that are long in time), or for l= inks that have a highly-time varying capacity, but it will help for a lot = of common bottleneck topologies (e.g., slowly time-varying access bufferblo= at). It is my hope that this topic has some discussion time in the Berlin Transp= ort WG (not the specific codepoint to be chosen, but rather the need for on= e). Off Soapbox, Michael Ramalho, Ph.D. -----Original Message----- From: Michael Ramalho (mramalho)=20 Sent: Tuesday, July 16, 2013 9:06 AM To: rmcat@ietf.org Subject: RE: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. loss-only rate-= adaptive for DiffServ RMCAT Design Team, The draft Lars references below is a formal request for a DSCP dedicated to= "RMCAT-only (or other nice delay-based cc) traffic". It will take a while to become socialized ... and we can progress our RMCAT= work in the interim. Michael Ramalho -----Original Message----- From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of E= ggert, Lars Sent: Tuesday, July 16, 2013 5:26 AM To: WG WG Cc: draft-polk-tsvwg-delay-vs-loss-ds-service-classes@tools.ietf.org Subject: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. loss-only rate-adap= tive for DiffServ Possibly of interest to RMCAT. Begin forwarded message: > From: James Polk > Subject: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for Di= ffServ > Date: July 16, 2013 8:07:59 GMT+02:00 > To: >=20 > (as an author) >=20 > Toerless and I put together a draft about legacy rate-adaptation based on= ly on loss vs. what RMCAT is looking to (for RTCWEB), which is based on del= ay and loss. Here's the URL. >=20 > http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-ser= vice-classes-00.txt >=20 > It's more raw than we had in mind, but we believe this is necessary, base= d on implementation experience and what users and customers have in their n= etworks, or are planning on having in their networks soon. >=20 > James & Toerless >=20 From eckelcu@cisco.com Tue Jul 16 13:47:01 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7541821F99FB for ; Tue, 16 Jul 2013 13:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HzoWa6rQOsB for ; Tue, 16 Jul 2013 13:46:56 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0FA21F99D7 for ; Tue, 16 Jul 2013 13:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1918; q=dns/txt; s=iport; t=1374007616; x=1375217216; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=8EdNW//89otxmOLR9hM3LC0oLBl/n8XgOcuOsomign8=; b=cuIU/tRJDRbCNLPB4eU6o+ePJ4MOeEhrzyh5o3rYwx9MWxoYrk3qBPFX lAKfpBBxwt/jrUSPkdV4NoGzUiW4I6aTZrwDMow1IFCi+GWvp4qkeb86V 4wLWSYvPbcLEK+RtES/G06QhNqcG7WI8oF5q0rZm+kn98Gws8cnyWmJpC w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAE6v5VGtJXG//2dsb2JhbABagwY0T8F8gRIWdIIjAQEBBDpLBAIBCBEEAQELFAkHMhQJCAIEARIIAYgGAQy1XY8uOAaDBm0Dk0RBlSSDEoIo X-IronPort-AV: E=Sophos;i="4.89,679,1367971200"; d="scan'208";a="235608754" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 16 Jul 2013 20:46:55 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6GKktNf025243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 16 Jul 2013 20:46:55 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.187]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 15:46:55 -0500 From: "Charles Eckel (eckelcu)" To: "James Polk (jmpolk)" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for DiffServ Thread-Index: AQHOgeraA2Us2T761Eqijb60sjBbhZlnwdGA Date: Tue, 16 Jul 2013 20:46:54 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828048B5077@xmb-aln-x08.cisco.com> References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> In-Reply-To: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 20:47:01 -0000 I read the draft and thank you for addressing this need. It does a good job= of making the case for the need to differentiate the DSCP assignments of d= elay-and-loss-based vs. just-loss-based rate-adaptive video applications. W= hile I do not agree with some of the finer points in the draft, including t= he statement in section 3 that AF4x traffic in general is inelastic/fixed b= itrate, I completely agree that this traffic is largely loss sensitive and = yet often relies on loss based adaption. The assignment of a new service class and the proposal for CS4 and CS4-Disc= ardable for rate-adaptive video makes sense to me. At the same time, it is = important to re-designate AF4x as you describe in order to match the realit= y of today's deployments and avoid future confusion. I look forward to seeing this work progress as it offer an incentive for ap= plications to embrace congestion control algorithms such as those being dev= eloped in RMCAT without fearing they will be overrun by non-delay adaptive = traffic. Cheers, Charles > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > James Polk (jmpolk) > Sent: Monday, July 15, 2013 11:08 PM > To: tsvwg@ietf.org > Subject: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for Di= ffServ >=20 > (as an author) >=20 > Toerless and I put together a draft about legacy rate-adaptation > based only on loss vs. what RMCAT is looking to (for RTCWEB), which > is based on delay and loss. Here's the URL. >=20 > http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-ser= vice- > classes-00.txt >=20 > It's more raw than we had in mind, but we believe this is necessary, > based on implementation experience and what users and customers have > in their networks, or are planning on having in their networks soon. >=20 > James & Toerless From jmpolk@cisco.com Tue Jul 16 14:06:53 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E22421F9D93 for ; Tue, 16 Jul 2013 14:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ft8ser+jZJTD for ; Tue, 16 Jul 2013 14:06:48 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B554C21F9CA1 for ; Tue, 16 Jul 2013 14:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2506; q=dns/txt; s=iport; t=1374008808; x=1375218408; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=FG3N08s+jjUTl+cHnR2HKIDbGdpHyWBLZax5b1GqSZM=; b=Jd0hoc18xLJpu+b9OWb1uCx7b1C6MS1oCLBPoPKVz4UcynftYkzDNl9k NvKX/kHaZYv/HZRT5w4Z0g7PXDmeqXGbBQpR2IvkBpINq3luAshw/5sWr v9tPC454NxrcFLhVHsIBl9fPvcIyk91c2Z+Px40npwxRmRtnd9Ama4Gp1 E=; X-IronPort-AV: E=Sophos;i="4.89,679,1367971200"; d="scan'208";a="235728520" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 16 Jul 2013 21:06:47 +0000 Received: from jmpolk-WS.cisco.com ([10.89.8.39]) (authenticated bits=0) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6GL6khf029009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 21:06:47 GMT Message-Id: <201307162106.r6GL6khf029009@rcdn-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 16 Jul 2013 16:06:38 -0500 To: "Charles Eckel (eckelcu)" , "tsvwg@ietf.org" From: James Polk In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828048B5077@xmb-aln-x08.cisco .com> References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <92B7E61ADAC1BB4F941F943788C08828048B5077@xmb-aln-x08.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: "James Polk \(jmpolk\)" Subject: Re: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 21:06:53 -0000 At 03:46 PM 7/16/2013, Charles Eckel (eckelcu) wrote: >I read the draft and thank you for addressing this need. It does a >good job of making the case for the need to differentiate the DSCP >assignments of delay-and-loss-based vs. just-loss-based >rate-adaptive video applications. While I do not agree with some of >the finer points in the draft, including the statement in section 3 >that AF4x traffic in general is inelastic/fixed bitrate, Charles Thank you for the quick review! If we authors gave the impression that all AF4X marked traffic is inelastic and uses the 'same' fixed bitrates, we apologize. However, each AF4X flow from a given codec - be it audio or video - in today's implementations, pretty much use the same bitrate per flow (not the same bitrate for each flow). Do you agree with this clarification, or would you like to offer substitute/replacement text in the offending section? James > I completely agree that this traffic is largely loss sensitive and > yet often relies on loss based adaption. >The assignment of a new service class and the proposal for CS4 and >CS4-Discardable for rate-adaptive video makes sense to me. At the >same time, it is important to re-designate AF4x as you describe in >order to match the reality of today's deployments and avoid future confusion. >I look forward to seeing this work progress as it offer an incentive >for applications to embrace congestion control algorithms such as >those being developed in RMCAT without fearing they will be overrun >by non-delay adaptive traffic. > >Cheers, >Charles > > > > -----Original Message----- > > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > > James Polk (jmpolk) > > Sent: Monday, July 15, 2013 11:08 PM > > To: tsvwg@ietf.org > > Subject: [tsvwg] Submitted ID on delay vs. loss-only > rate-adaptive for DiffServ > > > > (as an author) > > > > Toerless and I put together a draft about legacy rate-adaptation > > based only on loss vs. what RMCAT is looking to (for RTCWEB), which > > is based on delay and loss. Here's the URL. > > > > > http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-service- > > classes-00.txt > > > > It's more raw than we had in mind, but we believe this is necessary, > > based on implementation experience and what users and customers have > > in their networks, or are planning on having in their networks soon. > > > > James & Toerless From jmpolk@cisco.com Tue Jul 16 14:10:20 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCD521F9F13 for ; Tue, 16 Jul 2013 14:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.569 X-Spam-Level: X-Spam-Status: No, score=-110.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftDxsx6ee3t9 for ; Tue, 16 Jul 2013 14:10:13 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3498C21F9E3C for ; Tue, 16 Jul 2013 14:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3446; q=dns/txt; s=iport; t=1374009013; x=1375218613; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=pL8BAHvUhS7egKUVOzKRwrBWXh0vHD+zbBT/gx5S9Cs=; b=dNL6wU2I1+8PxhQHStfRU76wu2bQjhFPbVntvRoNd1p/jziF7M+tGKSI Ze2ODJGXeSCM3O808T/XBkpCNEXGuJXRiuRcm3icyDBTcv0/Tp+WK+v5n UAQpEFOsG4X/psBR+WAtHsbbJ2Ddb4nZe50w+WgUqczxdXaQz3Vb/UUWJ c=; X-IronPort-AV: E=Sophos;i="4.89,679,1367971200"; d="scan'208";a="235619756" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 16 Jul 2013 21:10:13 +0000 Received: from jmpolk-WS.cisco.com ([10.89.8.39]) (authenticated bits=0) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6GLAC3N019397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 21:10:12 GMT Message-Id: <201307162110.r6GLAC3N019397@rcdn-core2-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 16 Jul 2013 16:10:12 -0500 To: "Michael Ramalho (mramalho)" , "tsvwg@ietf.org" From: James Polk In-Reply-To: References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 21:10:20 -0000 At 08:36 AM 7/16/2013, Michael Ramalho (mramalho) wrote: >TSVWG Members, > >I should have copied you on my email to the RMCAT mailer below. > >I strongly support the creation of a new DSCP for transports in >which their congestion control can adapt based on delay. > >The current ID in support of this >(http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt >) is a work in progress, but a step in the right direction. Michael Thank you for the quick review. The draft isn't very long (under 8 pages currently), and it is a work in progress - but do you have text or just points that this draft needs to cover that it doesn't currently? James >It is a given that the ability of the eventual RMCAT adaptation >mechanisms to achieve low delay will be function of the other >dominant traffic it is competing against. If the dominant competing >traffic DEPENDS on loss, the RMCAT packets are held hostage to being >delayed by the bottleneck queue delay maximum. > >Thus, whenever possible, it will be preferable for RMCAT flows to >compete with other congestion control transports that adapt on >delay. Even this may not get us to the desired low-delay goals when >a portion of the traffic has long RTTs (i.e., adaptation control >loops that are long in time), or for links that have a highly-time >varying capacity, but it will help for a lot of common bottleneck >topologies (e.g., slowly time-varying access bufferbloat). > >It is my hope that this topic has some discussion time in the Berlin >Transport WG (not the specific codepoint to be chosen, but rather >the need for one). > >Off Soapbox, > >Michael Ramalho, Ph.D. > >-----Original Message----- >From: Michael Ramalho (mramalho) >Sent: Tuesday, July 16, 2013 9:06 AM >To: rmcat@ietf.org >Subject: RE: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. >loss-only rate-adaptive for DiffServ > >RMCAT Design Team, > >The draft Lars references below is a formal request for a DSCP >dedicated to "RMCAT-only (or other nice delay-based cc) traffic". > >It will take a while to become socialized ... and we can progress >our RMCAT work in the interim. > >Michael Ramalho > >-----Original Message----- >From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On >Behalf Of Eggert, Lars >Sent: Tuesday, July 16, 2013 5:26 AM >To: WG WG >Cc: draft-polk-tsvwg-delay-vs-loss-ds-service-classes@tools.ietf.org >Subject: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. loss-only >rate-adaptive for DiffServ > >Possibly of interest to RMCAT. > >Begin forwarded message: > > > From: James Polk > > Subject: [tsvwg] Submitted ID on delay vs. loss-only > rate-adaptive for DiffServ > > Date: July 16, 2013 8:07:59 GMT+02:00 > > To: > > > > (as an author) > > > > Toerless and I put together a draft about legacy rate-adaptation > based only on loss vs. what RMCAT is looking to (for RTCWEB), which > is based on delay and loss. Here's the URL. > > > > > http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt > > > > It's more raw than we had in mind, but we believe this is > necessary, based on implementation experience and what users and > customers have in their networks, or are planning on having in > their networks soon. > > > > James & Toerless > > From jmpolk@cisco.com Tue Jul 16 14:11:33 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868C821F9EEB; Tue, 16 Jul 2013 14:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.272 X-Spam-Level: X-Spam-Status: No, score=-110.272 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nyvv4VVepqCG; Tue, 16 Jul 2013 14:11:29 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E718321F9F13; Tue, 16 Jul 2013 14:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4225; q=dns/txt; s=iport; t=1374009089; x=1375218689; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=jTImcIP8FWj49HsY8MMT2meBoK3l9R3WKeDhKNwQuII=; b=jdVrhFQ+2SvlottlRCE/wLI266jxf8gj61IvDSvQAv+hAcI4dwjL37Lh fN4138vPCmD8a0aH9RkyB6SXCb7d7BEGPp+08eLvOnO2+88oRjbBXYx3n vQrPJk1rCnc/GvirzOY3Mv09TvfSSsOWwhI27btKReHfMfgixQz3wKVsa Q=; X-IronPort-AV: E=Sophos;i="4.89,679,1367971200"; d="scan'208";a="232647120" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 16 Jul 2013 21:11:28 +0000 Received: from jmpolk-WS.cisco.com ([10.89.8.39]) (authenticated bits=0) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6GLBSwF029514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 21:11:28 GMT Message-Id: <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 16 Jul 2013 16:11:27 -0500 To: "Cheng-Jia Lai (chelai)" , "James Polk (jmpolk)" , "Toerless Eckert (eckert)" , "Michael Ramalho (mramalho)" , "tsvwg@ietf.org" , "rmcat@ietf.org" From: James Polk In-Reply-To: References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 21:11:33 -0000 CJ Thank you for the quick review. I'll ask you the same question I just asked Michael, the draft isn't very long (under 8 pages currently), and it is a work in progress - but do you have text or just points that this draft needs to cover that it doesn't currently? James At 01:36 PM 7/16/2013, Cheng-Jia Lai (chelai) wrote: >Same here... I feel it makes sense to create a new DSCP / CS4 for >transport of video flows that have rate adaptive behaviors and/or >intra-flow preferential drop priorities as indicated in the I-D. The >service provided by the network may thus be considered new, i.e. >different from what exists in AF4x, so IMHO, using a new or reusing >CS4 service class adds clarity for the user applications. > >Regards, >CJ > > >-----Original Message----- >From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On >Behalf Of Michael Ramalho (mramalho) >Sent: Tuesday, July 16, 2013 6:36 AM >To: tsvwg@ietf.org >Subject: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs. >loss-only rate-adaptive for DiffServ > >TSVWG Members, > >I should have copied you on my email to the RMCAT mailer below. > >I strongly support the creation of a new DSCP for transports in >which their congestion control can adapt based on delay. > >The current ID in support of this >(http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt >) is a work in progress, but a step in the right direction. > >It is a given that the ability of the eventual RMCAT adaptation >mechanisms to achieve low delay will be function of the other >dominant traffic it is competing against. If the dominant competing >traffic DEPENDS on loss, the RMCAT packets are held hostage to being >delayed by the bottleneck queue delay maximum. > >Thus, whenever possible, it will be preferable for RMCAT flows to >compete with other congestion control transports that adapt on >delay. Even this may not get us to the desired low-delay goals when >a portion of the traffic has long RTTs (i.e., adaptation control >loops that are long in time), or for links that have a highly-time >varying capacity, but it will help for a lot of common bottleneck >topologies (e.g., slowly time-varying access bufferbloat). > >It is my hope that this topic has some discussion time in the Berlin >Transport WG (not the specific codepoint to be chosen, but rather >the need for one). > >Off Soapbox, > >Michael Ramalho, Ph.D. > >-----Original Message----- >From: Michael Ramalho (mramalho) >Sent: Tuesday, July 16, 2013 9:06 AM >To: rmcat@ietf.org >Subject: RE: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. >loss-only rate-adaptive for DiffServ > >RMCAT Design Team, > >The draft Lars references below is a formal request for a DSCP >dedicated to "RMCAT-only (or other nice delay-based cc) traffic". > >It will take a while to become socialized ... and we can progress >our RMCAT work in the interim. > >Michael Ramalho > >-----Original Message----- >From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On >Behalf Of Eggert, Lars >Sent: Tuesday, July 16, 2013 5:26 AM >To: WG WG >Cc: draft-polk-tsvwg-delay-vs-loss-ds-service-classes@tools.ietf.org >Subject: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. loss-only >rate-adaptive for DiffServ > >Possibly of interest to RMCAT. > >Begin forwarded message: > > > From: James Polk > > Subject: [tsvwg] Submitted ID on delay vs. loss-only > rate-adaptive for DiffServ > > Date: July 16, 2013 8:07:59 GMT+02:00 > > To: > > > > (as an author) > > > > Toerless and I put together a draft about legacy rate-adaptation > based only on loss vs. what RMCAT is looking to (for RTCWEB), which > is based on delay and loss. Here's the URL. > > > > > http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt > > > > It's more raw than we had in mind, but we believe this is > necessary, based on implementation experience and what users and > customers have in their networks, or are planning on having in > their networks soon. > > > > James & Toerless > > From eckelcu@cisco.com Tue Jul 16 16:32:42 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBD421F85B3 for ; Tue, 16 Jul 2013 16:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+4KNkkEAg83 for ; Tue, 16 Jul 2013 16:32:37 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA9721F84EF for ; Tue, 16 Jul 2013 16:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3380; q=dns/txt; s=iport; t=1374017553; x=1375227153; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=/WeDx4ZXhr0o0HJ7uzqk4Nwb5pSjFNui/wOh5Ms6f+w=; b=M9TP5YmFRD8gRFCHSp/PQWICEoE3Nne75s4owYMQAUmNC14nbqWx62Wk OAAq8afd1gdJUhnQUJwtKeibk3ltnu2fJBa/krApPtmV0W4TkVzUruKg8 ljql2oeOGHhs0MmSEkjv2inp9ACDfvS32gu1OR+vnRIWB0bYnearR3Uwb Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFADnW5VGtJV2c/2dsb2JhbABagwY0T8IQgRAWdIIjAQEBAwE6RAcEAgEIEQQBAQEKFAkHMhQJCAIEARIIAYgBBQEMtU2PLjgGgwZtA5NEQZUkgxKCKA X-IronPort-AV: E=Sophos;i="4.89,680,1367971200"; d="scan'208";a="235665541" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 16 Jul 2013 23:32:32 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6GNWWOn025569 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 16 Jul 2013 23:32:32 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.187]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 18:32:32 -0500 From: "Charles Eckel (eckelcu)" To: "James Polk (jmpolk)" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for DiffServ Thread-Index: AQHOgmhiyYlbl9BME0qUWX5+uVho8pln8eRA Date: Tue, 16 Jul 2013 23:32:31 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828048B52EC@xmb-aln-x08.cisco.com> References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <92B7E61ADAC1BB4F941F943788C08828048B5077@xmb-aln-x08.cisco.com> <201307162106.r6GL6khf029009@rcdn-core-2.cisco.com> In-Reply-To: <201307162106.r6GL6khf029009@rcdn-core-2.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 23:32:42 -0000 > -----Original Message----- > From: James Polk (jmpolk) > Sent: Tuesday, July 16, 2013 2:07 PM > To: Charles Eckel (eckelcu); tsvwg@ietf.org > Cc: James Polk (jmpolk) > Subject: RE: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive fo= r > DiffServ >=20 > At 03:46 PM 7/16/2013, Charles Eckel (eckelcu) wrote: > >I read the draft and thank you for addressing this need. It does a > >good job of making the case for the need to differentiate the DSCP > >assignments of delay-and-loss-based vs. just-loss-based > >rate-adaptive video applications. While I do not agree with some of > >the finer points in the draft, including the statement in section 3 > >that AF4x traffic in general is inelastic/fixed bitrate, >=20 > Charles >=20 > Thank you for the quick review! >=20 > If we authors gave the impression that all AF4X marked traffic is > inelastic and uses the 'same' fixed bitrates, we apologize. However, > each AF4X flow from a given codec - be it audio or video - in today's > implementations, pretty much use the same bitrate per flow (not the > same bitrate for each flow). Do you agree with this clarification, or > would you like to offer substitute/replacement text in the offending sect= ion? I think video codec implementations in the AF4X class today often have vari= able bit rates; however, those variations are primarily due to the amount o= f motion and sometimes as an adaptation to loss. The latter is what is impo= rtant in this discussion. Video codecs will continue to have variable bit r= ates in accordance with the amount of motion, but if aligned with the outpu= t of RMCAT, they will adapt based on delay as well as loss.=20 Cheers, Charles =20 > James >=20 > > I completely agree that this traffic is largely loss sensitive and > > yet often relies on loss based adaption. > >The assignment of a new service class and the proposal for CS4 and > >CS4-Discardable for rate-adaptive video makes sense to me. At the > >same time, it is important to re-designate AF4x as you describe in > >order to match the reality of today's deployments and avoid future confu= sion. > >I look forward to seeing this work progress as it offer an incentive > >for applications to embrace congestion control algorithms such as > >those being developed in RMCAT without fearing they will be overrun > >by non-delay adaptive traffic. > > > >Cheers, > >Charles > > > > > > > -----Original Message----- > > > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behal= f > Of > > > James Polk (jmpolk) > > > Sent: Monday, July 15, 2013 11:08 PM > > > To: tsvwg@ietf.org > > > Subject: [tsvwg] Submitted ID on delay vs. loss-only > > rate-adaptive for DiffServ > > > > > > (as an author) > > > > > > Toerless and I put together a draft about legacy rate-adaptation > > > based only on loss vs. what RMCAT is looking to (for RTCWEB), which > > > is based on delay and loss. Here's the URL. > > > > > > > > http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds- > service- > > > classes-00.txt > > > > > > It's more raw than we had in mind, but we believe this is necessary, > > > based on implementation experience and what users and customers have > > > in their networks, or are planning on having in their networks soon. > > > > > > James & Toerless From jmpolk@cisco.com Tue Jul 16 16:40:36 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C957421F9C7B for ; Tue, 16 Jul 2013 16:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDAiiraNwfnG for ; Tue, 16 Jul 2013 16:40:32 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4D96721F9C7D for ; Tue, 16 Jul 2013 16:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3626; q=dns/txt; s=iport; t=1374018032; x=1375227632; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=vut5Rib05chV0m7eIYuL7ao/mlVo5rA32kEYrJSyL6Q=; b=mEY6XEqVtZXzL4gI1mzXj+Fjn6lysrMWLOUbiWmig3pA4xPPJEZbbMh+ tfvkfDHb8OrnBr7Ye20H/3S/7Bd1K1VM15qHYAidzKe5lYA8FmaIauLia akeTuMi0EH7X930WlZxB2FtmnX/6c92DH88ZQTGNEwIQ0BsAqs4vcUNUl Y=; X-IronPort-AV: E=Sophos;i="4.89,680,1367971200"; d="scan'208";a="235680100" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 16 Jul 2013 23:40:30 +0000 Received: from jmpolk-WS.cisco.com ([10.89.8.39]) (authenticated bits=0) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6GNeThb021165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 23:40:29 GMT Message-Id: <201307162340.r6GNeThb021165@rcdn-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 16 Jul 2013 18:40:29 -0500 To: "Charles Eckel (eckelcu)" , "James Polk (jmpolk)" , "tsvwg@ietf.org" From: James Polk In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828048B52EC@xmb-aln-x08.cisco .com> References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <92B7E61ADAC1BB4F941F943788C08828048B5077@xmb-aln-x08.cisco.com> <201307162106.r6GL6khf029009@rcdn-core-2.cisco.com> <92B7E61ADAC1BB4F941F943788C08828048B52EC@xmb-aln-x08.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 23:40:36 -0000 At 06:32 PM 7/16/2013, Charles Eckel (eckelcu) wrote: > > -----Original Message----- > > From: James Polk (jmpolk) > > Sent: Tuesday, July 16, 2013 2:07 PM > > To: Charles Eckel (eckelcu); tsvwg@ietf.org > > Cc: James Polk (jmpolk) > > Subject: RE: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for > > DiffServ > > > > At 03:46 PM 7/16/2013, Charles Eckel (eckelcu) wrote: > > >I read the draft and thank you for addressing this need. It does a > > >good job of making the case for the need to differentiate the DSCP > > >assignments of delay-and-loss-based vs. just-loss-based > > >rate-adaptive video applications. While I do not agree with some of > > >the finer points in the draft, including the statement in section 3 > > >that AF4x traffic in general is inelastic/fixed bitrate, > > > > Charles > > > > Thank you for the quick review! > > > > If we authors gave the impression that all AF4X marked traffic is > > inelastic and uses the 'same' fixed bitrates, we apologize. However, > > each AF4X flow from a given codec - be it audio or video - in today's > > implementations, pretty much use the same bitrate per flow (not the > > same bitrate for each flow). Do you agree with this clarification, or > > would you like to offer substitute/replacement text in the > offending section? > >I think video codec implementations in the AF4X class today often >have variable bit rates; however, those variations are primarily due >to the amount of motion and sometimes as an adaptation to loss. The >latter is what is important in this discussion. Video codecs will >continue to have variable bit rates in accordance with the amount of >motion, but if aligned with the output of RMCAT, they will adapt >based on delay as well as loss. Thanks - we'll include those points in the next version. James >Cheers, >Charles > > > > James > > > > > I completely agree that this traffic is largely loss sensitive and > > > yet often relies on loss based adaption. > > >The assignment of a new service class and the proposal for CS4 and > > >CS4-Discardable for rate-adaptive video makes sense to me. At the > > >same time, it is important to re-designate AF4x as you describe in > > >order to match the reality of today's deployments and avoid > future confusion. > > >I look forward to seeing this work progress as it offer an incentive > > >for applications to embrace congestion control algorithms such as > > >those being developed in RMCAT without fearing they will be overrun > > >by non-delay adaptive traffic. > > > > > >Cheers, > > >Charles > > > > > > > > > > -----Original Message----- > > > > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf > > Of > > > > James Polk (jmpolk) > > > > Sent: Monday, July 15, 2013 11:08 PM > > > > To: tsvwg@ietf.org > > > > Subject: [tsvwg] Submitted ID on delay vs. loss-only > > > rate-adaptive for DiffServ > > > > > > > > (as an author) > > > > > > > > Toerless and I put together a draft about legacy rate-adaptation > > > > based only on loss vs. what RMCAT is looking to (for RTCWEB), which > > > > is based on delay and loss. Here's the URL. > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds- > > service- > > > > classes-00.txt > > > > > > > > It's more raw than we had in mind, but we believe this is necessary, > > > > based on implementation experience and what users and customers have > > > > in their networks, or are planning on having in their networks soon. > > > > > > > > James & Toerless From mzanaty@cisco.com Tue Jul 16 20:23:19 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C9521F9CA1; Tue, 16 Jul 2013 20:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.935 X-Spam-Level: X-Spam-Status: No, score=-9.935 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6nylqL3SaS2; Tue, 16 Jul 2013 20:23:14 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id AEB6E21F9AEE; Tue, 16 Jul 2013 20:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5490; q=dns/txt; s=iport; t=1374031393; x=1375240993; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=TXMzN7AE9tPnPsnArv5QIlGhzX43VyYZUtMH9BGTJv8=; b=bvTfunldjQKsWM/9y9XWT1nC9fvBUH51k8lOv1dq/JJxg8moI4a4HKcp uXnNWlehNiPnVFZk6rVIQoOOzGe+C/tFmtg8khx2zRs0H6HRH/LwZ3B1h wU+GyPY8wERs2LnmCRwWEx7dmygh5i61BGoO6RmkZepnJFBs1ru3S+I19 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAPoM5lGtJV2d/2dsb2JhbABagwY0T8IrgQ0WdIIjAQEBBDpLBAIBCBEDAQEBAQoUCQcyFAgBCAIEARIIAYgHDLVSjz04BoMGbgOpKYFZgTmCKA X-IronPort-AV: E=Sophos;i="4.89,682,1367971200"; d="scan'208";a="235741391" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 17 Jul 2013 03:23:13 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6H3NC8W006020 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 03:23:12 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 22:23:12 -0500 From: "Mo Zanaty (mzanaty)" To: "James Polk (jmpolk)" , "Cheng-Jia Lai (chelai)" , "Toerless Eckert (eckert)" , "Michael Ramalho (mramalho)" , "tsvwg@ietf.org" , "rmcat@ietf.org" Thread-Topic: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ Thread-Index: AQHOgmkPCJii7CPYUk2ch+5QoO+R/JloLzYQ Date: Wed, 17 Jul 2013 03:23:11 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> In-Reply-To: <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.251.178] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 03:23:19 -0000 I support something like what this draft proposes, to segregate RMCAT (and = potentially other delay-adaptive traffic) from other traffic which does not= adapt to delay trends (and therefore incurs maximum queue delay for all tr= affic in its queue). Of course, this only helps when such queue segregation= is available in the network, but effective active queue management is not = available (otherwise there would be no delay signals for delay-adaptive tra= ffic to act on). An open question in my mind, that I think this draft needs to address, is w= hether all delay-adaptive traffic should share the same queue/DSCP, or whet= her we need different queues/DSCPs for different delay-adaptive protocols/a= pplications (for example, RMCAT vs. LEDBAT). Mo -----Original Message----- From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of J= ames Polk (jmpolk) Sent: Tuesday, July 16, 2013 5:11 PM To: Cheng-Jia Lai (chelai); James Polk (jmpolk); Toerless Eckert (eckert); = Michael Ramalho (mramalho); tsvwg@ietf.org; rmcat@ietf.org Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only r= ate-adaptive for DiffServ CJ Thank you for the quick review. I'll ask you the same question I just asked Michael, the draft isn't=20 very long (under 8 pages currently), and it is a work in progress -=20 but do you have text or just points that this draft needs to cover=20 that it doesn't currently? James At 01:36 PM 7/16/2013, Cheng-Jia Lai (chelai) wrote: >Same here... I feel it makes sense to create a new DSCP / CS4 for=20 >transport of video flows that have rate adaptive behaviors and/or=20 >intra-flow preferential drop priorities as indicated in the I-D. The=20 >service provided by the network may thus be considered new, i.e.=20 >different from what exists in AF4x, so IMHO, using a new or reusing=20 >CS4 service class adds clarity for the user applications. > >Regards, >CJ > > >-----Original Message----- >From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On=20 >Behalf Of Michael Ramalho (mramalho) >Sent: Tuesday, July 16, 2013 6:36 AM >To: tsvwg@ietf.org >Subject: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs.=20 >loss-only rate-adaptive for DiffServ > >TSVWG Members, > >I should have copied you on my email to the RMCAT mailer below. > >I strongly support the creation of a new DSCP for transports in=20 >which their congestion control can adapt based on delay. > >The current ID in support of this=20 >(http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-ser= vice-classes-00.txt=20 >) is a work in progress, but a step in the right direction. > >It is a given that the ability of the eventual RMCAT adaptation=20 >mechanisms to achieve low delay will be function of the other=20 >dominant traffic it is competing against. If the dominant competing=20 >traffic DEPENDS on loss, the RMCAT packets are held hostage to being=20 >delayed by the bottleneck queue delay maximum. > >Thus, whenever possible, it will be preferable for RMCAT flows to=20 >compete with other congestion control transports that adapt on=20 >delay. Even this may not get us to the desired low-delay goals when=20 >a portion of the traffic has long RTTs (i.e., adaptation control=20 >loops that are long in time), or for links that have a highly-time=20 >varying capacity, but it will help for a lot of common bottleneck=20 >topologies (e.g., slowly time-varying access bufferbloat). > >It is my hope that this topic has some discussion time in the Berlin=20 >Transport WG (not the specific codepoint to be chosen, but rather=20 >the need for one). > >Off Soapbox, > >Michael Ramalho, Ph.D. > >-----Original Message----- >From: Michael Ramalho (mramalho) >Sent: Tuesday, July 16, 2013 9:06 AM >To: rmcat@ietf.org >Subject: RE: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs.=20 >loss-only rate-adaptive for DiffServ > >RMCAT Design Team, > >The draft Lars references below is a formal request for a DSCP=20 >dedicated to "RMCAT-only (or other nice delay-based cc) traffic". > >It will take a while to become socialized ... and we can progress=20 >our RMCAT work in the interim. > >Michael Ramalho > >-----Original Message----- >From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On=20 >Behalf Of Eggert, Lars >Sent: Tuesday, July 16, 2013 5:26 AM >To: WG WG >Cc: draft-polk-tsvwg-delay-vs-loss-ds-service-classes@tools.ietf.org >Subject: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. loss-only=20 >rate-adaptive for DiffServ > >Possibly of interest to RMCAT. > >Begin forwarded message: > > > From: James Polk > > Subject: [tsvwg] Submitted ID on delay vs. loss-only=20 > rate-adaptive for DiffServ > > Date: July 16, 2013 8:07:59 GMT+02:00 > > To: > > > > (as an author) > > > > Toerless and I put together a draft about legacy rate-adaptation=20 > based only on loss vs. what RMCAT is looking to (for RTCWEB), which=20 > is based on delay and loss. Here's the URL. > > > >=20 > http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-ser= vice-classes-00.txt > > > > It's more raw than we had in mind, but we believe this is=20 > necessary, based on implementation experience and what users and=20 > customers have in their networks, or are planning on having in=20 > their networks soon. > > > > James & Toerless > > From gorry@erg.abdn.ac.uk Tue Jul 16 23:50:16 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3AD21F9702; Tue, 16 Jul 2013 23:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.214 X-Spam-Level: X-Spam-Status: No, score=-106.214 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGl4E1P-qPKl; Tue, 16 Jul 2013 23:50:11 -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 B742421F8438; Tue, 16 Jul 2013 23:50:10 -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 F23DA2B41D5; Wed, 17 Jul 2013 07:50:08 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 17 Jul 2013 07:50:09 +0100 Message-ID: In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> Date: Wed, 17 Jul 2013 07:50:09 +0100 From: gorry@erg.abdn.ac.uk To: "Mo Zanaty (mzanaty)" 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 Cc: "tsvwg@ietf.org" , "rmcat@ietf.org" , "Michael Ramalho \(mramalho\)" , "James Polk \(jmpolk\)" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 06:50:16 -0000 I think the question of sharing diffserv is important, and my current suggestion is that RMCAT should use one or at most two DSCPs and design a CC that works well within the class - however this does not absolve RMCAT from also having to work in the Internet without this class. This will likely be the main use-case! Although the proposal could help these applications - the IETF can not somehow mandate this is universally deployed - and even if the DSCP(s) were universally recognised, it would still be aggregated within some networks and on L2 technologies that support fewer classes than DSCP markings. It would be interesting to know if others think we should be considering more DSCPs for this? Gorry > I support something like what this draft proposes, to segregate RMCAT (and > potentially other delay-adaptive traffic) from other traffic which does > not adapt to delay trends (and therefore incurs maximum queue delay for > all traffic in its queue). Of course, this only helps when such queue > segregation is available in the network, but effective active queue > management is not available (otherwise there would be no delay signals for > delay-adaptive traffic to act on). > > An open question in my mind, that I think this draft needs to address, is > whether all delay-adaptive traffic should share the same queue/DSCP, or > whether we need different queues/DSCPs for different delay-adaptive > protocols/applications (for example, RMCAT vs. LEDBAT). > > Mo > > -----Original Message----- > From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of > James Polk (jmpolk) > Sent: Tuesday, July 16, 2013 5:11 PM > To: Cheng-Jia Lai (chelai); James Polk (jmpolk); Toerless Eckert (eckert); > Michael Ramalho (mramalho); tsvwg@ietf.org; rmcat@ietf.org > Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only > rate-adaptive for DiffServ > > CJ > > Thank you for the quick review. > > I'll ask you the same question I just asked Michael, the draft isn't > very long (under 8 pages currently), and it is a work in progress - > but do you have text or just points that this draft needs to cover > that it doesn't currently? > > James > > At 01:36 PM 7/16/2013, Cheng-Jia Lai (chelai) wrote: >>Same here... I feel it makes sense to create a new DSCP / CS4 for >>transport of video flows that have rate adaptive behaviors and/or >>intra-flow preferential drop priorities as indicated in the I-D. The >>service provided by the network may thus be considered new, i.e. >>different from what exists in AF4x, so IMHO, using a new or reusing >>CS4 service class adds clarity for the user applications. >> >>Regards, >>CJ >> >> >>-----Original Message----- >>From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On >>Behalf Of Michael Ramalho (mramalho) >>Sent: Tuesday, July 16, 2013 6:36 AM >>To: tsvwg@ietf.org >>Subject: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs. >>loss-only rate-adaptive for DiffServ >> >>TSVWG Members, >> >>I should have copied you on my email to the RMCAT mailer below. >> >>I strongly support the creation of a new DSCP for transports in >>which their congestion control can adapt based on delay. >> >>The current ID in support of this >>(http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt >>) is a work in progress, but a step in the right direction. >> >>It is a given that the ability of the eventual RMCAT adaptation >>mechanisms to achieve low delay will be function of the other >>dominant traffic it is competing against. If the dominant competing >>traffic DEPENDS on loss, the RMCAT packets are held hostage to being >>delayed by the bottleneck queue delay maximum. >> >>Thus, whenever possible, it will be preferable for RMCAT flows to >>compete with other congestion control transports that adapt on >>delay. Even this may not get us to the desired low-delay goals when >>a portion of the traffic has long RTTs (i.e., adaptation control >>loops that are long in time), or for links that have a highly-time >>varying capacity, but it will help for a lot of common bottleneck >>topologies (e.g., slowly time-varying access bufferbloat). >> >>It is my hope that this topic has some discussion time in the Berlin >>Transport WG (not the specific codepoint to be chosen, but rather >>the need for one). >> >>Off Soapbox, >> >>Michael Ramalho, Ph.D. >> >>-----Original Message----- >>From: Michael Ramalho (mramalho) >>Sent: Tuesday, July 16, 2013 9:06 AM >>To: rmcat@ietf.org >>Subject: RE: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. >>loss-only rate-adaptive for DiffServ >> >>RMCAT Design Team, >> >>The draft Lars references below is a formal request for a DSCP >>dedicated to "RMCAT-only (or other nice delay-based cc) traffic". >> >>It will take a while to become socialized ... and we can progress >>our RMCAT work in the interim. >> >>Michael Ramalho >> >>-----Original Message----- >>From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On >>Behalf Of Eggert, Lars >>Sent: Tuesday, July 16, 2013 5:26 AM >>To: WG WG >>Cc: draft-polk-tsvwg-delay-vs-loss-ds-service-classes@tools.ietf.org >>Subject: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. loss-only >>rate-adaptive for DiffServ >> >>Possibly of interest to RMCAT. >> >>Begin forwarded message: >> >> > From: James Polk >> > Subject: [tsvwg] Submitted ID on delay vs. loss-only >> rate-adaptive for DiffServ >> > Date: July 16, 2013 8:07:59 GMT+02:00 >> > To: >> > >> > (as an author) >> > >> > Toerless and I put together a draft about legacy rate-adaptation >> based only on loss vs. what RMCAT is looking to (for RTCWEB), which >> is based on delay and loss. Here's the URL. >> > >> > >> http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt >> > >> > It's more raw than we had in mind, but we believe this is >> necessary, based on implementation experience and what users and >> customers have in their networks, or are planning on having in >> their networks soon. >> > >> > James & Toerless >> > > From michawe@ifi.uio.no Wed Jul 17 08:59:30 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0519921F9D9A; Wed, 17 Jul 2013 08:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8IW1DrYERHl; Wed, 17 Jul 2013 08:59:25 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 11FC721F8E1F; Wed, 17 Jul 2013 08:59:25 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1UzU8R-0006H0-EZ; Wed, 17 Jul 2013 17:59:23 +0200 Received: from 089144206079.atnat0015.highway.bob.at ([89.144.206.79] helo=[192.168.1.6]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UzU8P-0004mx-JP; Wed, 17 Jul 2013 17:59:23 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Welzl In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> Date: Wed, 17 Jul 2013 17:59:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9CCDAE4B-CA8E-4107-80EB-B7DD020CC9D1@ifi.uio.no> References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> To: Mo Zanaty (mzanaty) X-Mailer: Apple Mail (2.1508) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 22 msgs/h 9 sum rcpts/h 29 sum msgs/h 14 total rcpts 5801 max rcpts/h 40 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: 3394EAB07E4490447B8290DFABDD84BA4E15D334 X-UiO-SPAM-Test: remote_host: 89.144.206.79 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 9 total 42 max/h 10 blacklist 0 greylist 0 ratelimit 0 Cc: "tsvwg@ietf.org" , "rmcat@ietf.org" , "Michael Ramalho \(mramalho\)" , "James Polk \(jmpolk\)" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 15:59:30 -0000 +1 On Jul 17, 2013, at 5:23 AM, Mo Zanaty (mzanaty) = wrote: > I support something like what this draft proposes, to segregate RMCAT = (and potentially other delay-adaptive traffic) from other traffic which = does not adapt to delay trends (and therefore incurs maximum queue delay = for all traffic in its queue). Of course, this only helps when such = queue segregation is available in the network, but effective active = queue management is not available (otherwise there would be no delay = signals for delay-adaptive traffic to act on). >=20 > An open question in my mind, that I think this draft needs to address, = is whether all delay-adaptive traffic should share the same queue/DSCP, = or whether we need different queues/DSCPs for different delay-adaptive = protocols/applications (for example, RMCAT vs. LEDBAT). >=20 > Mo >=20 > -----Original Message----- > From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf = Of James Polk (jmpolk) > Sent: Tuesday, July 16, 2013 5:11 PM > To: Cheng-Jia Lai (chelai); James Polk (jmpolk); Toerless Eckert = (eckert); Michael Ramalho (mramalho); tsvwg@ietf.org; rmcat@ietf.org > Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. = loss-only rate-adaptive for DiffServ >=20 > CJ >=20 > Thank you for the quick review. >=20 > I'll ask you the same question I just asked Michael, the draft isn't=20= > very long (under 8 pages currently), and it is a work in progress -=20 > but do you have text or just points that this draft needs to cover=20 > that it doesn't currently? >=20 > James >=20 > At 01:36 PM 7/16/2013, Cheng-Jia Lai (chelai) wrote: >> Same here... I feel it makes sense to create a new DSCP / CS4 for=20 >> transport of video flows that have rate adaptive behaviors and/or=20 >> intra-flow preferential drop priorities as indicated in the I-D. The=20= >> service provided by the network may thus be considered new, i.e.=20 >> different from what exists in AF4x, so IMHO, using a new or reusing=20= >> CS4 service class adds clarity for the user applications. >>=20 >> Regards, >> CJ >>=20 >>=20 >> -----Original Message----- >> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On=20 >> Behalf Of Michael Ramalho (mramalho) >> Sent: Tuesday, July 16, 2013 6:36 AM >> To: tsvwg@ietf.org >> Subject: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs.=20 >> loss-only rate-adaptive for DiffServ >>=20 >> TSVWG Members, >>=20 >> I should have copied you on my email to the RMCAT mailer below. >>=20 >> I strongly support the creation of a new DSCP for transports in=20 >> which their congestion control can adapt based on delay. >>=20 >> The current ID in support of this=20 >> = (http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-ser= vice-classes-00.txt=20 >> ) is a work in progress, but a step in the right direction. >>=20 >> It is a given that the ability of the eventual RMCAT adaptation=20 >> mechanisms to achieve low delay will be function of the other=20 >> dominant traffic it is competing against. If the dominant competing=20= >> traffic DEPENDS on loss, the RMCAT packets are held hostage to being=20= >> delayed by the bottleneck queue delay maximum. >>=20 >> Thus, whenever possible, it will be preferable for RMCAT flows to=20 >> compete with other congestion control transports that adapt on=20 >> delay. Even this may not get us to the desired low-delay goals when=20= >> a portion of the traffic has long RTTs (i.e., adaptation control=20 >> loops that are long in time), or for links that have a highly-time=20 >> varying capacity, but it will help for a lot of common bottleneck=20 >> topologies (e.g., slowly time-varying access bufferbloat). >>=20 >> It is my hope that this topic has some discussion time in the Berlin=20= >> Transport WG (not the specific codepoint to be chosen, but rather=20 >> the need for one). >>=20 >> Off Soapbox, >>=20 >> Michael Ramalho, Ph.D. >>=20 >> -----Original Message----- >> From: Michael Ramalho (mramalho) >> Sent: Tuesday, July 16, 2013 9:06 AM >> To: rmcat@ietf.org >> Subject: RE: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs.=20 >> loss-only rate-adaptive for DiffServ >>=20 >> RMCAT Design Team, >>=20 >> The draft Lars references below is a formal request for a DSCP=20 >> dedicated to "RMCAT-only (or other nice delay-based cc) traffic". >>=20 >> It will take a while to become socialized ... and we can progress=20 >> our RMCAT work in the interim. >>=20 >> Michael Ramalho >>=20 >> -----Original Message----- >> From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On=20 >> Behalf Of Eggert, Lars >> Sent: Tuesday, July 16, 2013 5:26 AM >> To: WG WG >> Cc: draft-polk-tsvwg-delay-vs-loss-ds-service-classes@tools.ietf.org >> Subject: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. loss-only=20 >> rate-adaptive for DiffServ >>=20 >> Possibly of interest to RMCAT. >>=20 >> Begin forwarded message: >>=20 >>> From: James Polk >>> Subject: [tsvwg] Submitted ID on delay vs. loss-only=20 >> rate-adaptive for DiffServ >>> Date: July 16, 2013 8:07:59 GMT+02:00 >>> To: >>>=20 >>> (as an author) >>>=20 >>> Toerless and I put together a draft about legacy rate-adaptation=20 >> based only on loss vs. what RMCAT is looking to (for RTCWEB), which=20= >> is based on delay and loss. Here's the URL. >>>=20 >>>=20 >> = http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-serv= ice-classes-00.txt >>>=20 >>> It's more raw than we had in mind, but we believe this is=20 >> necessary, based on implementation experience and what users and=20 >> customers have in their networks, or are planning on having in=20 >> their networks soon. >>>=20 >>> James & Toerless >>>=20 >=20 From wes@mti-systems.com Wed Jul 17 11:26:48 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF7221E8084 for ; Wed, 17 Jul 2013 11:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCbhra-rsQgh for ; Wed, 17 Jul 2013 11:26:41 -0700 (PDT) Received: from atl4mhob08.myregisteredsite.com (atl4mhob08.myregisteredsite.com [209.17.115.46]) by ietfa.amsl.com (Postfix) with ESMTP id B7E0B21E804B for ; Wed, 17 Jul 2013 11:26:37 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.207]) by atl4mhob08.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r6HIQbvj008292 for ; Wed, 17 Jul 2013 14:26:37 -0400 Received: (qmail 11414 invoked by uid 0); 17 Jul 2013 18:26:37 -0000 X-TCPREMOTEIP: 107.47.151.64 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.47.151.64) by 0 with ESMTPA; 17 Jul 2013 18:26:36 -0000 Message-ID: <51E6E1D5.1050006@mti-systems.com> Date: Wed, 17 Jul 2013 14:26:29 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Mo Zanaty (mzanaty)" References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tsvwg@ietf.org" , "rmcat@ietf.org" , "Michael Ramalho \(mramalho\)" , "James Polk \(jmpolk\)" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 18:26:48 -0000 On 7/16/2013 11:23 PM, Mo Zanaty (mzanaty) wrote: > > An open question in my mind, that I think this draft needs to address, is whether all delay-adaptive traffic should share the same queue/DSCP, or whether we need different queues/DSCPs for different delay-adaptive protocols/applications (for example, RMCAT vs. LEDBAT). > Given that everything in the same queue will measure the same delays, it seems to me like separating flows into queues would be based on the relative target delays of the flows (tunable per-flow) and NOT the algorithm used (as you say, RMCAT vs LEDBAT). It is not wise, in my opinion, to have algorithm-specific DSCPs. The DSCPs need to indicate the desired forwarding behavior, and not what version of code the end-host runs. -- Wes Eddy MTI Systems From mzanaty@cisco.com Wed Jul 17 12:00:32 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B11021E809B; Wed, 17 Jul 2013 12:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.43 X-Spam-Level: X-Spam-Status: No, score=-10.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPAMLyjGMyiQ; Wed, 17 Jul 2013 12:00:26 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5E711E80E2; Wed, 17 Jul 2013 12:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1506; q=dns/txt; s=iport; t=1374087626; x=1375297226; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FRleAFZdbbeFpdtnTynqHtDMajU/1A085DaLWQYd6bo=; b=KQowT+YS/vDCU7Bw8LeVFtulWb33QeO8v1A5wQDVZ53N3Lj3FJUZKwZC F8gXlWvbtxeValLIxqo3nj+VldQj2bCTkUltcuf/hGjjwq+y5T0bFe8LS otdpfPyitw2ST9OoUUGoG3Tg+818zhBfUkUYkmOlkPaUsBFw5vJ5MLQTz M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAAPo5lGtJXG+/2dsb2JhbABagwaBBMF6gREWdIIjAQEBBDo/DAQCAQgOAwQBAQEKFAkHMhQIAQgCBA4FCIgItX+PSTEHBoMHbgOpKYFZgTmCKA X-IronPort-AV: E=Sophos;i="4.89,686,1367971200"; d="scan'208";a="236076637" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 17 Jul 2013 19:00:25 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6HJ0O9h029964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 19:00:25 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 14:00:24 -0500 From: "Mo Zanaty (mzanaty)" To: Wesley Eddy Thread-Topic: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ Thread-Index: AQHOgmkPCJii7CPYUk2ch+5QoO+R/JloLzYQgAFWGID//7MvoA== Date: Wed, 17 Jul 2013 19:00:23 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D494E45@xmb-rcd-x14.cisco.com> References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> <51E6E1D5.1050006@mti-systems.com> In-Reply-To: <51E6E1D5.1050006@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.210.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tsvwg@ietf.org" , "rmcat@ietf.org" , "Michael Ramalho \(mramalho\)" , "James Polk \(jmpolk\)" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 19:00:32 -0000 Agreed. I should have clarified in my RMCAT vs. LEDBAT example that the key= difference (for queue dynamics) is the target delay of near-zero vs. 100 m= s. (Near-zero is debatable to mean anything well below 100 ms. I've heard 5= 0, 25, and even 0 mentioned as potential targets in RMCAT.) Mo -----Original Message----- From: Wesley Eddy [mailto:wes@mti-systems.com]=20 Sent: Wednesday, July 17, 2013 2:26 PM To: Mo Zanaty (mzanaty) Cc: James Polk (jmpolk); Cheng-Jia Lai (chelai); Toerless Eckert (eckert); = Michael Ramalho (mramalho); tsvwg@ietf.org; rmcat@ietf.org Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only r= ate-adaptive for DiffServ On 7/16/2013 11:23 PM, Mo Zanaty (mzanaty) wrote: > > An open question in my mind, that I think this draft needs to address, is= whether all delay-adaptive traffic should share the same queue/DSCP, or wh= ether we need different queues/DSCPs for different delay-adaptive protocols= /applications (for example, RMCAT vs. LEDBAT). >=20 Given that everything in the same queue will measure the same delays, it seems to me like separating flows into queues would be based on the relative target delays of the flows (tunable per-flow) and NOT the algorithm used (as you say, RMCAT vs LEDBAT). It is not wise, in my opinion, to have algorithm-specific DSCPs. The DSCPs need to indicate the desired forwarding behavior, and not what version of code the end-host runs. --=20 Wes Eddy MTI Systems From brian.e.carpenter@gmail.com Wed Jul 17 12:55:48 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D2621E808F; Wed, 17 Jul 2013 12:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.202 X-Spam-Level: X-Spam-Status: No, score=-102.202 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9q12SWwZBGL; Wed, 17 Jul 2013 12:55:48 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2807821E808E; Wed, 17 Jul 2013 12:55:48 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kq14so1223298pab.11 for ; Wed, 17 Jul 2013 12:55:47 -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=fDpb336s2yPg/i3JFSLDqJoKOLkmWuYd3jt28YEfpy0=; b=Jmpd8zQH22R3VMH9NV/tCiTXTGfFIkEg3YxxIrF0p1idIz1aOLkGR7NxKg9Vj29C5C 1nZ2lRNS1nruN03fSglc8vIQrblQhr/DqOinlwgGfoHpIfXfBh7JklQVrhc4TJRWa5+L s9HGdclv9ZZvlI/q5icAw4+xJO1xB5S99J7re+CGhX54geUN4kb7YUPrOeeiHHyjIvdP GfDjpsw1HtHaRb727v6LIYrtamxHg1MFGVAL0oHTCjaRnty4tEFJhLlLcPFLPN9fFJpr lbUjLnJOsNOjX51inyopnsj5T25tTSJW/YJK4hjVToHUtQZ9a/11hyvtnB9AJoNZeGIj jc9g== X-Received: by 10.66.163.130 with SMTP id yi2mr9565837pab.7.1374090947845; Wed, 17 Jul 2013 12:55:47 -0700 (PDT) Received: from [192.168.178.23] (33.198.69.111.dynamic.snap.net.nz. [111.69.198.33]) by mx.google.com with ESMTPSA id ib9sm9383159pbc.43.2013.07.17.12.55.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Jul 2013 12:55:46 -0700 (PDT) Message-ID: <51E6F6C2.8090202@gmail.com> Date: Thu, 18 Jul 2013 07:55:46 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "rmcat@ietf.org" , "Michael Ramalho \(mramalho\)" , "James Polk \(jmpolk\)" , "Mo Zanaty \(mzanaty\)" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 19:55:49 -0000 On 17/07/2013 18:50, gorry@erg.abdn.ac.uk wrote: > I think the question of sharing diffserv is important, and my current > suggestion is that RMCAT should use one or at most two DSCPs and design a > CC that works well within the class - however this does not absolve RMCAT > from also having to work in the Internet without this class. This will > likely be the main use-case! > > Although the proposal could help these applications - the IETF can not > somehow mandate this is universally deployed - and even if the DSCP(s) > were universally recognised, it would still be aggregated within some > networks and on L2 technologies that support fewer classes than DSCP > markings. > > It would be interesting to know if others think we should be considering > more DSCPs for this? If you mean "more" in the sense of defining new PHBs, I sincerely hope not. Diffserv works best with a small set of highly differentiated PHBs. Also, in order to get cross-domain agreements on DSCP assignments, the fewer there are the better. Brian > > Gorry > >> I support something like what this draft proposes, to segregate RMCAT (and >> potentially other delay-adaptive traffic) from other traffic which does >> not adapt to delay trends (and therefore incurs maximum queue delay for >> all traffic in its queue). Of course, this only helps when such queue >> segregation is available in the network, but effective active queue >> management is not available (otherwise there would be no delay signals for >> delay-adaptive traffic to act on). >> >> An open question in my mind, that I think this draft needs to address, is >> whether all delay-adaptive traffic should share the same queue/DSCP, or >> whether we need different queues/DSCPs for different delay-adaptive >> protocols/applications (for example, RMCAT vs. LEDBAT). >> >> Mo >> >> -----Original Message----- >> From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of >> James Polk (jmpolk) >> Sent: Tuesday, July 16, 2013 5:11 PM >> To: Cheng-Jia Lai (chelai); James Polk (jmpolk); Toerless Eckert (eckert); >> Michael Ramalho (mramalho); tsvwg@ietf.org; rmcat@ietf.org >> Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only >> rate-adaptive for DiffServ >> >> CJ >> >> Thank you for the quick review. >> >> I'll ask you the same question I just asked Michael, the draft isn't >> very long (under 8 pages currently), and it is a work in progress - >> but do you have text or just points that this draft needs to cover >> that it doesn't currently? >> >> James >> >> At 01:36 PM 7/16/2013, Cheng-Jia Lai (chelai) wrote: >>> Same here... I feel it makes sense to create a new DSCP / CS4 for >>> transport of video flows that have rate adaptive behaviors and/or >>> intra-flow preferential drop priorities as indicated in the I-D. The >>> service provided by the network may thus be considered new, i.e. >>> different from what exists in AF4x, so IMHO, using a new or reusing >>> CS4 service class adds clarity for the user applications. >>> >>> Regards, >>> CJ >>> >>> >>> -----Original Message----- >>> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On >>> Behalf Of Michael Ramalho (mramalho) >>> Sent: Tuesday, July 16, 2013 6:36 AM >>> To: tsvwg@ietf.org >>> Subject: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs. >>> loss-only rate-adaptive for DiffServ >>> >>> TSVWG Members, >>> >>> I should have copied you on my email to the RMCAT mailer below. >>> >>> I strongly support the creation of a new DSCP for transports in >>> which their congestion control can adapt based on delay. >>> >>> The current ID in support of this >>> (http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt >>> ) is a work in progress, but a step in the right direction. >>> >>> It is a given that the ability of the eventual RMCAT adaptation >>> mechanisms to achieve low delay will be function of the other >>> dominant traffic it is competing against. If the dominant competing >>> traffic DEPENDS on loss, the RMCAT packets are held hostage to being >>> delayed by the bottleneck queue delay maximum. >>> >>> Thus, whenever possible, it will be preferable for RMCAT flows to >>> compete with other congestion control transports that adapt on >>> delay. Even this may not get us to the desired low-delay goals when >>> a portion of the traffic has long RTTs (i.e., adaptation control >>> loops that are long in time), or for links that have a highly-time >>> varying capacity, but it will help for a lot of common bottleneck >>> topologies (e.g., slowly time-varying access bufferbloat). >>> >>> It is my hope that this topic has some discussion time in the Berlin >>> Transport WG (not the specific codepoint to be chosen, but rather >>> the need for one). >>> >>> Off Soapbox, >>> >>> Michael Ramalho, Ph.D. >>> >>> -----Original Message----- >>> From: Michael Ramalho (mramalho) >>> Sent: Tuesday, July 16, 2013 9:06 AM >>> To: rmcat@ietf.org >>> Subject: RE: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. >>> loss-only rate-adaptive for DiffServ >>> >>> RMCAT Design Team, >>> >>> The draft Lars references below is a formal request for a DSCP >>> dedicated to "RMCAT-only (or other nice delay-based cc) traffic". >>> >>> It will take a while to become socialized ... and we can progress >>> our RMCAT work in the interim. >>> >>> Michael Ramalho >>> >>> -----Original Message----- >>> From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On >>> Behalf Of Eggert, Lars >>> Sent: Tuesday, July 16, 2013 5:26 AM >>> To: WG WG >>> Cc: draft-polk-tsvwg-delay-vs-loss-ds-service-classes@tools.ietf.org >>> Subject: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. loss-only >>> rate-adaptive for DiffServ >>> >>> Possibly of interest to RMCAT. >>> >>> Begin forwarded message: >>> >>>> From: James Polk >>>> Subject: [tsvwg] Submitted ID on delay vs. loss-only >>> rate-adaptive for DiffServ >>>> Date: July 16, 2013 8:07:59 GMT+02:00 >>>> To: >>>> >>>> (as an author) >>>> >>>> Toerless and I put together a draft about legacy rate-adaptation >>> based only on loss vs. what RMCAT is looking to (for RTCWEB), which >>> is based on delay and loss. Here's the URL. >>>> >>> http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt >>>> It's more raw than we had in mind, but we believe this is >>> necessary, based on implementation experience and what users and >>> customers have in their networks, or are planning on having in >>> their networks soon. >>>> James & Toerless >>>> > > > From chelai@cisco.com Wed Jul 17 13:22:17 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8EDA21E804C; Wed, 17 Jul 2013 13:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lt0Wk3zCVXID; Wed, 17 Jul 2013 13:22:12 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 05A6F11E80DC; Wed, 17 Jul 2013 13:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5840; q=dns/txt; s=iport; t=1374092531; x=1375302131; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=T5hVZNQHtHnKtgeA/Ss3Eixj/R+qXwpe2OPuLzuA/+Y=; b=k6/1xeyibIllqTZt0xD5dnPJu8ajZacTZJwSgir7Y+ZNjySFWY6U4hyw Hfcak8c16WQqXzKvDPmJ7pxbwb53xtKXW4xf5BgS6NiLIYTFXh8vSyiLQ yluHUrT7iXKTgP9IqlaMGgUzrq5CvvL8+ny5QwnSdqe+yzUfp9cbJDWO/ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAIP75lGtJXHA/2dsb2JhbABagwY0UMBJgRIWdIIjAQEBBDpLBAIBCBEDAQEBAQoUCQcyFAgBCAIEARIIAYgHDLYSj0k4BoMHbgOpKYFZgTmCKA X-IronPort-AV: E=Sophos;i="4.89,687,1367971200"; d="scan'208";a="235926946" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 17 Jul 2013 20:22:09 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6HKM8Ug027764 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 20:22:08 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.51]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 15:22:08 -0500 From: "Cheng-Jia Lai (chelai)" To: "James Polk (jmpolk)" , "Toerless Eckert (eckert)" , "Michael Ramalho (mramalho)" , "tsvwg@ietf.org" , "rmcat@ietf.org" Thread-Topic: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ Thread-Index: AQHOgmkJVhIAra2Os0yVivAo05Amo5lpST9g Date: Wed, 17 Jul 2013 20:22:08 +0000 Message-ID: References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> In-Reply-To: <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.76.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 20:22:17 -0000 I think it would be good if Section 5.1 can include some specification or r= ecommendation how a video flow's packets should be classified into CS4 and = CS4-Discardable and how they will be dropped preferentially at congestion. = Although AF4x has already specified how to do this by different drop probab= ilities, it might not be suitable since I-frame, IDR, or other important pa= ckets (e.g. in-band signals or supplementary metadata) can still be dropped= by probability (smaller though) before all discardable P frames in the sam= e video flow are dropped. In addition, maybe it should cover some fairness requirements, i.e. how the= video rate adaptive behaviors can expect to see packet drops w.r.t. conten= tion, which IMHO should encourage video endpoints to generate more discarda= ble P-frame or other lower priority packets, even at congestion. If possibl= e, this should also try to avoid global synchronization, i.e. all video-enc= oders to generate I-frame/IDR at the same time (even after they reduce rate= , they still need to recover the lost video) when CS4 / CS4-Discardable que= ue is congested and drops packets from all of them. Regards, CJ -----Original Message----- From: James Polk (jmpolk)=20 Sent: Tuesday, July 16, 2013 2:11 PM To: Cheng-Jia Lai (chelai); James Polk (jmpolk); Toerless Eckert (eckert); = Michael Ramalho (mramalho); tsvwg@ietf.org; rmcat@ietf.org Subject: RE: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs. loss-only r= ate-adaptive for DiffServ CJ Thank you for the quick review. I'll ask you the same question I just asked Michael, the draft isn't=20 very long (under 8 pages currently), and it is a work in progress -=20 but do you have text or just points that this draft needs to cover=20 that it doesn't currently? James At 01:36 PM 7/16/2013, Cheng-Jia Lai (chelai) wrote: >Same here... I feel it makes sense to create a new DSCP / CS4 for=20 >transport of video flows that have rate adaptive behaviors and/or=20 >intra-flow preferential drop priorities as indicated in the I-D. The=20 >service provided by the network may thus be considered new, i.e.=20 >different from what exists in AF4x, so IMHO, using a new or reusing=20 >CS4 service class adds clarity for the user applications. > >Regards, >CJ > > >-----Original Message----- >From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On=20 >Behalf Of Michael Ramalho (mramalho) >Sent: Tuesday, July 16, 2013 6:36 AM >To: tsvwg@ietf.org >Subject: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs.=20 >loss-only rate-adaptive for DiffServ > >TSVWG Members, > >I should have copied you on my email to the RMCAT mailer below. > >I strongly support the creation of a new DSCP for transports in=20 >which their congestion control can adapt based on delay. > >The current ID in support of this=20 >(http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-ser= vice-classes-00.txt=20 >) is a work in progress, but a step in the right direction. > >It is a given that the ability of the eventual RMCAT adaptation=20 >mechanisms to achieve low delay will be function of the other=20 >dominant traffic it is competing against. If the dominant competing=20 >traffic DEPENDS on loss, the RMCAT packets are held hostage to being=20 >delayed by the bottleneck queue delay maximum. > >Thus, whenever possible, it will be preferable for RMCAT flows to=20 >compete with other congestion control transports that adapt on=20 >delay. Even this may not get us to the desired low-delay goals when=20 >a portion of the traffic has long RTTs (i.e., adaptation control=20 >loops that are long in time), or for links that have a highly-time=20 >varying capacity, but it will help for a lot of common bottleneck=20 >topologies (e.g., slowly time-varying access bufferbloat). > >It is my hope that this topic has some discussion time in the Berlin=20 >Transport WG (not the specific codepoint to be chosen, but rather=20 >the need for one). > >Off Soapbox, > >Michael Ramalho, Ph.D. > >-----Original Message----- >From: Michael Ramalho (mramalho) >Sent: Tuesday, July 16, 2013 9:06 AM >To: rmcat@ietf.org >Subject: RE: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs.=20 >loss-only rate-adaptive for DiffServ > >RMCAT Design Team, > >The draft Lars references below is a formal request for a DSCP=20 >dedicated to "RMCAT-only (or other nice delay-based cc) traffic". > >It will take a while to become socialized ... and we can progress=20 >our RMCAT work in the interim. > >Michael Ramalho > >-----Original Message----- >From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On=20 >Behalf Of Eggert, Lars >Sent: Tuesday, July 16, 2013 5:26 AM >To: WG WG >Cc: draft-polk-tsvwg-delay-vs-loss-ds-service-classes@tools.ietf.org >Subject: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. loss-only=20 >rate-adaptive for DiffServ > >Possibly of interest to RMCAT. > >Begin forwarded message: > > > From: James Polk > > Subject: [tsvwg] Submitted ID on delay vs. loss-only=20 > rate-adaptive for DiffServ > > Date: July 16, 2013 8:07:59 GMT+02:00 > > To: > > > > (as an author) > > > > Toerless and I put together a draft about legacy rate-adaptation=20 > based only on loss vs. what RMCAT is looking to (for RTCWEB), which=20 > is based on delay and loss. Here's the URL. > > > >=20 > http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-ser= vice-classes-00.txt > > > > It's more raw than we had in mind, but we believe this is=20 > necessary, based on implementation experience and what users and=20 > customers have in their networks, or are planning on having in=20 > their networks soon. > > > > James & Toerless > > From jmpolk@cisco.com Wed Jul 17 13:37:39 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3C121F91F4; Wed, 17 Jul 2013 13:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.23 X-Spam-Level: X-Spam-Status: No, score=-110.23 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vifEfdFCxPhT; Wed, 17 Jul 2013 13:37:35 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 209A821F8456; Wed, 17 Jul 2013 13:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6250; q=dns/txt; s=iport; t=1374093455; x=1375303055; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=E98sKYiCPiHTiKNpEY9gNOm+uljzGQrIhq7AD74REWg=; b=DMBVKxutNbsnIH2Rf/3h6W75jwcyzVvtl78hpEmWVe4pTuVR8aSXrYPh zgN/EAXzPsp2Lasr+Ekz1ljYTBDBPIcj5WzqK5AJt3FoiUxU+6RxZ496Q A86TufF/DrK0VE/gRt9+9jPbnGw18OI1QsrgnMNB4Du8ptWKARyAnVA5Q U=; X-IronPort-AV: E=Sophos;i="4.89,687,1367971200"; d="scan'208";a="236105210" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 17 Jul 2013 20:37:34 +0000 Received: from jmpolk-WS.cisco.com ([10.89.8.39]) (authenticated bits=0) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6HKbYCG031201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 20:37:34 GMT Message-Id: <201307172037.r6HKbYCG031201@rcdn-core2-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 17 Jul 2013 15:37:34 -0500 To: "Cheng-Jia Lai (chelai)" , "James Polk (jmpolk)" , "Toerless Eckert (eckert)" , "Michael Ramalho (mramalho)" , "tsvwg@ietf.org" , "rmcat@ietf.org" From: James Polk In-Reply-To: References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 20:37:39 -0000 CJ These are good suggestions for the next version. I thank you for offering them. I agree that s5.1 is underspecified, and will be expanded next version along the lines of your 1st paragraph below, as well. James At 03:22 PM 7/17/2013, Cheng-Jia Lai (chelai) wrote: >I think it would be good if Section 5.1 can include some >specification or recommendation how a video flow's packets should be >classified into CS4 and CS4-Discardable and how they will be dropped >preferentially at congestion. Although AF4x has already specified >how to do this by different drop probabilities, it might not be >suitable since I-frame, IDR, or other important packets (e.g. >in-band signals or supplementary metadata) can still be dropped by >probability (smaller though) before all discardable P frames in the >same video flow are dropped. > >In addition, maybe it should cover some fairness requirements, i.e. >how the video rate adaptive behaviors can expect to see packet drops >w.r.t. contention, which IMHO should encourage video endpoints to >generate more discardable P-frame or other lower priority packets, >even at congestion. If possible, this should also try to avoid >global synchronization, i.e. all video-encoders to generate >I-frame/IDR at the same time (even after they reduce rate, they >still need to recover the lost video) when CS4 / CS4-Discardable >queue is congested and drops packets from all of them. > >Regards, >CJ > > >-----Original Message----- >From: James Polk (jmpolk) >Sent: Tuesday, July 16, 2013 2:11 PM >To: Cheng-Jia Lai (chelai); James Polk (jmpolk); Toerless Eckert >(eckert); Michael Ramalho (mramalho); tsvwg@ietf.org; rmcat@ietf.org >Subject: RE: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs. >loss-only rate-adaptive for DiffServ > >CJ > >Thank you for the quick review. > >I'll ask you the same question I just asked Michael, the draft isn't >very long (under 8 pages currently), and it is a work in progress - >but do you have text or just points that this draft needs to cover >that it doesn't currently? > >James > >At 01:36 PM 7/16/2013, Cheng-Jia Lai (chelai) wrote: > >Same here... I feel it makes sense to create a new DSCP / CS4 for > >transport of video flows that have rate adaptive behaviors and/or > >intra-flow preferential drop priorities as indicated in the I-D. The > >service provided by the network may thus be considered new, i.e. > >different from what exists in AF4x, so IMHO, using a new or reusing > >CS4 service class adds clarity for the user applications. > > > >Regards, > >CJ > > > > > >-----Original Message----- > >From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On > >Behalf Of Michael Ramalho (mramalho) > >Sent: Tuesday, July 16, 2013 6:36 AM > >To: tsvwg@ietf.org > >Subject: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs. > >loss-only rate-adaptive for DiffServ > > > >TSVWG Members, > > > >I should have copied you on my email to the RMCAT mailer below. > > > >I strongly support the creation of a new DSCP for transports in > >which their congestion control can adapt based on delay. > > > >The current ID in support of this > >(http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss > -ds-service-classes-00.txt > >) is a work in progress, but a step in the right direction. > > > >It is a given that the ability of the eventual RMCAT adaptation > >mechanisms to achieve low delay will be function of the other > >dominant traffic it is competing against. If the dominant competing > >traffic DEPENDS on loss, the RMCAT packets are held hostage to being > >delayed by the bottleneck queue delay maximum. > > > >Thus, whenever possible, it will be preferable for RMCAT flows to > >compete with other congestion control transports that adapt on > >delay. Even this may not get us to the desired low-delay goals when > >a portion of the traffic has long RTTs (i.e., adaptation control > >loops that are long in time), or for links that have a highly-time > >varying capacity, but it will help for a lot of common bottleneck > >topologies (e.g., slowly time-varying access bufferbloat). > > > >It is my hope that this topic has some discussion time in the Berlin > >Transport WG (not the specific codepoint to be chosen, but rather > >the need for one). > > > >Off Soapbox, > > > >Michael Ramalho, Ph.D. > > > >-----Original Message----- > >From: Michael Ramalho (mramalho) > >Sent: Tuesday, July 16, 2013 9:06 AM > >To: rmcat@ietf.org > >Subject: RE: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. > >loss-only rate-adaptive for DiffServ > > > >RMCAT Design Team, > > > >The draft Lars references below is a formal request for a DSCP > >dedicated to "RMCAT-only (or other nice delay-based cc) traffic". > > > >It will take a while to become socialized ... and we can progress > >our RMCAT work in the interim. > > > >Michael Ramalho > > > >-----Original Message----- > >From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On > >Behalf Of Eggert, Lars > >Sent: Tuesday, July 16, 2013 5:26 AM > >To: WG WG > >Cc: draft-polk-tsvwg-delay-vs-loss-ds-service-classes@tools.ietf.org > >Subject: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. loss-only > >rate-adaptive for DiffServ > > > >Possibly of interest to RMCAT. > > > >Begin forwarded message: > > > > > From: James Polk > > > Subject: [tsvwg] Submitted ID on delay vs. loss-only > > rate-adaptive for DiffServ > > > Date: July 16, 2013 8:07:59 GMT+02:00 > > > To: > > > > > > (as an author) > > > > > > Toerless and I put together a draft about legacy rate-adaptation > > based only on loss vs. what RMCAT is looking to (for RTCWEB), which > > is based on delay and loss. Here's the URL. > > > > > > > > > http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt > > > > > > It's more raw than we had in mind, but we believe this is > > necessary, based on implementation experience and what users and > > customers have in their networks, or are planning on having in > > their networks soon. > > > > > > James & Toerless > > > From jmpolk@cisco.com Wed Jul 17 13:46:06 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96BB21F9EC4; Wed, 17 Jul 2013 13:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.213 X-Spam-Level: X-Spam-Status: No, score=-110.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8LH94+HqqSs; Wed, 17 Jul 2013 13:46:02 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1235321F9EA7; Wed, 17 Jul 2013 13:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7663; q=dns/txt; s=iport; t=1374093962; x=1375303562; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=Oqd6Z1DnziKxlsIJS3njLwDRMssOQGI5lPX0imGEl+k=; b=RmsdjlvM1hYzXILYGd/Dr4+ScVz1qzDDW8QZ7KhxL66ZpsDnSYenxEIX xW1FBYhkLSq1yxxW/a6F4h5MKt78S8KqDVpsxKKrWdmMetBFBFBXcheYW rI6Iz9eZmPqGfJf5+fnh0Ss2p7NFAqOaO8Co+EuImLMUl6K/aNL2Hc16V 0=; X-IronPort-AV: E=Sophos;i="4.89,687,1367971200"; d="scan'208";a="236218285" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 17 Jul 2013 20:46:01 +0000 Received: from jmpolk-WS.cisco.com ([10.89.8.39]) (authenticated bits=0) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6HKk02G028620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 20:46:01 GMT Message-Id: <201307172046.r6HKk02G028620@rcdn-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 17 Jul 2013 15:46:00 -0500 To: Brian E Carpenter , From: James Polk In-Reply-To: <51E6F6C2.8090202@gmail.com> References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> <51E6F6C2.8090202@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: "rmcat@ietf.org" , "Michael Ramalho \(mramalho\)" , "James Polk \(jmpolk\)" , "Mo Zanaty \(mzanaty\)" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 20:46:07 -0000 At 02:55 PM 7/17/2013, Brian E Carpenter wrote: >On 17/07/2013 18:50, gorry@erg.abdn.ac.uk wrote: > > I think the question of sharing diffserv is important, and my current > > suggestion is that RMCAT should use one or at most two DSCPs and design a > > CC that works well within the class - however this does not absolve RMCAT > > from also having to work in the Internet without this class. This will > > likely be the main use-case! > > > > Although the proposal could help these applications - the IETF can not > > somehow mandate this is universally deployed - and even if the DSCP(s) > > were universally recognised, it would still be aggregated within some > > networks and on L2 technologies that support fewer classes than DSCP > > markings. > > > > It would be interesting to know if others think we should be considering > > more DSCPs for this? > >If you mean "more" in the sense of defining new PHBs, I sincerely hope >not. Diffserv works best with a small set of highly differentiated >PHBs. Also, in order to get cross-domain agreements on DSCP assignments, >the fewer there are the better. Brian - while I agree less is more manageable, but less what? Isn't 'the less' or "... a small set..." you're referring to actually about treatment aggregates, defined by RFC 5127 (where similar PHBs are aggregated into 'treatment aggregates' to all be treated the same where we have big pipes)? Treatment Aggregates would see all of the above video traffic in the same individual treatment aggregate, solving the issue you bring up that _not_ any more treatment aggregates are defined. James > Brian > > > > > Gorry > > > >> I support something like what this draft proposes, to segregate RMCAT (and > >> potentially other delay-adaptive traffic) from other traffic which does > >> not adapt to delay trends (and therefore incurs maximum queue delay for > >> all traffic in its queue). Of course, this only helps when such queue > >> segregation is available in the network, but effective active queue > >> management is not available (otherwise there would be no delay signals for > >> delay-adaptive traffic to act on). > >> > >> An open question in my mind, that I think this draft needs to address, is > >> whether all delay-adaptive traffic should share the same queue/DSCP, or > >> whether we need different queues/DSCPs for different delay-adaptive > >> protocols/applications (for example, RMCAT vs. LEDBAT). > >> > >> Mo > >> > >> -----Original Message----- > >> From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of > >> James Polk (jmpolk) > >> Sent: Tuesday, July 16, 2013 5:11 PM > >> To: Cheng-Jia Lai (chelai); James Polk (jmpolk); Toerless Eckert (eckert); > >> Michael Ramalho (mramalho); tsvwg@ietf.org; rmcat@ietf.org > >> Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only > >> rate-adaptive for DiffServ > >> > >> CJ > >> > >> Thank you for the quick review. > >> > >> I'll ask you the same question I just asked Michael, the draft isn't > >> very long (under 8 pages currently), and it is a work in progress - > >> but do you have text or just points that this draft needs to cover > >> that it doesn't currently? > >> > >> James > >> > >> At 01:36 PM 7/16/2013, Cheng-Jia Lai (chelai) wrote: > >>> Same here... I feel it makes sense to create a new DSCP / CS4 for > >>> transport of video flows that have rate adaptive behaviors and/or > >>> intra-flow preferential drop priorities as indicated in the I-D. The > >>> service provided by the network may thus be considered new, i.e. > >>> different from what exists in AF4x, so IMHO, using a new or reusing > >>> CS4 service class adds clarity for the user applications. > >>> > >>> Regards, > >>> CJ > >>> > >>> > >>> -----Original Message----- > >>> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On > >>> Behalf Of Michael Ramalho (mramalho) > >>> Sent: Tuesday, July 16, 2013 6:36 AM > >>> To: tsvwg@ietf.org > >>> Subject: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs. > >>> loss-only rate-adaptive for DiffServ > >>> > >>> TSVWG Members, > >>> > >>> I should have copied you on my email to the RMCAT mailer below. > >>> > >>> I strongly support the creation of a new DSCP for transports in > >>> which their congestion control can adapt based on delay. > >>> > >>> The current ID in support of this > >>> > (http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt > >>> ) is a work in progress, but a step in the right direction. > >>> > >>> It is a given that the ability of the eventual RMCAT adaptation > >>> mechanisms to achieve low delay will be function of the other > >>> dominant traffic it is competing against. If the dominant competing > >>> traffic DEPENDS on loss, the RMCAT packets are held hostage to being > >>> delayed by the bottleneck queue delay maximum. > >>> > >>> Thus, whenever possible, it will be preferable for RMCAT flows to > >>> compete with other congestion control transports that adapt on > >>> delay. Even this may not get us to the desired low-delay goals when > >>> a portion of the traffic has long RTTs (i.e., adaptation control > >>> loops that are long in time), or for links that have a highly-time > >>> varying capacity, but it will help for a lot of common bottleneck > >>> topologies (e.g., slowly time-varying access bufferbloat). > >>> > >>> It is my hope that this topic has some discussion time in the Berlin > >>> Transport WG (not the specific codepoint to be chosen, but rather > >>> the need for one). > >>> > >>> Off Soapbox, > >>> > >>> Michael Ramalho, Ph.D. > >>> > >>> -----Original Message----- > >>> From: Michael Ramalho (mramalho) > >>> Sent: Tuesday, July 16, 2013 9:06 AM > >>> To: rmcat@ietf.org > >>> Subject: RE: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. > >>> loss-only rate-adaptive for DiffServ > >>> > >>> RMCAT Design Team, > >>> > >>> The draft Lars references below is a formal request for a DSCP > >>> dedicated to "RMCAT-only (or other nice delay-based cc) traffic". > >>> > >>> It will take a while to become socialized ... and we can progress > >>> our RMCAT work in the interim. > >>> > >>> Michael Ramalho > >>> > >>> -----Original Message----- > >>> From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On > >>> Behalf Of Eggert, Lars > >>> Sent: Tuesday, July 16, 2013 5:26 AM > >>> To: WG WG > >>> Cc: draft-polk-tsvwg-delay-vs-loss-ds-service-classes@tools.ietf.org > >>> Subject: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. loss-only > >>> rate-adaptive for DiffServ > >>> > >>> Possibly of interest to RMCAT. > >>> > >>> Begin forwarded message: > >>> > >>>> From: James Polk > >>>> Subject: [tsvwg] Submitted ID on delay vs. loss-only > >>> rate-adaptive for DiffServ > >>>> Date: July 16, 2013 8:07:59 GMT+02:00 > >>>> To: > >>>> > >>>> (as an author) > >>>> > >>>> Toerless and I put together a draft about legacy rate-adaptation > >>> based only on loss vs. what RMCAT is looking to (for RTCWEB), which > >>> is based on delay and loss. Here's the URL. > >>>> > >>> > http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt > >>>> It's more raw than we had in mind, but we believe this is > >>> necessary, based on implementation experience and what users and > >>> customers have in their networks, or are planning on having in > >>> their networks soon. > >>>> James & Toerless > >>>> > > > > > > From david.black@emc.com Wed Jul 17 14:37:48 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3330221F99A2 for ; Wed, 17 Jul 2013 14:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t40rlD9Xq4Qt for ; Wed, 17 Jul 2013 14:37:43 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id C9C4421F8DE3 for ; Wed, 17 Jul 2013 14:37:39 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6HLbbxZ014195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 17 Jul 2013 17:37:37 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Wed, 17 Jul 2013 17:37:23 -0400 Received: from mxhub33.corp.emc.com (mxhub33.corp.emc.com [10.254.93.81]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6HLbMP1024875 for ; Wed, 17 Jul 2013 17:37:22 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub33.corp.emc.com ([::1]) with mapi; Wed, 17 Jul 2013 17:37:22 -0400 From: "Black, David" To: tsvwg WG Date: Wed, 17 Jul 2013 17:37:21 -0400 Thread-Topic: Delay vs. Loss draft: Terminology Thread-Index: Ac6DNdGM+DVXkMjwQwGwpdmoK+2kUg== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712984AC721@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-EMM-MHVC: 1 Subject: [tsvwg] Delay vs. Loss draft: Terminology X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 21:37:48 -0000 This note concerns draft-polk-tsvwg-delay-vs-loss-ds-service-classes I believe I see some sloppy use of terminology in this draft and the related discussion. CS4 was originally defined as a DSCP value in RFC 2474 (Diffserv field in IP headers) and is used only as a DSCP value in RFC 4594 (Diffserv Service classes). That said, RFC 2474 can be read to allow use of CS4 as a PHB name - it's effectively shorthand for "the PHB assigned to the CS4 DSCP - as is done in draft-polk-tsvwg-rfc4594-update does. While that may not be the best usage, I think it's ok. OTOH, draft-polk-tsvwg-delay-vs-loss-ds-service-classes appears to be using strings such as "CS4", "CS4-Discardable" and "CS4+" as service class names (see Sections 5 and 6). That inclusion of the DSCP name in the service class name is (IMHO), a stunningly bad idea that is going to lead to confusion, and moreover is at odds with one of the basic principles of the Diffserv architecture, namely separation of traffic behavior (PHB and subsequently, service class) from the DSCP used in the IP header to request suitable treatment in a particular network. As an author of both RFC 2474 and 2475, I really would like to see draft-polk-tsvwg-delay-vs-loss-ds-service-classes revised to be clear on DSCP vs. PHB vs. service class and in particular to cease and desist from using CS4 (or any other DSCP name) as the name or part of the name of a service class - that will inevitably lead to the bad and wrong assumption that such a service class can only ever be deployed with the CS4 DSCP - while that sort of relationship is RECOMMENDED by RFC 4594, it is not REQUIRED (where "RECOMMENNDED" and "REQUIRED" have their RFC 2119 meanings). An example of the possible confusion that is that there will be networks in which the CS4 DSCP will be deployed with only one of the service classes currently called "CS4" and "CS4-Discardable" in draft-polk-tsvwg-delay-vs-loss-ds-service-classes. Is anyone prepared to try to explain with a straight face why the "CS4" service class isn't using the "CS4" DSCP? 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 david.black@emc.com Wed Jul 17 15:57:50 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2933321F85B2 for ; Wed, 17 Jul 2013 15:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4OjAR8rSXtq for ; Wed, 17 Jul 2013 15:57:31 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9EC21E805F for ; Wed, 17 Jul 2013 15:57:05 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6HMucSw021009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 18:56:38 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 17 Jul 2013 18:56:25 -0400 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6HMuMp5009195; Wed, 17 Jul 2013 18:56:22 -0400 Received: from mxhub40.corp.emc.com (128.222.70.107) by mxhub10.corp.emc.com (10.254.92.105) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 17 Jul 2013 18:56:22 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub40.corp.emc.com ([128.222.70.107]) with mapi; Wed, 17 Jul 2013 18:56:22 -0400 From: "Black, David" To: RFC Errata System , "kk@teraoptic.com" , "floyd@aciri.org" , "spencerdawkins.ietf@gmail.com" , "martin.stiemerling@neclab.eu" , "gorry@erg.abdn.ac.uk" , "jmpolk@cisco.com" Date: Wed, 17 Jul 2013 18:56:20 -0400 Thread-Topic: [Technical Errata Reported] RFC3168 (3680) Thread-Index: Ac5+8XE39Y6lF7DgSCS8OBhR/RvQOgET1fLQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712984AC743@MX15A.corp.emc.com> References: <20130712111516.3B8B66211A@rfc-editor.org> In-Reply-To: <20130712111516.3B8B66211A@rfc-editor.org> 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-EMM-MHVC: 1 Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] [Technical Errata Reported] RFC3168 (3680) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 22:57:51 -0000 I believe this errata is correct. Thanks, --David (as RFC 3168 author and tsvwg WG co-chair) > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: Friday, July 12, 2013 7:15 AM > To: kk@teraoptic.com; floyd@aciri.org; Black, David; > spencerdawkins.ietf@gmail.com; martin.stiemerling@neclab.eu; > gorry@erg.abdn.ac.uk; Black, David; jmpolk@cisco.com > Cc: mirja.kuehlewind@ikr.uni-stuttgart.de; tsvwg@ietf.org; rfc-editor@rfc= - > editor.org > Subject: [Technical Errata Reported] RFC3168 (3680) >=20 > The following errata report has been submitted for RFC3168, > "The Addition of Explicit Congestion Notification (ECN) to IP". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D3168&eid=3D3680 >=20 > -------------------------------------- > Type: Technical > Reported by: Mirja K=FChlewind >=20 > Section: 6.1.1. >=20 > Original Text > ------------- > If the TCP connection does not > wish to use ECN notification for a particular packet, the sending TCP > sets the ECN codepoint to not-ECT, and the TCP receiver ignores the > CE codepoint in the received packet. >=20 > Corrected Text > -------------- > If the TCP connection does not > wish to use ECN notification for a particular packet, the sending TCP > sets the ECN codepoint to not-ECT. >=20 > Notes > ----- > The receiver should not ignore any CE codepoint. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC3168 (draft-ietf-tsvwg-ecn-04) > -------------------------------------- > Title : The Addition of Explicit Congestion Notification (E= CN) > to IP > Publication Date : September 2001 > Author(s) : K. Ramakrishnan, S. Floyd, D. Black > Category : PROPOSED STANDARD > Source : Transport Area Working Group > Area : Transport > Stream : IETF > Verifying Party : IESG From brian.e.carpenter@gmail.com Wed Jul 17 16:17:21 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9414521E8087; Wed, 17 Jul 2013 16:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.193 X-Spam-Level: X-Spam-Status: No, score=-102.193 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYMyKOjdHCWp; Wed, 17 Jul 2013 16:17:20 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BFE1A21E8054; Wed, 17 Jul 2013 16:17:20 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr13so2442146pbb.34 for ; Wed, 17 Jul 2013 16:17:20 -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=TXBw5A4NDzOQMAW8JpWcKs5oY7B2VZ4fv5dCVmUU0OI=; b=aLGtuTmB/XJqFL55Kn/ySu2g5/YesLHeB/h6920OGzEEjnmOFWZcp/GYgOCIGAm8Pj KGhXRyMSfCeGBkiAVqs+rN3jmGeS3aHvksBEiVwz8mH3omFiG5eNgg9SXhFXQAoOr28G pjkNs5CRcLyLH0yveaNg7l01FGlRQA/zCiMUK78MIXvrKdvahZdvt8ryssZ9KyZUwZX1 xOIS+Ij5gO3LJ2+FUgcTAqYGpn6+67jRs2TQSxpHhjL84nU1K1Knxa6uby+65t6wU9H7 kPK5XElbbdnlzkBdgF0WGNLwCjvo5hayQtx/g0Z3ZqeBmFvCmpB7u0dxxDTG3fP0ISyx 5Wug== X-Received: by 10.66.5.195 with SMTP id u3mr10031929pau.79.1374103040494; Wed, 17 Jul 2013 16:17:20 -0700 (PDT) Received: from [192.168.178.23] (33.198.69.111.dynamic.snap.net.nz. [111.69.198.33]) by mx.google.com with ESMTPSA id yj2sm10003192pbb.40.2013.07.17.16.17.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Jul 2013 16:17:19 -0700 (PDT) Message-ID: <51E72604.8030203@gmail.com> Date: Thu, 18 Jul 2013 11:17:24 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: James Polk References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> <51E6F6C2.8090202@gmail.com> <201307172046.r6HKk02G028620@rcdn-core-1.cisco.com> In-Reply-To: <201307172046.r6HKk02G028620@rcdn-core-1.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, "rmcat@ietf.org" , "Michael Ramalho \(mramalho\)" , "Mo Zanaty \(mzanaty\)" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 23:17:21 -0000 On 18/07/2013 08:46, James Polk wrote: > At 02:55 PM 7/17/2013, Brian E Carpenter wrote: >> On 17/07/2013 18:50, gorry@erg.abdn.ac.uk wrote: >> > I think the question of sharing diffserv is important, and my current >> > suggestion is that RMCAT should use one or at most two DSCPs and >> design a >> > CC that works well within the class - however this does not absolve >> RMCAT >> > from also having to work in the Internet without this class. This will >> > likely be the main use-case! >> > >> > Although the proposal could help these applications - the IETF can not >> > somehow mandate this is universally deployed - and even if the DSCP(s) >> > were universally recognised, it would still be aggregated within some >> > networks and on L2 technologies that support fewer classes than DSCP >> > markings. >> > >> > It would be interesting to know if others think we should be >> considering >> > more DSCPs for this? >> >> If you mean "more" in the sense of defining new PHBs, I sincerely hope >> not. Diffserv works best with a small set of highly differentiated >> PHBs. Also, in order to get cross-domain agreements on DSCP assignments, >> the fewer there are the better. > > Brian - while I agree less is more manageable, but less what? Isn't 'the > less' or "... a small set..." you're referring to actually about > treatment aggregates, defined by RFC 5127 (where similar PHBs are > aggregated into 'treatment aggregates' to all be treated the same where > we have big pipes)? Treatment Aggregates would see all of the above > video traffic in the same individual treatment aggregate, solving the > issue you bring up that _not_ any more treatment aggregates are defined. Yes, I agree entirely. Brian > > James > > >> Brian >> >> > >> > Gorry >> > >> >> I support something like what this draft proposes, to segregate >> RMCAT (and >> >> potentially other delay-adaptive traffic) from other traffic which >> does >> >> not adapt to delay trends (and therefore incurs maximum queue delay >> for >> >> all traffic in its queue). Of course, this only helps when such queue >> >> segregation is available in the network, but effective active queue >> >> management is not available (otherwise there would be no delay >> signals for >> >> delay-adaptive traffic to act on). >> >> >> >> An open question in my mind, that I think this draft needs to >> address, is >> >> whether all delay-adaptive traffic should share the same >> queue/DSCP, or >> >> whether we need different queues/DSCPs for different delay-adaptive >> >> protocols/applications (for example, RMCAT vs. LEDBAT). >> >> >> >> Mo >> >> >> >> -----Original Message----- >> >> From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On >> Behalf Of >> >> James Polk (jmpolk) >> >> Sent: Tuesday, July 16, 2013 5:11 PM >> >> To: Cheng-Jia Lai (chelai); James Polk (jmpolk); Toerless Eckert >> (eckert); >> >> Michael Ramalho (mramalho); tsvwg@ietf.org; rmcat@ietf.org >> >> Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. >> loss-only >> >> rate-adaptive for DiffServ >> >> >> >> CJ >> >> >> >> Thank you for the quick review. >> >> >> >> I'll ask you the same question I just asked Michael, the draft isn't >> >> very long (under 8 pages currently), and it is a work in progress - >> >> but do you have text or just points that this draft needs to cover >> >> that it doesn't currently? >> >> >> >> James >> >> >> >> At 01:36 PM 7/16/2013, Cheng-Jia Lai (chelai) wrote: >> >>> Same here... I feel it makes sense to create a new DSCP / CS4 for >> >>> transport of video flows that have rate adaptive behaviors and/or >> >>> intra-flow preferential drop priorities as indicated in the I-D. The >> >>> service provided by the network may thus be considered new, i.e. >> >>> different from what exists in AF4x, so IMHO, using a new or reusing >> >>> CS4 service class adds clarity for the user applications. >> >>> >> >>> Regards, >> >>> CJ >> >>> >> >>> >> >>> -----Original Message----- >> >>> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On >> >>> Behalf Of Michael Ramalho (mramalho) >> >>> Sent: Tuesday, July 16, 2013 6:36 AM >> >>> To: tsvwg@ietf.org >> >>> Subject: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs. >> >>> loss-only rate-adaptive for DiffServ >> >>> >> >>> TSVWG Members, >> >>> >> >>> I should have copied you on my email to the RMCAT mailer below. >> >>> >> >>> I strongly support the creation of a new DSCP for transports in >> >>> which their congestion control can adapt based on delay. >> >>> >> >>> The current ID in support of this >> >>> >> (http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt >> >> >>> ) is a work in progress, but a step in the right direction. >> >>> >> >>> It is a given that the ability of the eventual RMCAT adaptation >> >>> mechanisms to achieve low delay will be function of the other >> >>> dominant traffic it is competing against. If the dominant competing >> >>> traffic DEPENDS on loss, the RMCAT packets are held hostage to being >> >>> delayed by the bottleneck queue delay maximum. >> >>> >> >>> Thus, whenever possible, it will be preferable for RMCAT flows to >> >>> compete with other congestion control transports that adapt on >> >>> delay. Even this may not get us to the desired low-delay goals when >> >>> a portion of the traffic has long RTTs (i.e., adaptation control >> >>> loops that are long in time), or for links that have a highly-time >> >>> varying capacity, but it will help for a lot of common bottleneck >> >>> topologies (e.g., slowly time-varying access bufferbloat). >> >>> >> >>> It is my hope that this topic has some discussion time in the Berlin >> >>> Transport WG (not the specific codepoint to be chosen, but rather >> >>> the need for one). >> >>> >> >>> Off Soapbox, >> >>> >> >>> Michael Ramalho, Ph.D. >> >>> >> >>> -----Original Message----- >> >>> From: Michael Ramalho (mramalho) >> >>> Sent: Tuesday, July 16, 2013 9:06 AM >> >>> To: rmcat@ietf.org >> >>> Subject: RE: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. >> >>> loss-only rate-adaptive for DiffServ >> >>> >> >>> RMCAT Design Team, >> >>> >> >>> The draft Lars references below is a formal request for a DSCP >> >>> dedicated to "RMCAT-only (or other nice delay-based cc) traffic". >> >>> >> >>> It will take a while to become socialized ... and we can progress >> >>> our RMCAT work in the interim. >> >>> >> >>> Michael Ramalho >> >>> >> >>> -----Original Message----- >> >>> From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On >> >>> Behalf Of Eggert, Lars >> >>> Sent: Tuesday, July 16, 2013 5:26 AM >> >>> To: WG WG >> >>> Cc: draft-polk-tsvwg-delay-vs-loss-ds-service-classes@tools.ietf.org >> >>> Subject: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. loss-only >> >>> rate-adaptive for DiffServ >> >>> >> >>> Possibly of interest to RMCAT. >> >>> >> >>> Begin forwarded message: >> >>> >> >>>> From: James Polk >> >>>> Subject: [tsvwg] Submitted ID on delay vs. loss-only >> >>> rate-adaptive for DiffServ >> >>>> Date: July 16, 2013 8:07:59 GMT+02:00 >> >>>> To: >> >>>> >> >>>> (as an author) >> >>>> >> >>>> Toerless and I put together a draft about legacy rate-adaptation >> >>> based only on loss vs. what RMCAT is looking to (for RTCWEB), which >> >>> is based on delay and loss. Here's the URL. >> >>>> >> >>> >> http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt >> >> >>>> It's more raw than we had in mind, but we believe this is >> >>> necessary, based on implementation experience and what users and >> >>> customers have in their networks, or are planning on having in >> >>> their networks soon. >> >>>> James & Toerless >> >>>> >> > >> > >> > > > From brian.e.carpenter@gmail.com Wed Jul 17 16:35:47 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1814A21F9F3A for ; Wed, 17 Jul 2013 16:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZ-XwY2RGP3z for ; Wed, 17 Jul 2013 16:35:46 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8415521F9ED4 for ; Wed, 17 Jul 2013 16:35:46 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id bi5so2494720pad.18 for ; Wed, 17 Jul 2013 16:35:46 -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=UMvhUaglqIuA166l8DNj0ovHA7bYr4n9JvTBOCzkSjI=; b=tM7KcrfsUreCv0rI+d1w6TIYEUSyHgRbzyVHiFVKFUBr9xoq6iAZyNQ8oAETv5oM+n wufKAENFszGs134IEblfHf6EXxDUHo4l4UlMd81oBWBfRp4l8qHJPDbXa0IGi8B1B4dH sVcXUkUDBjqHUAqJOcZNrWGa8j98CkFmYQ5JZGGCwj7fcw46EXLEuMh5M7TPrKZuUYYY GI1EkHJFE+cBdG8oa71rLwngSIg86u+edt09QXZfefnxoPBo5yvHUXPSRlqui5HmViFW RwA9Vm0saATMgb4LODGooB8sPFtlrNcPSY9CNm9VKNokU1MX29tTogzM/VdkCsRsjgLJ u5ng== X-Received: by 10.66.218.39 with SMTP id pd7mr10259438pac.148.1374104146199; Wed, 17 Jul 2013 16:35:46 -0700 (PDT) Received: from [192.168.178.23] (33.198.69.111.dynamic.snap.net.nz. [111.69.198.33]) by mx.google.com with ESMTPSA id uj1sm12846330pac.21.2013.07.17.16.35.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Jul 2013 16:35:45 -0700 (PDT) Message-ID: <51E72A57.7090304@gmail.com> Date: Thu, 18 Jul 2013 11:35:51 +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: <8D3D17ACE214DC429325B2B98F3AE712984AC721@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712984AC721@MX15A.corp.emc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tsvwg WG Subject: Re: [tsvwg] Delay vs. Loss draft: Terminology X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 23:35:47 -0000 On 18/07/2013 09:37, Black, David wrote: > > > This note concerns draft-polk-tsvwg-delay-vs-loss-ds-service-classes > > I believe I see some sloppy use of terminology in this draft and the > related discussion. > > CS4 was originally defined as a DSCP value in RFC 2474 (Diffserv field > in IP headers) and is used only as a DSCP value in RFC 4594 (Diffserv > Service classes). > > That said, RFC 2474 can be read to allow use of CS4 as a PHB name - it's > effectively shorthand for "the PHB assigned to the CS4 DSCP - as is done > in draft-polk-tsvwg-rfc4594-update does. While that may not be the best > usage, I think it's ok. > > OTOH, draft-polk-tsvwg-delay-vs-loss-ds-service-classes appears to be > using strings such as "CS4", "CS4-Discardable" and "CS4+" as service > class names (see Sections 5 and 6). That inclusion of the DSCP name > in the service class name is (IMHO), a stunningly bad idea that is > going to lead to confusion, and moreover is at odds with one of the basic > principles of the Diffserv architecture, namely separation of traffic > behavior (PHB and subsequently, service class) from the DSCP used in > the IP header to request suitable treatment in a particular network. Hear, hear! It's especially true because CSn was included explicitly for backwards-compatibility with RFC 791, so attempting to name new behaviours as derivatives of CSn is particularly misleading. If you're looking for a PHB that's like CS4 but "more discardable" that would be CS3, anyway. The CSn, including CS0, are unique in that the assigned code points are not *recommended* mappings - section 4.2.2.1 of RFC 2474 reserves them unconditionally. No wiggle room here; there's a 1:1 correspondence between DSCP CSn and PHB CSn. But that applies nowhere else in diffserv. Brian > As an author of both RFC 2474 and 2475, I really would like to > see draft-polk-tsvwg-delay-vs-loss-ds-service-classes revised to be > clear on DSCP vs. PHB vs. service class and in particular to cease > and desist from using CS4 (or any other DSCP name) as the name or part > of the name of a service class - that will inevitably lead to the bad > and wrong assumption that such a service class can only ever be > deployed with the CS4 DSCP - while that sort of relationship is > RECOMMENDED by RFC 4594, it is not REQUIRED (where "RECOMMENNDED" > and "REQUIRED" have their RFC 2119 meanings). > > An example of the possible confusion that is that there will be > networks in which the CS4 DSCP will be deployed with only one > of the service classes currently called "CS4" and "CS4-Discardable" in > draft-polk-tsvwg-delay-vs-loss-ds-service-classes. Is anyone prepared > to try to explain with a straight face why the "CS4" service class > isn't using the "CS4" DSCP? > > 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 paulej@packetizer.com Wed Jul 17 23:26:04 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1E011E80AE for ; Wed, 17 Jul 2013 23:26:04 -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=[AWL=-0.252, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f367cT+R2R1W for ; Wed, 17 Jul 2013 23:25:59 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1E921F9FC8 for ; Wed, 17 Jul 2013 23:25:59 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r6I6Pv4l005185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Jul 2013 02:25:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1374128758; bh=+k52LcS4Xv5iN18i/wb3b+wziEFkxtnrAgMNN+rfYLA=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=nrgI/xgk05rQIajvEw9/806DwMcHkWXFL4xiNCpCAHjWapz17cUD962uozH/YvWnE 3NN3VwQ5MOWhvL/hoOO3KUTDG2mZxm8MONMvMQcP/LWvRLqA51YIlIcm0Wk8joD8c8 EzYrfUOFbJNhjNSnmu9HXhu5yj/1+oH5TWBYrQus= From: "Paul E. Jones" To: "'Charles Eckel \(eckelcu\)'" , "'James Polk \(jmpolk\)'" , References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <92B7E61ADAC1BB4F941F943788C08828048B5077@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828048B5077@xmb-aln-x08.cisco.com> Date: Thu, 18 Jul 2013 02:26:10 -0400 Message-ID: <080901ce837f$b1edccc0$15c96640$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKODdg0YCsHrqzz/K46YbzKWcJ3ZgISA31fl9pStAA= Content-Language: en-us Subject: Re: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 06:26:04 -0000 Charles, The current use of AF4x is fairly inelastic. Few video endpoints implement algorithms to dynamically adjust the bit-rate in the face of potential loss. Part of the reason is that to do that properly, one needs the work the rmcat WG is doing. So, I agree with the argument that we need something that is different than AF4x for what AF4x was originally intended. It simply a practical problem trying to change existing equipment to do something different. At any rate, it needs a good debate. Paul > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > Charles Eckel (eckelcu) > Sent: Tuesday, July 16, 2013 4:47 PM > To: James Polk (jmpolk); tsvwg@ietf.org > Subject: Re: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for > DiffServ > > I read the draft and thank you for addressing this need. It does a good > job of making the case for the need to differentiate the DSCP assignments > of delay-and-loss-based vs. just-loss-based rate-adaptive video > applications. While I do not agree with some of the finer points in the > draft, including the statement in section 3 that AF4x traffic in general > is inelastic/fixed bitrate, I completely agree that this traffic is > largely loss sensitive and yet often relies on loss based adaption. > The assignment of a new service class and the proposal for CS4 and CS4- > Discardable for rate-adaptive video makes sense to me. At the same time, > it is important to re-designate AF4x as you describe in order to match the > reality of today's deployments and avoid future confusion. > I look forward to seeing this work progress as it offer an incentive for > applications to embrace congestion control algorithms such as those being > developed in RMCAT without fearing they will be overrun by non-delay > adaptive traffic. > > Cheers, > Charles > > > > -----Original Message----- > > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf > Of > > James Polk (jmpolk) > > Sent: Monday, July 15, 2013 11:08 PM > > To: tsvwg@ietf.org > > Subject: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for > DiffServ > > > > (as an author) > > > > Toerless and I put together a draft about legacy rate-adaptation > > based only on loss vs. what RMCAT is looking to (for RTCWEB), which > > is based on delay and loss. Here's the URL. > > > > http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds- > service- > > classes-00.txt > > > > It's more raw than we had in mind, but we believe this is necessary, > > based on implementation experience and what users and customers have > > in their networks, or are planning on having in their networks soon. > > > > James & Toerless From paulej@packetizer.com Wed Jul 17 23:29:17 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C59B21F9FDE for ; Wed, 17 Jul 2013 23:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGglBJk53LEF for ; Wed, 17 Jul 2013 23:29:12 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4444321F9E26 for ; Wed, 17 Jul 2013 23:29:12 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r6I6TAqS005444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Jul 2013 02:29:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1374128951; bh=XB2z/0jp9sk5NCiTCumc0DbKFCFN7/dyByAZ+h2sZDE=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=UELDTt+gzB8qDkOOOUIHiGMY3hJoU06wcz4K00imLEJsSsbbork5Cxlz52fOAyUR2 YHjiNgh/gJnipyL1mbXK0UqfcHxX9Ll18k3DMnbU6Qypv1GTwqS7kY6yUPRqBbC7/a 1rKlQ1N0WFnmJn8U0cDcZlVeAPbfR0Hw7fx56kUs= From: "Paul E. Jones" To: "'Charles Eckel \(eckelcu\)'" , "'James Polk \(jmpolk\)'" , References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <92B7E61ADAC1BB4F941F943788C08828048B5077@xmb-aln-x08.cisco.com> <201307162106.r6GL6khf029009@rcdn-core-2.cisco.com> <92B7E61ADAC1BB4F941F943788C08828048B52EC@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828048B52EC@xmb-aln-x08.cisco.com> Date: Thu, 18 Jul 2013 02:29:23 -0400 Message-ID: <080b01ce8380$24fdabe0$6ef903a0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKODdg0YCsHrqzz/K46YbzKWcJ3ZgISA31fAhw9qd0B5iA2f5e6QOVQ Content-Language: en-us Subject: Re: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 06:29:17 -0000 Charles, > I think video codec implementations in the AF4X class today often have > variable bit rates; however, those variations are primarily due to the > amount of motion and sometimes as an adaptation to loss. Right, that's the issue. Trying to shove rmcat traffic into the same bucket will be problematic, I think. > The latter is > what is important in this discussion. Video codecs will continue to have > variable bit rates in accordance with the amount of motion, but if aligned > with the output of RMCAT, they will adapt based on delay as well as loss. That's the discussion that needs to be had. Paul From lars@netapp.com Wed Jul 17 23:41:36 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8A321E8090; Wed, 17 Jul 2013 23:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.929 X-Spam-Level: X-Spam-Status: No, score=-4.929 tagged_above=-999 required=5 tests=[AWL=-2.330, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvcxaMWFzEZA; Wed, 17 Jul 2013 23:41:31 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 43BF221E8093; Wed, 17 Jul 2013 23:41:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,691,1367996400"; d="scan'208";a="34640510" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 17 Jul 2013 23:41:30 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.35]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Wed, 17 Jul 2013 23:41:29 -0700 From: "Eggert, Lars" To: Wesley Eddy Thread-Topic: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ Thread-Index: AQHOgmmIKV+UZzP5tkaXbtTw1tg5vZloqnOAgAD8YYCAAM1ggA== Date: Thu, 18 Jul 2013 06:41:28 +0000 Message-ID: <460B8D74-2700-4875-B970-16D5936F3F58@netapp.com> References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> <51E6E1D5.1050006@mti-systems.com> In-Reply-To: <51E6E1D5.1050006@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9C6A17DD8070494B915135F8D8D7162F@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tsvwg@ietf.org" , "Mo Zanaty \(mzanaty\)" , "rmcat@ietf.org" , "Michael Ramalho \(mramalho\)" , "James Polk \(jmpolk\)" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 06:41:36 -0000 On Jul 17, 2013, at 20:26, Wesley Eddy wrote: > It is not wise, in my opinion, to have algorithm-specific DSCPs. > The DSCPs need to indicate the desired forwarding behavior, and > not what version of code the end-host runs. +1 Lars From michawe@ifi.uio.no Thu Jul 18 04:59:07 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81DD711E8138; Thu, 18 Jul 2013 04:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZGN4FXyID0w; Thu, 18 Jul 2013 04:59:01 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7FF11E8132; Thu, 18 Jul 2013 04:59:01 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1UzmrG-0004CA-58; Thu, 18 Jul 2013 13:58:54 +0200 Received: from 089144206079.atnat0015.highway.bob.at ([89.144.206.79] helo=[192.168.1.6]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UzmrE-0000vU-Gs; Thu, 18 Jul 2013 13:58:54 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Welzl In-Reply-To: <460B8D74-2700-4875-B970-16D5936F3F58@netapp.com> Date: Thu, 18 Jul 2013 13:58:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2CB66184-A7BF-45CD-9C9F-7B252EAD4088@ifi.uio.no> References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> <51E6E1D5.1050006@mti-systems.com> <460B8D74-2700-4875-B970-16D5936F3F58@netapp.com> To: "Eggert, Lars" X-Mailer: Apple Mail (2.1508) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 18 msgs/h 3 sum rcpts/h 19 sum msgs/h 4 total rcpts 5844 max rcpts/h 40 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: 158D348A1B63C011A12409D7465E1F17262ABA83 X-UiO-SPAM-Test: remote_host: 89.144.206.79 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 57 max/h 10 blacklist 0 greylist 0 ratelimit 0 Cc: "tsvwg@ietf.org" , "Mo Zanaty \(mzanaty\)" , "rmcat@ietf.org" , "Michael Ramalho \(mramalho\)" , "James Polk \(jmpolk\)" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 11:59:07 -0000 Hi everyone, I'm still working off my email backlog, and in doing so I got a bit = confused about the various drafts and views in this space. Since the = issue of interactions with congestion control was also mentioned, I'll = try to give a general comment here: First, about the stuff quoted below, it surprises me that we're even = debating algorithm-specific DSCPs - it should be rather obvious that we = don't want that?! I thought that the discussion is: a) 1 DSCP for rtcweb vs. b) multiple DSCPs for rtcweb (in which case I was thinking of e.g. video = / audio / data rather than algorithms) I have seen various emails that indicate agreement that we should have = at least one DSCP for rtcweb in general. The reason that was given is = that rmcat's congestion control will prefer to not be exposed to = TCP-like non-delay-based traffic (even though it should be able to work = reasonably well in the presence of such traffic too). As many others, I = totally agree. So let's move on to the next question, which is: should we have multiple = DSCPs (for multiple traffic classes) or not. Well, there are several = pro's and con's here - surely more than I list below, but these are the = ones I'd like to lay out because of the coupled-cc stuff we're = contributing to rmcat: Con's of multiple DSCPs: - 1 DSCP is simpler. - Whatever the DSCPs achieve, for traffic from a single source going = across the same shared bottleneck, coupled congestion control can = probably do a better job (*) < =3D=3D=3D but see this footnote! Pro's of multiple DSCPs: - coupled congestion control only applies to traffic from one host. In = other words, protecting your latency-critical audio from your own data = transfer doesn't help you against the rtcweb data transfer that a family = member generates in your home, as (s)he sends his file across the same = shared bottleneck. (*) Footnote: coupled congestion control should really only be applied = when we can be pretty sure that the traffic under control traverses the = same shared bottleneck. One simple way to achieve that for rtcweb is to = say that all traffic going from the same source to the same destination = shares the same bottleneck, but this only applies if "source" and = "destination" includes the port number, i.e. if traffic is multiplexed = over the same 5-tuple ***AND IF IT SHARES THE SAME DSCP*** (so here we = have the DSCP constraint). Due to the amount of traffic on their list I = find it hard to track rtcweb, but it seems to me that it's not = guaranteed that all rtcweb traffic will indeed be multiplexed in this = fashion. Moreover, such shared bottleneck detection is rather limiting - = it's also quite possible that traffic from the same source to multiple = destinations traverses the same shared bottleneck (typically the = source's access link), but this method would then only apply coupled = congestion control across flows towards the same destination. =46rom the above, it seems clear that we're better off using = measurement-based shared bottleneck detection anyway, and we're working = on that. Note that any measurement-based mechanism will have to look at = correlations to determine if traffic shares the same queue, and = therefore such a method should discover that flows which carry different = DSCPs do *not* share the same bottleneck. Thus, it would automatically = do the right thing. To summarize, it seems that using multiple DSCPs for rtcweb can help, = but creates a conflict with something that we shouldn't really rely on = for coupled congestion control. Therefore, it probably isn't really a = big problem from a congestion control point of view. I think that = simplicity is perhaps a more important argument for only one DSCP. My 2 cents. Cheers, Michael On Jul 18, 2013, at 8:41 AM, "Eggert, Lars" wrote: > On Jul 17, 2013, at 20:26, Wesley Eddy wrote: >> It is not wise, in my opinion, to have algorithm-specific DSCPs. >> The DSCPs need to indicate the desired forwarding behavior, and >> not what version of code the end-host runs. >=20 > +1 >=20 > Lars From david.black@emc.com Thu Jul 18 07:07:31 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4D611E80BA; Thu, 18 Jul 2013 07:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0huCAhbUUq0x; Thu, 18 Jul 2013 07:07:27 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 433CF11E8146; Thu, 18 Jul 2013 07:07:23 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6IE78xf009482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jul 2013 10:07:09 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 18 Jul 2013 10:06:44 -0400 Received: from mxhub25.corp.emc.com (mxhub25.corp.emc.com [10.254.110.181]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6IE5epW022766; Thu, 18 Jul 2013 10:06:43 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub25.corp.emc.com ([10.254.110.181]) with mapi; Thu, 18 Jul 2013 10:06:41 -0400 From: "Black, David" To: Michael Welzl , "Eggert, Lars" Date: Thu, 18 Jul 2013 10:03:20 -0400 Thread-Topic: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ Thread-Index: Ac6Drk8pgEa8BnSUTmWMcuV/DsnEPAADk8qQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712984AC816@MX15A.corp.emc.com> References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> <51E6E1D5.1050006@mti-systems.com> <460B8D74-2700-4875-B970-16D5936F3F58@netapp.com> <2CB66184-A7BF-45CD-9C9F-7B252EAD4088@ifi.uio.no> In-Reply-To: <2CB66184-A7BF-45CD-9C9F-7B252EAD4088@ifi.uio.no> 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-EMM-MHVC: 1 Cc: "rmcat@ietf.org" , "Michael Ramalho \(mramalho\)" , "James Polk \(jmpolk\)" , "tsvwg@ietf.org" , "Mo Zanaty \(mzanaty\)" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 14:07:31 -0000 I have a couple of requests to help focus the discussion: (1) Please focus on service classes and PHBs. An important reason is that the proposal in the draft that started this discussion is to repurpose an existing DSCP, namely CS4. Asking for a "new DSCP" is premature, and this is yet more rationale for why "CS4" should never have been used as a service class name in that draft. (2) Can we generalize beyond rtcweb/rmcat to look at the traffic behavior involved? This is not the first time that adaptive transport techniques that strive for low queue occupancy have arisen - Data Center TCP is another example, which is based on enhanced ECN signaling: http://simula.stanford.edu/~alizade/Site/DCTCP.html I assume that people like Michael and Lars are already very familiar with DCTCP, so that link's included for everyone else :-). If we can figure out what's going on here beyond "rtcweb/rmcat needs its own queue", the draft I would really like to see for Vancouver is the PHB specification for this. That might be a variant of EF that allows or requires adaptive response by endpoints, or it might be something completely new. While I recall at least talk about writing a PHB spec for less-than-best-effort adaptive traffic (e.g., ledbat), I don't recall that as having gone anywhere. Thanks, --David > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > Michael Welzl > Sent: Thursday, July 18, 2013 7:59 AM > To: Eggert, Lars > Cc: tsvwg@ietf.org; Mo Zanaty (mzanaty); rmcat@ietf.org; Michael Ramalho > (mramalho); James Polk (jmpolk) > Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only > rate-adaptive for DiffServ >=20 > Hi everyone, >=20 > I'm still working off my email backlog, and in doing so I got a bit confu= sed > about the various drafts and views in this space. Since the issue of > interactions with congestion control was also mentioned, I'll try to give= a > general comment here: >=20 > First, about the stuff quoted below, it surprises me that we're even deba= ting > algorithm-specific DSCPs - it should be rather obvious that we don't want > that?! I thought that the discussion is: > a) 1 DSCP for rtcweb > vs. > b) multiple DSCPs for rtcweb (in which case I was thinking of e.g. video = / > audio / data rather than algorithms) >=20 > I have seen various emails that indicate agreement that we should have at > least one DSCP for rtcweb in general. The reason that was given is that > rmcat's congestion control will prefer to not be exposed to TCP-like non- > delay-based traffic (even though it should be able to work reasonably wel= l in > the presence of such traffic too). As many others, I totally agree. >=20 > So let's move on to the next question, which is: should we have multiple = DSCPs > (for multiple traffic classes) or not. Well, there are several pro's and = con's > here - surely more than I list below, but these are the ones I'd like to = lay > out because of the coupled-cc stuff we're contributing to rmcat: >=20 > Con's of multiple DSCPs: > - 1 DSCP is simpler. > - Whatever the DSCPs achieve, for traffic from a single source going acro= ss > the same shared bottleneck, coupled congestion control can probably do a > better job (*) < =3D=3D=3D but see this footnote! >=20 > Pro's of multiple DSCPs: > - coupled congestion control only applies to traffic from one host. In ot= her > words, protecting your latency-critical audio from your own data transfer > doesn't help you against the rtcweb data transfer that a family member > generates in your home, as (s)he sends his file across the same shared > bottleneck. >=20 >=20 > (*) Footnote: coupled congestion control should really only be applied wh= en we > can be pretty sure that the traffic under control traverses the same shar= ed > bottleneck. One simple way to achieve that for rtcweb is to say that all > traffic going from the same source to the same destination shares the sam= e > bottleneck, but this only applies if "source" and "destination" includes = the > port number, i.e. if traffic is multiplexed over the same 5-tuple ***AND = IF IT > SHARES THE SAME DSCP*** (so here we have the DSCP constraint). Due to the > amount of traffic on their list I find it hard to track rtcweb, but it se= ems > to me that it's not guaranteed that all rtcweb traffic will indeed be > multiplexed in this fashion. Moreover, such shared bottleneck detection i= s > rather limiting - it's also quite possible that traffic from the same sou= rce > to multiple destinations traverses the same shared bottleneck (typically = the > source's access link), but this method would then only apply coupled > congestion control across flows towards the same destination. >=20 > From the above, it seems clear that we're better off using measurement-ba= sed > shared bottleneck detection anyway, and we're working on that. Note that = any > measurement-based mechanism will have to look at correlations to determin= e if > traffic shares the same queue, and therefore such a method should discove= r > that flows which carry different DSCPs do *not* share the same bottleneck= . > Thus, it would automatically do the right thing. >=20 > To summarize, it seems that using multiple DSCPs for rtcweb can help, but > creates a conflict with something that we shouldn't really rely on for co= upled > congestion control. Therefore, it probably isn't really a big problem fro= m a > congestion control point of view. I think that simplicity is perhaps a mo= re > important argument for only one DSCP. >=20 > My 2 cents. >=20 > Cheers, > Michael >=20 >=20 > On Jul 18, 2013, at 8:41 AM, "Eggert, Lars" wrote: >=20 > > On Jul 17, 2013, at 20:26, Wesley Eddy wrote: > >> It is not wise, in my opinion, to have algorithm-specific DSCPs. > >> The DSCPs need to indicate the desired forwarding behavior, and > >> not what version of code the end-host runs. > > > > +1 > > > > Lars >=20 From mramalho@cisco.com Thu Jul 18 07:52:23 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D90C21E8102; Thu, 18 Jul 2013 07:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OveTuY-GlJky; Thu, 18 Jul 2013 07:52:10 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE1211E814E; Thu, 18 Jul 2013 07:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7187; q=dns/txt; s=iport; t=1374159124; x=1375368724; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mH08scvS3HYHdkxaDIBo32sJuNs9NuS09K0DTh9BOuo=; b=lGJZI6obx41vw+AHcgCSbRQqG3mwmmIywmzr/J/bx/hXKfDPg1nA4p/k diz+uPhIuvj5BhRAtgtJ5wbl4wwpXGm+QUWnfrXSrtwLVYA+FdU0vTxlp kF9bRGQMO02mN7v3c0yGGo8/7Sp9jtz1CYl3gU/HzFoyqfp62/sG+W+ej M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAGT/51GtJXG8/2dsb2JhbABagwaBBcBDgQ4WdIIkAQEBAQIBOj8FBwQCAQgOAwQBAQEKFAkHMhQIAQgCBAoEBQgTh28Gth+OTYERMQcGgwhuA5QGlSSBWYE5gXE5 X-IronPort-AV: E=Sophos;i="4.89,694,1367971200"; d="scan'208";a="236474156" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 18 Jul 2013 14:52:04 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6IEq3rJ023690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 14:52:03 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.54]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Thu, 18 Jul 2013 09:52:03 -0500 From: "Michael Ramalho (mramalho)" To: Michael Welzl , "Eggert, Lars" Thread-Topic: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ Thread-Index: AQHOgpz4+m0uun89XEWA3y5OIxdfmJlphOaAgADNWgCAAFigAP//z5dg Date: Thu, 18 Jul 2013 14:52:02 +0000 Message-ID: References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> <51E6E1D5.1050006@mti-systems.com> <460B8D74-2700-4875-B970-16D5936F3F58@netapp.com> <2CB66184-A7BF-45CD-9C9F-7B252EAD4088@ifi.uio.no> In-Reply-To: <2CB66184-A7BF-45CD-9C9F-7B252EAD4088@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.125.234] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tsvwg@ietf.org" , "Mo Zanaty \(mzanaty\)" , "rmcat@ietf.org" , "James Polk \(jmpolk\)" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 14:52:23 -0000 Michael (Welzl), I think you have summarized the discussion well except, perhaps, for an imp= licit assumption on how rmcat flows will (or can) be used within a singular= WebRTC session (we really need to standardize what we mean by stream, flow= , session, association and other transport protocol naming conventions). Before I add commentary to your excellent email summary (with "MAR:" below)= , let me state a few points. Point 1: I have presumed that the rmcat congestion control algorithm (hopef= ully codified into an actual protocol specification someday) would be appli= ed to the MEDIA stream(s) within the WebRTC session. This is because non-st= reams WITHIN a WebRTC session can have different (and sometimes conflicting= ) requirements or characteristics. Point 2: Your "cross-flow" congestion control point is a very good one, but= one that is out-of-scope for RMCAT as I read the charter (Lars and Mirja c= an comment). Existing experience with conferencing sessions that have both = real-time, semi-real-time (e.g., "screen share" where a display of scrolli= ng screen can be delayed for a few 100 milliseconds) and non-real time elas= tic (e.g., background transfer) within them OVER A SINGULAR BOTTLENECK have= shown that it is necessary under congestion to PACE information in the non= -real time components of those streams in order for that the real-time stre= ams not be impaired. So your point is well taken, but out-of-scope. More be= low. Michael (Ramalho) -----Original Message----- From: Michael Welzl [mailto:michawe@ifi.uio.no]=20 Sent: Thursday, July 18, 2013 7:59 AM To: Eggert, Lars Cc: Wesley Eddy; Toerless Eckert (eckert); tsvwg@ietf.org; Mo Zanaty (mzana= ty); rmcat@ietf.org; Michael Ramalho (mramalho); James Polk (jmpolk); Cheng= -Jia Lai (chelai) Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only r= ate-adaptive for DiffServ Hi everyone, I'm still working off my email backlog, and in doing so I got a bit confuse= d about the various drafts and views in this space. Since the issue of inte= ractions with congestion control was also mentioned, I'll try to give a gen= eral comment here: First, about the stuff quoted below, it surprises me that we're even debati= ng algorithm-specific DSCPs - it should be rather obvious that we don't wan= t that?! I thought that the discussion is: a) 1 DSCP for rtcweb vs. b) multiple DSCPs for rtcweb (in which case I was thinking of e.g. video / = audio / data rather than algorithms) I have seen various emails that indicate agreement that we should have at l= east one DSCP for rtcweb in general. The reason that was given is that rmca= t's congestion control will prefer to not be exposed to TCP-like non-delay-= based traffic (even though it should be able to work reasonably well in the= presence of such traffic too). As many others, I totally agree. MAR: I think that is the point that started the thread. It is my only (indi= vidual, not WG) request to tsvwg. So let's move on to the next question, which is: should we have multiple DS= CPs (for multiple traffic classes) or not. Well, there are several pro's an= d con's here - surely more than I list below, but these are the ones I'd li= ke to lay out because of the coupled-cc stuff we're contributing to rmcat: Con's of multiple DSCPs: - 1 DSCP is simpler. - Whatever the DSCPs achieve, for traffic from a single source going across= the same shared bottleneck, coupled congestion control can probably do a b= etter job (*) < =3D=3D=3D but see this footnote! Pro's of multiple DSCPs: - coupled congestion control only applies to traffic from one host. In othe= r words, protecting your latency-critical audio from your own data transfer= doesn't help you against the rtcweb data transfer that a family member gen= erates in your home, as (s)he sends his file across the same shared bottlen= eck. MAR: This is not within scope of RMCAT or TSVWG as I see it. It is likely w= ithin scope of WebRTC if they choose to look at it - and they can punt to T= SVWG or RMCAT to include in their charters if they desire. (*) Footnote: coupled congestion control should really only be applied when= we can be pretty sure that the traffic under control traverses the same sh= ared bottleneck. One simple way to achieve that for rtcweb is to say that a= ll traffic going from the same source to the same destination shares the sa= me bottleneck, but this only applies if "source" and "destination" includes= the port number, i.e. if traffic is multiplexed over the same 5-tuple ***A= ND IF IT SHARES THE SAME DSCP*** (so here we have the DSCP constraint). Due= to the amount of traffic on their list I find it hard to track rtcweb, but= it seems to me that it's not guaranteed that all rtcweb traffic will indee= d be multiplexed in this fashion. Moreover, such shared bottleneck detectio= n is rather limiting - it's also quite possible that traffic from the same = source to multiple destinations traverses the same shared bottleneck (typic= ally the source's access link), but this method would then only apply coupl= ed congestion control across flows towards the same destination. >From the above, it seems clear that we're better off using measurement-base= d shared bottleneck detection anyway, and we're working on that. Note that = any measurement-based mechanism will have to look at correlations to determ= ine if traffic shares the same queue, and therefore such a method should di= scover that flows which carry different DSCPs do *not* share the same bottl= eneck. Thus, it would automatically do the right thing. MAR: Thankfully, for the shared bottleneck problem you are considering here= , the WebRTC (sub) stream which is causing the undue congestion relative to= the total WebRTC stream (sometimes called "self-induced" congestion) can s= ense it quickly. So it is not clear to me that having a congestion measurem= ent apparatus shared by all flows in a WebRTC session (which would appear t= o be the optimal solution if information flows between the flows were well = specified and instantaneous) is actually better in practice. To summarize, it seems that using multiple DSCPs for rtcweb can help, but c= reates a conflict with something that we shouldn't really rely on for coupl= ed congestion control. Therefore, it probably isn't really a big problem fr= om a congestion control point of view. I think that simplicity is perhaps a= more important argument for only one DSCP. MAR: Independent of your conclusion (and thank you for making it so clear),= I believe it to be out of scope for RMCAT. I would suggest that these issu= es be brought to WebRTC. My 2 cents. Cheers, Michael On Jul 18, 2013, at 8:41 AM, "Eggert, Lars" wrote: > On Jul 17, 2013, at 20:26, Wesley Eddy wrote: >> It is not wise, in my opinion, to have algorithm-specific DSCPs. >> The DSCPs need to indicate the desired forwarding behavior, and not=20 >> what version of code the end-host runs. >=20 > +1 >=20 > Lars From michawe@ifi.uio.no Fri Jul 19 02:37:30 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30A311E80FB; Fri, 19 Jul 2013 02:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hi-bPWxk-eE8; Fri, 19 Jul 2013 02:37:25 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 56FF411E80F8; Fri, 19 Jul 2013 02:37:24 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1V077n-0002Sj-3t; Fri, 19 Jul 2013 11:37:19 +0200 Received: from 089144206079.atnat0015.highway.bob.at ([89.144.206.79] helo=[192.168.1.6]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1V077j-0005gD-Th; Fri, 19 Jul 2013 11:37:19 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Welzl In-Reply-To: Date: Fri, 19 Jul 2013 11:37:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> <51E6E1D5.1050006@mti-systems.com> <460B8D74-2700-4875-B970-16D5936F3F58@netapp.com> <2CB66184-A7BF-45CD-9C9F-7B252EAD4088@ifi.uio.no> To: Michael Ramalho (mramalho) X-Mailer: Apple Mail (2.1508) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 1 sum rcpts/h 16 sum msgs/h 3 total rcpts 5883 max rcpts/h 40 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: 6DDA99BCAB359C3EA4BF256B3E3B47E73880D2C0 X-UiO-SPAM-Test: remote_host: 89.144.206.79 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 71 max/h 10 blacklist 0 greylist 0 ratelimit 0 Cc: "tsvwg@ietf.org" , "Mo Zanaty \(mzanaty\)" , "rmcat@ietf.org" , "James Polk \(jmpolk\)" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 09:37:30 -0000 Hi, See in line below - On Jul 18, 2013, at 4:52 PM, Michael Ramalho (mramalho) = wrote: > Michael (Welzl), >=20 > I think you have summarized the discussion well except, perhaps, for = an implicit assumption on how rmcat flows will (or can) be used within a = singular WebRTC session (we really need to standardize what we mean by = stream, flow, session, association and other transport protocol naming = conventions). >=20 > Before I add commentary to your excellent email summary (with "MAR:" = below), let me state a few points. >=20 > Point 1: I have presumed that the rmcat congestion control algorithm = (hopefully codified into an actual protocol specification someday) would = be applied to the MEDIA stream(s) within the WebRTC session. This is = because non-streams WITHIN a WebRTC session can have different (and = sometimes conflicting) requirements or characteristics. I assume that you mean "non-media-streams" with "non-streams"? Anyway: non-media streams are out of scope for rmcat, but as a technical = eventual decision, it would be bad to not apply rmcat congestion control = to *all* the traffic that shares a bottleneck. I know there are more, = but I think we all agree that one key requirement for RMCAT congestion = control is low delay. We're not going to get low delay if the browser = we're dealing with for rtcweb uses e.g. a loss-based congestion control = (for data) in addition to a delay-based congestion control (for media) = across the same bottleneck - that's exactly the situation we'd like to = avoid. Even if we have multiple individual delay-minimizing rtcweb = flows, they will compete for bandwidth on the bottleneck that they = share, which inevitably causes more queue growth than necessary. 2 flows = of whatever mechanism you can come up with create more queue growth than = 1, so we should strive to avoid that sort of competition. I'm arguing that this would be best design-wise, but I'd also say we = don't have to worry about rtcweb data streams for now, they are indeed = out of scope for RMCAT. Yet, even if we want to minimize the delay for = media streams only, ignoring the possibility of a data channel, then = we're still better off if we combine the media streams' congestion = controllers whenever we can. I might have been sloppy in talking about coupled congestion control = being applied to both data and media when, at this point, in the RMCAT = context, we should probably ignore data - sorry! > Point 2: Your "cross-flow" congestion control point is a very good = one, but one that is out-of-scope for RMCAT as I read the charter (Lars = and Mirja can comment). Existing experience with conferencing I'm sure it's not. We're really re-iterating a pre-BOF discussion here; = there was uniform agreement that we'd need such congestion control = coupling, culminating in this text bits in the charter: "The working group will: (..) - Develop a mechanism for identifying = shared bottlenecks between groups of flows, and means to flexibly allocate their rates within the aggregate = hitting the shared bottleneck." "Deliverables: (..) - Identifying and controlling groups of flows as a = Proposed Standard RFC" "Milestones: (..)=20 Jan 2014=09 Adopt first WG draft on identifying and controlling groups of flows Jul 2014=09 Submit identifying and controlling groups of flows to IESG for Standards = Track publication" > sessions that have both real-time, semi-real-time (e.g., "screen = share" where a display of scrolling screen can be delayed for a few 100 = milliseconds) and non-real time elastic (e.g., background transfer) = within them OVER A SINGULAR BOTTLENECK have shown that it is necessary = under congestion to PACE information in the non-real time components of = those streams in order for that the real-time streams not be impaired. = So your point is well taken, but out-of-scope. More below. Pacing is surely one possible way of doing it. Anyway I don't see a = conflict here. Also more below=85. > Michael (Ramalho) >=20 > -----Original Message----- > From: Michael Welzl [mailto:michawe@ifi.uio.no]=20 > Sent: Thursday, July 18, 2013 7:59 AM > To: Eggert, Lars > Cc: Wesley Eddy; Toerless Eckert (eckert); tsvwg@ietf.org; Mo Zanaty = (mzanaty); rmcat@ietf.org; Michael Ramalho (mramalho); James Polk = (jmpolk); Cheng-Jia Lai (chelai) > Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. = loss-only rate-adaptive for DiffServ >=20 > Hi everyone, >=20 > I'm still working off my email backlog, and in doing so I got a bit = confused about the various drafts and views in this space. Since the = issue of interactions with congestion control was also mentioned, I'll = try to give a general comment here: >=20 > First, about the stuff quoted below, it surprises me that we're even = debating algorithm-specific DSCPs - it should be rather obvious that we = don't want that?! I thought that the discussion is: > a) 1 DSCP for rtcweb > vs. > b) multiple DSCPs for rtcweb (in which case I was thinking of e.g. = video / audio / data rather than algorithms) >=20 > I have seen various emails that indicate agreement that we should have = at least one DSCP for rtcweb in general. The reason that was given is = that rmcat's congestion control will prefer to not be exposed to = TCP-like non-delay-based traffic (even though it should be able to work = reasonably well in the presence of such traffic too). As many others, I = totally agree. >=20 > MAR: I think that is the point that started the thread. It is my only = (individual, not WG) request to tsvwg. >=20 > So let's move on to the next question, which is: should we have = multiple DSCPs (for multiple traffic classes) or not. Well, there are = several pro's and con's here - surely more than I list below, but these = are the ones I'd like to lay out because of the coupled-cc stuff we're = contributing to rmcat: >=20 > Con's of multiple DSCPs: > - 1 DSCP is simpler. > - Whatever the DSCPs achieve, for traffic from a single source going = across the same shared bottleneck, coupled congestion control can = probably do a better job (*) < =3D=3D=3D but see this footnote! >=20 > Pro's of multiple DSCPs: > - coupled congestion control only applies to traffic from one host. In = other words, protecting your latency-critical audio from your own data = transfer doesn't help you against the rtcweb data transfer that a family = member generates in your home, as (s)he sends his file across the same = shared bottleneck. >=20 > MAR: This is not within scope of RMCAT or TSVWG as I see it. It is = likely within scope of WebRTC if they choose to look at it - and they = can punt to TSVWG or RMCAT to include in their charters if they desire. The "data transfer" bit isn't in scope, but coupled congestion control = is. So my example wasn't quite ideal, all you need to do is to replace = "latency-critical audio" with e.g. "high priority audio" and "data = transfer" with e.g. "low priority video" in my "Pro's of multiple DSCPs" = sentence above. > (*) Footnote: coupled congestion control should really only be applied = when we can be pretty sure that the traffic under control traverses the = same shared bottleneck. One simple way to achieve that for rtcweb is to = say that all traffic going from the same source to the same destination = shares the same bottleneck, but this only applies if "source" and = "destination" includes the port number, i.e. if traffic is multiplexed = over the same 5-tuple ***AND IF IT SHARES THE SAME DSCP*** (so here we = have the DSCP constraint). Due to the amount of traffic on their list I = find it hard to track rtcweb, but it seems to me that it's not = guaranteed that all rtcweb traffic will indeed be multiplexed in this = fashion. Moreover, such shared bottleneck detection is rather limiting - = it's also quite possible that traffic from the same source to multiple = destinations traverses the same shared bottleneck (typically the = source's access link), but this method would then only apply coupled = congestion control across flows towards the same destination. >=20 > =46rom the above, it seems clear that we're better off using = measurement-based shared bottleneck detection anyway, and we're working = on that. Note that any measurement-based mechanism will have to look at = correlations to determine if traffic shares the same queue, and = therefore such a method should discover that flows which carry different = DSCPs do *not* share the same bottleneck. Thus, it would automatically = do the right thing. >=20 > MAR: Thankfully, for the shared bottleneck problem you are considering = here, the WebRTC (sub) stream which is causing the undue congestion = relative to the total WebRTC stream (sometimes called "self-induced" = congestion) can sense it quickly. So it is not clear to me that having a = congestion measurement apparatus shared by all flows in a WebRTC session = (which would appear to be the optimal solution if information flows = between the flows were well specified and instantaneous) is actually = better in practice. We'll hopefully be able to show some results in Berlin that will = convince you that this is indeed better in practice. As for the information flow between flows being well specified, we're = trying to address this here: http://tools.ietf.org/html/draft-welzl-rmcat-coupled-cc-01 and this document needs some discussion, so please take a look and = comment! As for the information flow between flows being instantaneous, at least = for now, we're working with the notion that a flow only needs to talk to = our coupling entity (which we call "Flow State Exchange (FSE)") whenever = it updates it sending rate as a result of its own congestion control, = and the FSE does *not* need to immediately notify all other flows. So, = the constraint regarding "instantaneous" information flow is quite = relaxed - we did this because a design goal of ours was to minimize the = changes required to applications already implementing one or another = form of congestion control. > To summarize, it seems that using multiple DSCPs for rtcweb can help, = but creates a conflict with something that we shouldn't really rely on = for coupled congestion control. Therefore, it probably isn't really a = big problem from a congestion control point of view. I think that = simplicity is perhaps a more important argument for only one DSCP. >=20 > MAR: Independent of your conclusion (and thank you for making it so = clear), I believe it to be out of scope for RMCAT. I would suggest that = these issues be brought to WebRTC. I do hope that I have now convinced you that shared bottleneck detection = and congestion control coupling are in scope, and only my mentioning of = "data" was out of scope (even though I do think that including the data = channel, at some point in the future, would lead to better overall = behavior anyway). Cheers, Michael From brian.e.carpenter@gmail.com Fri Jul 19 13:08:45 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0195D21F9E52; Fri, 19 Jul 2013 13:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sd4azJmLDIxz; Fri, 19 Jul 2013 13:08:44 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 406CA11E80F4; Fri, 19 Jul 2013 13:08:44 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id wz7so4827175pbc.9 for ; Fri, 19 Jul 2013 13:08:44 -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=ULcNS2AmYCQHpKQXwXykTfDhfv1liQ5e9CVfU7HPeNc=; b=k7fJ/G/hXessK0RerfLqsAM3RjF5cPieiev4D8c6xMtnbChVMLBKV0XvjJ5YtRcfnY SpAOK6RkRk37g2F/1+dMUTV7stNqUlW8OyxqJnenOZjjtdySklPdUHw2Adk9w9Ad3sIw GDjzpeVd9PGHLMSbMaCRoisae4229gNM/zgjIyanGqQNj3k+aYvjLIWr5DUBCYa9E/2T irGlHo2bnlWExs9bK5TMPRZfzGsabnafh9Ha6aiy1eXfevT5B7Hjj0UVEiX5gzykYvCj /E0WCiu9xgUcoypUcquP21fZ+Cyc2ORjJR1cCFe7VD9nrDoFvEOuQWuNgBkoqMhbL5Ui LCnQ== X-Received: by 10.66.228.72 with SMTP id sg8mr19962253pac.45.1374264522984; Fri, 19 Jul 2013 13:08:42 -0700 (PDT) Received: from [192.168.178.23] (31.195.69.111.dynamic.snap.net.nz. [111.69.195.31]) by mx.google.com with ESMTPSA id aj3sm24301431pad.8.2013.07.19.13.08.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 13:08:41 -0700 (PDT) Message-ID: <51E99CCE.9090103@gmail.com> Date: Sat, 20 Jul 2013 08:08:46 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Welzl References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> <51E6E1D5.1050006@mti-systems.com> <460B8D74-2700-4875-B970-16D5936F3F58@netapp.com> <2CB66184-A7BF-45CD-9C9F-7B252EAD4088@ifi.uio.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "rmcat@ietf.org" , "James Polk \(jmpolk\)" , "Mo Zanaty \(mzanaty\)" , "Michael Ramalho \(mramalho\)" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 20:08:45 -0000 On 19/07/2013 21:37, Michael Welzl wrote: > Hi, > > See in line below - > > > On Jul 18, 2013, at 4:52 PM, Michael Ramalho (mramalho) > wrote: > >> Michael (Welzl), >> >> I think you have summarized the discussion well except, >> perhaps, for an implicit assumption on how rmcat flows will >> (or can) be used within a singular WebRTC session (we >> really need to standardize what we mean by stream, flow, >> session, association and other transport protocol naming >> conventions). >> >> Before I add commentary to your excellent email summary >> (with "MAR:" below), let me state a few points. >> >> Point 1: I have presumed that the rmcat congestion control >> algorithm (hopefully codified into an actual protocol >> specification someday) would be applied to the MEDIA >> stream(s) within the WebRTC session. This is because >> non-streams WITHIN a WebRTC session can have different (and >> sometimes conflicting) requirements or characteristics. > > I assume that you mean "non-media-streams" with > "non-streams"? > > Anyway: non-media streams are out of scope for rmcat, but as > a technical eventual decision, it would be bad to not apply > rmcat congestion control to *all* the traffic that shares a > bottleneck. I know there are more, but I think we all agree > that one key requirement for RMCAT congestion control is low > delay. We're not going to get low delay if the browser we're > dealing with for rtcweb uses e.g. a loss-based congestion > control (for data) in addition to a delay-based congestion > control (for media) across the same bottleneck - that's > exactly the situation we'd like to avoid. I'm rather confused. As I understand things, this is by definition a situation you can't avoid in the Internet, since the mix of traffic at any point, including at a bottleneck, is completely arbitrary. What you have just described is *exactly* why our scaleable QoS model (diffserv) defines qualitatively different per-hop behaviours, so that a delay-based PHB can coexist with a loss-based PHB at the same interface. Needless to say, there is no free lunch, which is why the default PHB (for all unclassified traffic) gets no guarantees at all. Wishing that it was different cannot make it different - delay- sensitive traffic competes with loss-sensitive traffic, because that's how the world works. > Even if we have > multiple individual delay-minimizing rtcweb flows, they will > compete for bandwidth on the bottleneck that they share, > which inevitably causes more queue growth than necessary. 2 > flows of whatever mechanism you can come up with create more > queue growth than 1, so we should strive to avoid that sort > of competition. > > I'm arguing that this would be best design-wise, but I'd also > say we don't have to worry about rtcweb data streams for now, > they are indeed out of scope for RMCAT. Yet, even if we want > to minimize the delay for media streams only, ignoring the > possibility of a data channel, then we're still better off if > we combine the media streams' congestion controllers whenever > we can. That is definitely true - if you have N streams that need the same PHB, running them as a single behaviour aggregate is always better. > > I might have been sloppy in talking about coupled congestion > control being applied to both data and media when, at this > point, in the RMCAT context, we should probably ignore data - > sorry! Do you mean ignore it, or simply regard it as background traffic that will soak up all resources that media traffic doesn't use? I think those are two rather different things. Brian From carlberg@g11.org.uk Fri Jul 19 13:39:39 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BED011E81B2; Fri, 19 Jul 2013 13:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsKv1sujk2us; Fri, 19 Jul 2013 13:39:34 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id F28E211E80D3; Fri, 19 Jul 2013 13:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=yjGfbGofei3jXUsO3FqUXyRtkn0WKyUzoH8aCftz6oU=; b=GKoK6JAG480jYBv0HiJriEY6HJBf5A34jedrw3uJUbQQ4NMae8+NXkxh43FTYVn9rXZbWLmB53N9xY8z1+fFWroWEShYEdGSNPT4wrkDR0K/eI+ROwPZ2UuiLP0n2kBy; Received: from c-98-218-170-72.hsd1.va.comcast.net ([98.218.170.72]:32937 helo=[10.0.1.20]) by portland.eukhosting.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1V0HSb-003jDr-Dv; Fri, 19 Jul 2013 21:39:29 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: ken carlberg In-Reply-To: <51E99CCE.9090103@gmail.com> Date: Fri, 19 Jul 2013 16:39:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> <51E6E1D5.1050006@mti-systems.com> <460B8D74-2700-4875-B970-16D5936F3F58@netapp.com> <2CB66184-A7BF-45CD-9C9F-7B252EAD4088@ifi.uio.no> <51E99CCE.9090103@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Get-Message-Sender-Via: portland.eukhosting.net: acl_c_relayhosts_text_entry: carlberg@g11.org.uk|g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: "tsvwg@ietf.org" , Michael Welzl , "Mo Zanaty \(mzanaty\)" , "rmcat@ietf.org" , "Michael Ramalho \(mramalho\)" , "James Polk \(jmpolk\)" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 20:39:39 -0000 On Jul 19, 2013, at 4:08 PM, Brian E Carpenter = wrote: > I'm rather confused. As I understand things, this is by > definition a situation you can't avoid in the Internet, since > the mix of traffic at any point, including at a bottleneck, is > completely arbitrary. What you have just described is *exactly* > why our scaleable QoS model (diffserv) defines qualitatively > different per-hop behaviours, so that a delay-based PHB can > coexist with a loss-based PHB at the same interface. Needless to > say, there is no free lunch, which is why the default PHB (for > all unclassified traffic) gets no guarantees at all. >=20 > Wishing that it was different cannot make it different - delay- > sensitive traffic competes with loss-sensitive traffic, because > that's how the world works. there is actually some middle ground. Traffic engineering exists and is = used to do some measure of segmentation of flows -- particularly in = access networks that are more prone to congestion than transit = backbones. And TE tends to get even more pronounced in "walled = gardens"*. The issues to keep in mind is that your mileage may very = depending on the providers, and you can't count on it existing = throughout the Internet -- its a jungle out there and one has to = consider/accept the worst case scenario of an arbitrary traffic mix.=20 -ken * a fair amount of folks don't consider "walled gardens" as part of the = Internet, or of concern to the IETF. I'll acknowledge the viewpoint, = and respectfully disagree by keeping in mind the original phrase "an = internetwork of networks".= From mramalho@cisco.com Fri Jul 19 14:32:59 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68C111E817C; Fri, 19 Jul 2013 14:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Kl+jyW7Ze-f; Fri, 19 Jul 2013 14:32:54 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 75E8F11E8173; Fri, 19 Jul 2013 14:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14093; q=dns/txt; s=iport; t=1374269574; x=1375479174; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9ZkuZIlcZ99nt4qMpcH/xwME5rbFN94HTHBk6iLXHQY=; b=iUxvYlSNGigjls/A5UJu7LOGLdk0MEVlos6ZRRnCeMBj1oW3uwS2trWk PTlvnUTwxAWUL0YCd2ILClwbYemNjpPGIXGvKMRVoBKMcsgOTtt3nH/uG VyNquIcMLlwyw10x5I7/88LC7nzFpeF2/kEMreKSGAcTGquHS9lo0UbC2 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAPOv6VGtJXHA/2dsb2JhbABbgwY1UMBJgREWdIIkAQEBAwE6PwUHBAIBCA4DBAEBCxQJBzIUCAEIAgQKBAUIE4dvBgy3K45NCoEHMQcGgwpuA5QGhQCQJIFZgTmBaAkXIg X-IronPort-AV: E=Sophos;i="4.89,704,1367971200"; d="scan'208";a="237146771" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 19 Jul 2013 21:32:52 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6JLWqKq030859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Jul 2013 21:32:52 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.54]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 16:32:52 -0500 From: "Michael Ramalho (mramalho)" To: Michael Welzl Thread-Topic: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ Thread-Index: AQHOgpz4+m0uun89XEWA3y5OIxdfmJlphOaAgADNWgCAAFigAP//z5dggAGbMAD///d2gA== Date: Fri, 19 Jul 2013 21:32:51 +0000 Message-ID: References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> <51E6E1D5.1050006@mti-systems.com> <460B8D74-2700-4875-B970-16D5936F3F58@netapp.com> <2CB66184-A7BF-45CD-9C9F-7B252EAD4088@ifi.uio.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.125.234] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tsvwg@ietf.org" , "Mo Zanaty \(mzanaty\)" , "rmcat@ietf.org" , "James Polk \(jmpolk\)" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 21:32:59 -0000 Hi Michael, A few more comments below, identified with "MAR2:". Before I begin, let's say we are also re-visiting an email thread of a few = weeks ago. I should have been more clear about the "cross-stream" part. We = agreed in my July 5 email (and your reply to it) that all applications ON A= GIVEN HOST could know about each other (what we called Case 1 - same sourc= e address with potentially different destination addresses). However the ca= se of a shared bottleneck created by applications on different hosts (what = we called Case 2 - having different source addresses) you agreed was out-of= -scope. Now apparently you are calling "Case 2" back in scope when referring to "*a= ll* the traffic that shares a bottleneck" (your quote and your emphasis). T= hat is the part I disagree with. Michael Ramalho -----Original Message----- From: Michael Welzl [mailto:michawe@ifi.uio.no]=20 Sent: Friday, July 19, 2013 5:37 AM To: Michael Ramalho (mramalho) Cc: Eggert, Lars; Wesley Eddy; Toerless Eckert (eckert); tsvwg@ietf.org; Mo= Zanaty (mzanaty); rmcat@ietf.org; James Polk (jmpolk); Cheng-Jia Lai (chel= ai) Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only r= ate-adaptive for DiffServ Hi, See in line below - On Jul 18, 2013, at 4:52 PM, Michael Ramalho (mramalho) wrote: > Michael (Welzl), >=20 > I think you have summarized the discussion well except, perhaps, for an i= mplicit assumption on how rmcat flows will (or can) be used within a singul= ar WebRTC session (we really need to standardize what we mean by stream, fl= ow, session, association and other transport protocol naming conventions). >=20 > Before I add commentary to your excellent email summary (with "MAR:" belo= w), let me state a few points. >=20 > Point 1: I have presumed that the rmcat congestion control algorithm (hop= efully codified into an actual protocol specification someday) would be app= lied to the MEDIA stream(s) within the WebRTC session. This is because non-= streams WITHIN a WebRTC session can have different (and sometimes conflicti= ng) requirements or characteristics. I assume that you mean "non-media-streams" with "non-streams"? MAR2: Duh. Yeah. Sorry. Anyway: non-media streams are out of scope for rmcat, but as a technical ev= entual decision, it would be bad to not apply rmcat congestion control to *= all* the traffic that shares a bottleneck. MAR2: But "*all* traffic that shares a bottleneck" includes the traffic fr= om other hosts too! You previously agreed (on July 5) all those other flows= are out of scope! MAR2: If you meant "all the traffic IN A SPECIFIC WebRTC session" (i.e., bo= th media and non-media streams), then I agree. MAR2: Let's please try to differentiate the cases (or equivalently, precise= ly specify the subset of the bottleneck traffic you are considering). I know there are more, but I think we all agree that one key requirement fo= r RMCAT congestion control is low delay. We're not going to get low delay i= f the browser we're dealing with for rtcweb uses e.g. a loss-based congesti= on control (for data) in addition to a delay-based congestion control (for = media) across the same bottleneck - that's exactly the situation we'd like = to avoid. Even if we have multiple individual delay-minimizing rtcweb flows= , they will compete for bandwidth on the bottleneck that they share, which = inevitably causes more queue growth than necessary. MAR2: Yes, two independent control loops not knowing of each other could co= ntribute to a doubling of the queue that one alone could do with bad timing= . Join the design team meetings to specify the experiments you want to see. 2 flows of whatever mechanism you can come up with create more queue growth= than 1, so we should strive to avoid that sort of competition. I'm arguing that this would be best design-wise, but I'd also say we don't = have to worry about rtcweb data streams for now, they are indeed out of sco= pe for RMCAT. Yet, even if we want to minimize the delay for media streams = only, ignoring the possibility of a data channel, then we're still better o= ff if we combine the media streams' congestion controllers whenever we can. I might have been sloppy in talking about coupled congestion control being = applied to both data and media when, at this point, in the RMCAT context, w= e should probably ignore data - sorry! > Point 2: Your "cross-flow" congestion control point is a very good=20 > one, but one that is out-of-scope for RMCAT as I read the charter=20 > (Lars and Mirja can comment). Existing experience with conferencing I'm sure it's not. We're really re-iterating a pre-BOF discussion here; the= re was uniform agreement that we'd need such congestion control coupling, c= ulminating in this text bits in the charter: "The working group will: (..) - Develop a mechanism for identifying shared= bottlenecks between groups of flows, and means to flexibly allocate their = rates within the aggregate hitting the shared bottleneck." "Deliverables: (..) - Identifying and controlling groups of flows as a Prop= osed Standard RFC" "Milestones: (..)=20 Jan 2014=09 Adopt first WG draft on identifying and controlling groups of flows Jul 2014=09 Submit identifying and controlling groups of flows to IESG for Standards Tr= ack publication" MAR2: We have been down this road before (on July 5). My comment was in res= ponse to your "all traffic" comment. By my reading, your draft AND the RMCA= T charter exclusively deals with flows emanating from a given host, and the= refore limited in scope to ONLY THAT SUBSET of "all traffic hitting the sha= red bottleneck" that came from a given host. Q.E.D. MAR2: I stand behind my statement that it is outside the scope of RMCAT to = consider "cross-flow" information from flows from a multiplicity of hosts t= hat could have contributed traffic to the bottleneck. MAR2: Perhaps we need to tighten the words in the charter so that they mean= the same thing to everyone ;-). > sessions that have both real-time, semi-real-time (e.g., "screen share" w= here a display of scrolling screen can be delayed for a few 100 millisecon= ds) and non-real time elastic (e.g., background transfer) within them OVER = A SINGULAR BOTTLENECK have shown that it is necessary under congestion to P= ACE information in the non-real time components of those streams in order f= or that the real-time streams not be impaired. So your point is well taken,= but out-of-scope. More below. Pacing is surely one possible way of doing it. Anyway I don't see a conflic= t here. Also more below.... > Michael (Ramalho) >=20 > -----Original Message----- > From: Michael Welzl [mailto:michawe@ifi.uio.no] > Sent: Thursday, July 18, 2013 7:59 AM > To: Eggert, Lars > Cc: Wesley Eddy; Toerless Eckert (eckert); tsvwg@ietf.org; Mo Zanaty=20 > (mzanaty); rmcat@ietf.org; Michael Ramalho (mramalho); James Polk=20 > (jmpolk); Cheng-Jia Lai (chelai) > Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs.=20 > loss-only rate-adaptive for DiffServ >=20 > Hi everyone, >=20 > I'm still working off my email backlog, and in doing so I got a bit confu= sed about the various drafts and views in this space. Since the issue of in= teractions with congestion control was also mentioned, I'll try to give a g= eneral comment here: >=20 > First, about the stuff quoted below, it surprises me that we're even deba= ting algorithm-specific DSCPs - it should be rather obvious that we don't w= ant that?! I thought that the discussion is: > a) 1 DSCP for rtcweb > vs. > b) multiple DSCPs for rtcweb (in which case I was thinking of e.g.=20 > video / audio / data rather than algorithms) >=20 > I have seen various emails that indicate agreement that we should have at= least one DSCP for rtcweb in general. The reason that was given is that rm= cat's congestion control will prefer to not be exposed to TCP-like non-dela= y-based traffic (even though it should be able to work reasonably well in t= he presence of such traffic too). As many others, I totally agree. >=20 > MAR: I think that is the point that started the thread. It is my only (in= dividual, not WG) request to tsvwg. >=20 > So let's move on to the next question, which is: should we have multiple = DSCPs (for multiple traffic classes) or not. Well, there are several pro's = and con's here - surely more than I list below, but these are the ones I'd = like to lay out because of the coupled-cc stuff we're contributing to rmcat= : >=20 > Con's of multiple DSCPs: > - 1 DSCP is simpler. > - Whatever the DSCPs achieve, for traffic from a single source going acro= ss the same shared bottleneck, coupled congestion control can probably do a= better job (*) < =3D=3D=3D but see this footnote! >=20 > Pro's of multiple DSCPs: > - coupled congestion control only applies to traffic from one host. In ot= her words, protecting your latency-critical audio from your own data transf= er doesn't help you against the rtcweb data transfer that a family member g= enerates in your home, as (s)he sends his file across the same shared bottl= eneck. >=20 > MAR: This is not within scope of RMCAT or TSVWG as I see it. It is likely= within scope of WebRTC if they choose to look at it - and they can punt to= TSVWG or RMCAT to include in their charters if they desire. The "data transfer" bit isn't in scope, but coupled congestion control is. = So my example wasn't quite ideal, all you need to do is to replace "latency= -critical audio" with e.g. "high priority audio" and "data transfer" with e= .g. "low priority video" in my "Pro's of multiple DSCPs" sentence above. > (*) Footnote: coupled congestion control should really only be applied wh= en we can be pretty sure that the traffic under control traverses the same = shared bottleneck. One simple way to achieve that for rtcweb is to say that= all traffic going from the same source to the same destination shares the = same bottleneck, but this only applies if "source" and "destination" includ= es the port number, i.e. if traffic is multiplexed over the same 5-tuple **= *AND IF IT SHARES THE SAME DSCP*** (so here we have the DSCP constraint). D= ue to the amount of traffic on their list I find it hard to track rtcweb, b= ut it seems to me that it's not guaranteed that all rtcweb traffic will ind= eed be multiplexed in this fashion. Moreover, such shared bottleneck detect= ion is rather limiting - it's also quite possible that traffic from the sam= e source to multiple destinations traverses the same shared bottleneck (typ= ically the source's access link), but this method would then only apply cou= pled congestion control across flows towards the same destination. >=20 > From the above, it seems clear that we're better off using measurement-ba= sed shared bottleneck detection anyway, and we're working on that. Note tha= t any measurement-based mechanism will have to look at correlations to dete= rmine if traffic shares the same queue, and therefore such a method should = discover that flows which carry different DSCPs do *not* share the same bot= tleneck. Thus, it would automatically do the right thing. >=20 > MAR: Thankfully, for the shared bottleneck problem you are considering he= re, the WebRTC (sub) stream which is causing the undue congestion relative = to the total WebRTC stream (sometimes called "self-induced" congestion) can= sense it quickly. So it is not clear to me that having a congestion measur= ement apparatus shared by all flows in a WebRTC session (which would appear= to be the optimal solution if information flows between the flows were wel= l specified and instantaneous) is actually better in practice. We'll hopefully be able to show some results in Berlin that will convince y= ou that this is indeed better in practice. As for the information flow between flows being well specified, we're tryin= g to address this here: http://tools.ietf.org/html/draft-welzl-rmcat-coupled-cc-01 and this document needs some discussion, so please take a look and comment! As for the information flow between flows being instantaneous, at least for= now, we're working with the notion that a flow only needs to talk to our c= oupling entity (which we call "Flow State Exchange (FSE)") whenever it upda= tes it sending rate as a result of its own congestion control, and the FSE = does *not* need to immediately notify all other flows. So, the constraint r= egarding "instantaneous" information flow is quite relaxed - we did this be= cause a design goal of ours was to minimize the changes required to applica= tions already implementing one or another form of congestion control. > To summarize, it seems that using multiple DSCPs for rtcweb can help, but= creates a conflict with something that we shouldn't really rely on for cou= pled congestion control. Therefore, it probably isn't really a big problem = from a congestion control point of view. I think that simplicity is perhaps= a more important argument for only one DSCP. >=20 > MAR: Independent of your conclusion (and thank you for making it so clear= ), I believe it to be out of scope for RMCAT. I would suggest that these is= sues be brought to WebRTC. I do hope that I have now convinced you that shared bottleneck detection an= d congestion control coupling are in scope, and only my mentioning of "data= " was out of scope (even though I do think that including the data channel= , at some point in the future, would lead to better overall behavior anyway= ). MAR2: You haven't convinced me that coupled congestion control across diffe= rent hosts are in scope yet - because your own document at its present vers= ion number does not address the entire scope of the problem. Reasonable peo= ple can disagree. See you in Berlin. Cheers, Michael From brian.e.carpenter@gmail.com Fri Jul 19 16:12:13 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8284121E80B7; Fri, 19 Jul 2013 16:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5SHG6VHNYsD; Fri, 19 Jul 2013 16:12:13 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id EFA9721E80B4; Fri, 19 Jul 2013 16:12:12 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id y14so4739009pdi.2 for ; Fri, 19 Jul 2013 16:12:12 -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=DSEh7FlncbXeFiULDwqsiCNCt9/esVofPHXWrsbQDYw=; b=sDwIdKO9/SWCWb0CrwyXLW7H2Ty9yCk25zPITyo7k3tMJUZ6GM1pcRlA5l6WEgM6vw AtWaD/lIqlbXl8YP1i9X3zxMSYKKZ4m5o6PR7S4ujoxFjTg81pbE5+3scYVWvP7GSyKx xSJOF+1oH4qT7TWbaIMBr3F4C+XzNducH/Zqe1DJxCNgIh4p2HKpGeB94ElbgXWqFldb eum2I1qbKsebSsEUxQGGXCfv1ZKHyVbryTlrW1up8GtN53IfIm4BMQaEy/vj4+Pr2bBm Uz3KerR994eS8t+ZUxeFVsUSbAJXTlCaDKFSKyerBl41TvL5GVNsiX8cFA6xCedG7slJ X9Kw== X-Received: by 10.66.19.229 with SMTP id i5mr20179891pae.158.1374275532704; Fri, 19 Jul 2013 16:12:12 -0700 (PDT) Received: from [192.168.178.23] (31.195.69.111.dynamic.snap.net.nz. [111.69.195.31]) by mx.google.com with ESMTPSA id py4sm21748135pbc.14.2013.07.19.16.12.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 16:12:11 -0700 (PDT) Message-ID: <51E9C7D4.8010606@gmail.com> Date: Sat, 20 Jul 2013 11:12:20 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ken carlberg References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> <51E6E1D5.1050006@mti-systems.com> <460B8D74-2700-4875-B970-16D5936F3F58@netapp.com> <2CB66184-A7BF-45CD-9C9F-7B252EAD4088@ifi.uio.no> <51E99CCE.9090103@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "tsvwg@ietf.org" , Michael Welzl , "Mo Zanaty \(mzanaty\)" , "rmcat@ietf.org" , "Michael Ramalho \(mramalho\)" , "James Polk \(jmpolk\)" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 23:12:13 -0000 On 20/07/2013 08:39, ken carlberg wrote: > On Jul 19, 2013, at 4:08 PM, Brian E Carpenter wrote: > >> I'm rather confused. As I understand things, this is by >> definition a situation you can't avoid in the Internet, since >> the mix of traffic at any point, including at a bottleneck, is >> completely arbitrary. What you have just described is *exactly* >> why our scaleable QoS model (diffserv) defines qualitatively >> different per-hop behaviours, so that a delay-based PHB can >> coexist with a loss-based PHB at the same interface. Needless to >> say, there is no free lunch, which is why the default PHB (for >> all unclassified traffic) gets no guarantees at all. >> >> Wishing that it was different cannot make it different - delay- >> sensitive traffic competes with loss-sensitive traffic, because >> that's how the world works. > > there is actually some middle ground. Traffic engineering exists and is used to do some measure of segmentation of flows -- particularly in access networks that are more prone to congestion than transit backbones. Absolutely, but of course to do any kind of dynamic TE you need to be able to classify traffic somehow. > And TE tends to get even more pronounced in "walled gardens"*. The issues to keep in mind is that your mileage may very depending on the providers, and you can't count on it existing throughout the Internet -- its a jungle out there and one has to consider/accept the worst case scenario of an arbitrary traffic mix. Exactly. Whatever we do to improve matters inside a walled garden must not make things worse in that jungle. > -ken > > * a fair amount of folks don't consider "walled gardens" as part of the Internet, or of concern to the IETF. I'll acknowledge the viewpoint, and respectfully disagree by keeping in mind the original phrase "an internetwork of networks". I hesitate to keep banging on about the diffserv model, but I think it's a realistic paradigm, and it definitely assumes walled gardens as far as QoS is concerned (called "diffserv domains"). You can slice and dice the problem as much as you want, but I think we're stuck with the inter-domain model boiling down to best effort, in the absence of pairwise SLAs between competing providers. Brian From michawe@ifi.uio.no Sat Jul 20 00:18:54 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A7221F8F4F; Sat, 20 Jul 2013 00:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EjNaslPkfJP; Sat, 20 Jul 2013 00:18:49 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7A421F991F; Sat, 20 Jul 2013 00:18:48 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1V0RRB-00066B-SK; Sat, 20 Jul 2013 09:18:41 +0200 Received: from 089144206012.atnat0015.highway.bob.at ([89.144.206.12] helo=[192.168.1.6]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1V0RR6-0003Jq-0R; Sat, 20 Jul 2013 09:18:41 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Welzl In-Reply-To: Date: Sat, 20 Jul 2013 09:18:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <23C83A79-0ACB-418E-9915-3F71EAEC3DE2@ifi.uio.no> References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> <51E6E1D5.1050006@mti-systems.com> <460B8D74-2700-4875-B970-16D5936F3F58@netapp.com> <2CB66184-A7BF-45CD-9C9F-7B252EAD4088@ifi.uio.no> To: Michael Ramalho (mramalho) X-Mailer: Apple Mail (2.1508) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 1 sum rcpts/h 11 sum msgs/h 2 total rcpts 5899 max rcpts/h 40 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: B7F9FED832303AAFD54F6FF32AC3208EF804920D X-UiO-SPAM-Test: remote_host: 89.144.206.12 spam_score: -49 maxlevel 80 minaction 2 bait 0 blacklist 0 greylist 0 ratelimit 0 Cc: "tsvwg@ietf.org" , "Mo Zanaty \(mzanaty\)" , "rmcat@ietf.org" , "James Polk \(jmpolk\)" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 07:18:54 -0000 Hi, My apologies to everyone whose time I have wasted by not being clear = enough: this all seems to be a big misunderstanding. I am *not* calling "Case 2" back in scope and I really only meant = coupled congestion control for traffic from a single host. Note this bit from my first email in this discussion: ** Pro's of multiple DSCPs: - coupled congestion control only applies to traffic from one host. In = other words, protecting your latency-critical audio from your own data = transfer doesn't help you against the rtcweb data transfer that a family = member generates in your home, as (s)he sends his file across the same = shared bottleneck. ** A few things are somewhat off here: as we already discussed, I shouldn't = have mentioned "data transfer"; probably worse, the notion of = "protecting" is misleading, because what I really meant is that you = cannot use coupled congestion control to protect one flow against = another when that other doesn't originate from the same host. (then again, the first sentence was quite clear?! "coupled congestion = control only applies to traffic from one host.") Anyway, sorry again to everyone I have confused. As for joining the design team discussions, the usual time of the telco = doesn't work for me, but I plan to be at the design team meeting in = Berlin. Cheers, Michael On Jul 19, 2013, at 11:32 PM, Michael Ramalho (mramalho) = wrote: > Hi Michael, >=20 > A few more comments below, identified with "MAR2:". >=20 > Before I begin, let's say we are also re-visiting an email thread of a = few weeks ago. I should have been more clear about the "cross-stream" = part. We agreed in my July 5 email (and your reply to it) that all = applications ON A GIVEN HOST could know about each other (what we called = Case 1 - same source address with potentially different destination = addresses). However the case of a shared bottleneck created by = applications on different hosts (what we called Case 2 - having = different source addresses) you agreed was out-of-scope. >=20 > Now apparently you are calling "Case 2" back in scope when referring = to "*all* the traffic that shares a bottleneck" (your quote and your = emphasis). That is the part I disagree with. >=20 > Michael Ramalho >=20 > -----Original Message----- > From: Michael Welzl [mailto:michawe@ifi.uio.no]=20 > Sent: Friday, July 19, 2013 5:37 AM > To: Michael Ramalho (mramalho) > Cc: Eggert, Lars; Wesley Eddy; Toerless Eckert (eckert); = tsvwg@ietf.org; Mo Zanaty (mzanaty); rmcat@ietf.org; James Polk = (jmpolk); Cheng-Jia Lai (chelai) > Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. = loss-only rate-adaptive for DiffServ >=20 > Hi, >=20 > See in line below - >=20 >=20 > On Jul 18, 2013, at 4:52 PM, Michael Ramalho (mramalho) = wrote: >=20 >> Michael (Welzl), >>=20 >> I think you have summarized the discussion well except, perhaps, for = an implicit assumption on how rmcat flows will (or can) be used within a = singular WebRTC session (we really need to standardize what we mean by = stream, flow, session, association and other transport protocol naming = conventions). >>=20 >> Before I add commentary to your excellent email summary (with "MAR:" = below), let me state a few points. >>=20 >> Point 1: I have presumed that the rmcat congestion control algorithm = (hopefully codified into an actual protocol specification someday) would = be applied to the MEDIA stream(s) within the WebRTC session. This is = because non-streams WITHIN a WebRTC session can have different (and = sometimes conflicting) requirements or characteristics. >=20 > I assume that you mean "non-media-streams" with "non-streams"? >=20 > MAR2: Duh. Yeah. Sorry. >=20 > Anyway: non-media streams are out of scope for rmcat, but as a = technical eventual decision, it would be bad to not apply rmcat = congestion control to *all* the traffic that shares a bottleneck. >=20 > MAR2: But "*all* traffic that shares a bottleneck" includes the = traffic from other hosts too! You previously agreed (on July 5) all = those other flows are out of scope! >=20 > MAR2: If you meant "all the traffic IN A SPECIFIC WebRTC session" = (i.e., both media and non-media streams), then I agree. >=20 > MAR2: Let's please try to differentiate the cases (or equivalently, = precisely specify the subset of the bottleneck traffic you are = considering). >=20 > I know there are more, but I think we all agree that one key = requirement for RMCAT congestion control is low delay. We're not going = to get low delay if the browser we're dealing with for rtcweb uses e.g. = a loss-based congestion control (for data) in addition to a delay-based = congestion control (for media) across the same bottleneck - that's = exactly the situation we'd like to avoid. Even if we have multiple = individual delay-minimizing rtcweb flows, they will compete for = bandwidth on the bottleneck that they share, which inevitably causes = more queue growth than necessary. >=20 > MAR2: Yes, two independent control loops not knowing of each other = could contribute to a doubling of the queue that one alone could do with = bad timing. Join the design team meetings to specify the experiments you = want to see. >=20 > 2 flows of whatever mechanism you can come up with create more queue = growth than 1, so we should strive to avoid that sort of competition. >=20 > I'm arguing that this would be best design-wise, but I'd also say we = don't have to worry about rtcweb data streams for now, they are indeed = out of scope for RMCAT. Yet, even if we want to minimize the delay for = media streams only, ignoring the possibility of a data channel, then = we're still better off if we combine the media streams' congestion = controllers whenever we can. >=20 > I might have been sloppy in talking about coupled congestion control = being applied to both data and media when, at this point, in the RMCAT = context, we should probably ignore data - sorry! >=20 >> Point 2: Your "cross-flow" congestion control point is a very good=20 >> one, but one that is out-of-scope for RMCAT as I read the charter=20 >> (Lars and Mirja can comment). Existing experience with conferencing >=20 > I'm sure it's not. We're really re-iterating a pre-BOF discussion = here; there was uniform agreement that we'd need such congestion control = coupling, culminating in this text bits in the charter: >=20 > "The working group will: (..) - Develop a mechanism for identifying = shared bottlenecks between groups of flows, and means to flexibly = allocate their rates within the aggregate hitting the shared = bottleneck." >=20 > "Deliverables: (..) - Identifying and controlling groups of flows as a = Proposed Standard RFC" >=20 > "Milestones: (..)=20 > Jan 2014=09 > Adopt first WG draft on identifying and controlling groups of flows >=20 > Jul 2014=09 > Submit identifying and controlling groups of flows to IESG for = Standards Track publication" >=20 > MAR2: We have been down this road before (on July 5). My comment was = in response to your "all traffic" comment. By my reading, your draft AND = the RMCAT charter exclusively deals with flows emanating from a given = host, and therefore limited in scope to ONLY THAT SUBSET of "all traffic = hitting the shared bottleneck" that came from a given host. Q.E.D. >=20 > MAR2: I stand behind my statement that it is outside the scope of = RMCAT to consider "cross-flow" information from flows from a = multiplicity of hosts that could have contributed traffic to the = bottleneck. >=20 > MAR2: Perhaps we need to tighten the words in the charter so that they = mean the same thing to everyone ;-). >=20 >> sessions that have both real-time, semi-real-time (e.g., "screen = share" where a display of scrolling screen can be delayed for a few 100 = milliseconds) and non-real time elastic (e.g., background transfer) = within them OVER A SINGULAR BOTTLENECK have shown that it is necessary = under congestion to PACE information in the non-real time components of = those streams in order for that the real-time streams not be impaired. = So your point is well taken, but out-of-scope. More below. >=20 > Pacing is surely one possible way of doing it. Anyway I don't see a = conflict here. > Also more below.... >=20 >=20 >> Michael (Ramalho) >>=20 >> -----Original Message----- >> From: Michael Welzl [mailto:michawe@ifi.uio.no] >> Sent: Thursday, July 18, 2013 7:59 AM >> To: Eggert, Lars >> Cc: Wesley Eddy; Toerless Eckert (eckert); tsvwg@ietf.org; Mo Zanaty=20= >> (mzanaty); rmcat@ietf.org; Michael Ramalho (mramalho); James Polk=20 >> (jmpolk); Cheng-Jia Lai (chelai) >> Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs.=20 >> loss-only rate-adaptive for DiffServ >>=20 >> Hi everyone, >>=20 >> I'm still working off my email backlog, and in doing so I got a bit = confused about the various drafts and views in this space. Since the = issue of interactions with congestion control was also mentioned, I'll = try to give a general comment here: >>=20 >> First, about the stuff quoted below, it surprises me that we're even = debating algorithm-specific DSCPs - it should be rather obvious that we = don't want that?! I thought that the discussion is: >> a) 1 DSCP for rtcweb >> vs. >> b) multiple DSCPs for rtcweb (in which case I was thinking of e.g.=20 >> video / audio / data rather than algorithms) >>=20 >> I have seen various emails that indicate agreement that we should = have at least one DSCP for rtcweb in general. The reason that was given = is that rmcat's congestion control will prefer to not be exposed to = TCP-like non-delay-based traffic (even though it should be able to work = reasonably well in the presence of such traffic too). As many others, I = totally agree. >>=20 >> MAR: I think that is the point that started the thread. It is my only = (individual, not WG) request to tsvwg. >>=20 >> So let's move on to the next question, which is: should we have = multiple DSCPs (for multiple traffic classes) or not. Well, there are = several pro's and con's here - surely more than I list below, but these = are the ones I'd like to lay out because of the coupled-cc stuff we're = contributing to rmcat: >>=20 >> Con's of multiple DSCPs: >> - 1 DSCP is simpler. >> - Whatever the DSCPs achieve, for traffic from a single source going = across the same shared bottleneck, coupled congestion control can = probably do a better job (*) < =3D=3D=3D but see this footnote! >>=20 >> Pro's of multiple DSCPs: >> - coupled congestion control only applies to traffic from one host. = In other words, protecting your latency-critical audio from your own = data transfer doesn't help you against the rtcweb data transfer that a = family member generates in your home, as (s)he sends his file across the = same shared bottleneck. >>=20 >> MAR: This is not within scope of RMCAT or TSVWG as I see it. It is = likely within scope of WebRTC if they choose to look at it - and they = can punt to TSVWG or RMCAT to include in their charters if they desire. >=20 > The "data transfer" bit isn't in scope, but coupled congestion control = is. So my example wasn't quite ideal, all you need to do is to replace = "latency-critical audio" with e.g. "high priority audio" and "data = transfer" with e.g. "low priority video" in my "Pro's of multiple DSCPs" = sentence above. >=20 >=20 >> (*) Footnote: coupled congestion control should really only be = applied when we can be pretty sure that the traffic under control = traverses the same shared bottleneck. One simple way to achieve that for = rtcweb is to say that all traffic going from the same source to the same = destination shares the same bottleneck, but this only applies if = "source" and "destination" includes the port number, i.e. if traffic is = multiplexed over the same 5-tuple ***AND IF IT SHARES THE SAME DSCP*** = (so here we have the DSCP constraint). Due to the amount of traffic on = their list I find it hard to track rtcweb, but it seems to me that it's = not guaranteed that all rtcweb traffic will indeed be multiplexed in = this fashion. Moreover, such shared bottleneck detection is rather = limiting - it's also quite possible that traffic from the same source to = multiple destinations traverses the same shared bottleneck (typically = the source's access link), but this method would then only apply coupled = congestion control across flows towards the same destination. >>=20 >> =46rom the above, it seems clear that we're better off using = measurement-based shared bottleneck detection anyway, and we're working = on that. Note that any measurement-based mechanism will have to look at = correlations to determine if traffic shares the same queue, and = therefore such a method should discover that flows which carry different = DSCPs do *not* share the same bottleneck. Thus, it would automatically = do the right thing. >>=20 >> MAR: Thankfully, for the shared bottleneck problem you are = considering here, the WebRTC (sub) stream which is causing the undue = congestion relative to the total WebRTC stream (sometimes called = "self-induced" congestion) can sense it quickly. So it is not clear to = me that having a congestion measurement apparatus shared by all flows in = a WebRTC session (which would appear to be the optimal solution if = information flows between the flows were well specified and = instantaneous) is actually better in practice. >=20 > We'll hopefully be able to show some results in Berlin that will = convince you that this is indeed better in practice. > As for the information flow between flows being well specified, we're = trying to address this here: > http://tools.ietf.org/html/draft-welzl-rmcat-coupled-cc-01 > and this document needs some discussion, so please take a look and = comment! >=20 > As for the information flow between flows being instantaneous, at = least for now, we're working with the notion that a flow only needs to = talk to our coupling entity (which we call "Flow State Exchange (FSE)") = whenever it updates it sending rate as a result of its own congestion = control, and the FSE does *not* need to immediately notify all other = flows. So, the constraint regarding "instantaneous" information flow is = quite relaxed - we did this because a design goal of ours was to = minimize the changes required to applications already implementing one = or another form of congestion control. >=20 >=20 >> To summarize, it seems that using multiple DSCPs for rtcweb can help, = but creates a conflict with something that we shouldn't really rely on = for coupled congestion control. Therefore, it probably isn't really a = big problem from a congestion control point of view. I think that = simplicity is perhaps a more important argument for only one DSCP. >>=20 >> MAR: Independent of your conclusion (and thank you for making it so = clear), I believe it to be out of scope for RMCAT. I would suggest that = these issues be brought to WebRTC. >=20 > I do hope that I have now convinced you that shared bottleneck = detection and congestion control coupling are in scope, and only my = mentioning of "data" was out of scope (even though I do think that = including the data channel, at some point in the future, would lead to = better overall behavior anyway). >=20 > MAR2: You haven't convinced me that coupled congestion control across = different hosts are in scope yet - because your own document at its = present version number does not address the entire scope of the problem. = Reasonable people can disagree. See you in Berlin. >=20 > Cheers, > Michael >=20 From Karen.Nielsen@tieto.com Mon Jul 22 03:03:00 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB32A21F848A for ; Mon, 22 Jul 2013 03:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDkUCXgSlTst for ; Mon, 22 Jul 2013 03:02:48 -0700 (PDT) Received: from ebb06.tieto.com (ebb06.tieto.com [131.207.168.38]) by ietfa.amsl.com (Postfix) with ESMTP id A2E6511E80A5 for ; Mon, 22 Jul 2013 03:00:14 -0700 (PDT) X-AuditID: 83cfa826-b7fc96d000004032-ed-51ed02a3c1d0 Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb06.tieto.com (SMTP Mailer) with SMTP id 91.A2.16434.3A20DE15; Mon, 22 Jul 2013 13:00:03 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.151]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Mon, 22 Jul 2013 13:00:03 +0300 From: To: Date: Mon, 22 Jul 2013 13:00:02 +0300 Thread-Topic: draft-ietf-tsvwg-sctp-failover: comments and suggestions Thread-Index: Ac6Bez4An5SHm6KwSeS+M9vXH4kz7gFOnM2w Message-ID: References: <51A360E7.7020209@ericsson.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: multipart/alternative; boundary="_000_CF340E42AED0874C81947E18863DE77B29DBD5C24EEXMB03eutieto_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJKsWRmVeSWpSXmKPExsXSfL5DS3cx09tAg+PfDSw+vN3HbLFxyQ02 i7t/tzFbHHtzl82BxePX16tsHkuW/GTyuPj6OrPHl8uf2QJYorhsUlJzMstSi/TtErgyfn4t KuieyVTxdc5OtgbGlW8Zuxg5OCQETCQeXNboYuQEMsUkLtxbz9bFyMUhJLCKUWL5g5VMEM4U RomWuV9YQKrYBOQl5u5dxQ5iiwjISPz98p8VxGYWyJCY+KaRBWQoi4CqxIpNYSBhYQFXie8P prFBlLtJvF01Gco2kthy8R7YSF4BH4nup3PYIXbtZ5Loe3oRbA6nQKBEy6EQkBpGoOO+n1rD BLFKXOLWk/lMEEcLSCzZc54ZwhaVePn4HytEvajEnfb1jBD1+RKzZ+6H2iUocXLmE5YJjKKz kIyahaRsFpIyiLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvoqRPzUpycBMryQztSRfLzk/ dxMjOBZXqO1gfPZA6hCjAAejEg9vY8CbQCHWxLLiytxDjJIcTEqivA//AoX4kvJTKjMSizPi i0pzUosPMUpwMCuJ8HquAsrxpiRWVqUW5cOkpDlYlMR5jdbfCxQSSE8sSc1OTS1ILYLJynBw KEnwbmV8GygkWJSanlqRlplTgpBm4uAEGc4DNLwNpIa3uCAxtzgzHSJ/ilGXY/LZLe8ZhVjy 8vNSpcR5d4EUCYAUZZTmwc2BpdBXjOJAbwnzXgCp4gGmX7hJr4CWMAEtMWx9DbKkJBEhJdXA 6HrTccl38b277FxYAngt7vlktWw/M/+FAJuX6vECSf4dJu77VOK3LPgmWNOo+ObrR/myqZlG m+JFyuT+ndgi3RrCGGorwqfhJcPv1mnXv1fqskGVhd3O39/ZNtyt7fH7Yiqd/Gjtbod71+4v yyuYk/DlCHdizBFl02V79pmt9AurnmWhGM+kxFKckWioxVxUnAgArsdk5nwDAAA= Cc: tsvwg@ietf.org, draft-ietf-tsvwg-sctp-failover@tools.ietf.org Subject: Re: [tsvwg] draft-ietf-tsvwg-sctp-failover: comments and suggestions X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 10:03:00 -0000 --_000_CF340E42AED0874C81947E18863DE77B29DBD5C24EEXMB03eutieto_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yoshifumi, Please find some follow up below. BR, Karen Please accept the following addition comments: The motivation for the 2MTU, I now understand, is to aim to mitigate unwant= ed effects of path bouncing resulting from a spurious T3-timeout followed by failover and subsequent "immediate" switchback operation of RFC4960 once HB ACK is acknowledged within the back-off'ed RTO. While I think that one can very well say in this document that the CWND cou= ld be set to 2MTU in case the first HB sent on a PF path is successfully ack'ed, then I would= like to note that this then is motivated by a desire, first and foremost, to be backward comp= atible with RC4960, more than it really necessarily addresses how to best mitigate throughput degradation ef= fects of spurious T3-timeouts. Indeed for implementations that operate with different switchback modes tha= n the immediate switchback operation of RFC4960, (e.g. operate with certain permanent failover modes), then the set of the = CWND to 2 MTU on the previous PF path is not of a big significance as it can be most optimal, from a performance = perspective, to stay on the new data carrying path, which at this point in time may have= a CWND of IW, IW+1MTU or even higher. I think that the motivation for setting the CWND to 2MTU possibly should be= made conditionally on whether the SCTP indeed follows the immediate switchback operation of RFC4960. One further observation is that in a situation where it is only the 2dn or = the 3rd (or 4th..) of the HBs sent on the PF path, that is successful, then setting the CWND to 2 MTU may actually constitute a decrease of the CWND. T= his is the case if the implementation follows RC4960 and raise the CWND to IW (4MTU) after an idle period of one = RTO following the T3 timeout. When in the text it is said that the CWND should be set to 1MTU at the stat= e transition from PF to ACTIVE does this then very explicitly addresses the fact that unsuccessful HBs, sent on a PF path, shall keep the= CWND down at 1MTU as otherwise data failures would ? If so then I think that it could be good to add this clarification. Ok. I see your point. I think we should explicitly say that we should set CWND to 1MTU after unsu= ccessful HBs. I don't think using 4MTU after seeing HB timeout is good approach. Thanks f= or pointing out. [Karen] I think that there could an issue here. On a data carrying path the= n the CWND is set to 1 MTU after a data T3 timeout. But on other paths, then I think that it could be unfortunate if a random l= oss of one HB (a periodic path monitoring HB) made the CWND be reduced to 1 MTU. I would opt for the set CWND to 1MTU after unsuccessful HBs to be performed= ONLY on a path in PF state, i.e., not for the HB that made the path enter = PF state nor for HBs done of Paths that are INACTIVE state, thereby one wou= ld make the CWND reductions be a little more robust towards random packet d= rops (of HBs). Alternatively one should do nothing special at all and keep the situation o= f RFC4960 where the fate of the HBs do not impact the CWND at all. Side note: A single drop of a data packet on a sparsely loaded path (or in = data tail - not enough data for Fast Recovery to kick in) today also result= s in CWND reduction and this of course compares with the loss of HB situati= on. But I think that this is a problem, rather than a desired effect, in th= e present algorithms that one continuously tries to find solutions for. We = should not make this problem worse by also introducing if for single drop o= f HBs. I think. Final thoughts: We have in real deployment experienced fault situations where HBs consisten= tly were able to get through on the primary path, but where the path broke due to congestion once it got loaded with data. Th= ere are different ways in which one can improve the protocol operation to best tackle such a situation. Our present solution, w= hich is to deploy a permanent failover mode together with PF and looking for a way to add reliability to the T3 timeouts, may not be the= ultimate way to solve this, but I would like to note that in such a situation then consistently returning to the primary path and set= ting CWND =3D 2MTU is not the right thing to do. >- Section 5.3: Permanent Failover > >We have good experiences from live networks with running SCTP in a "no >switchback" mode of operation with no automatic migration back to a prefer= red >primary path. Once the primary path is left due to it being potentially fa= iled, then a >selected alternative path automatically becomes the new primary path. > >This mode of operation corresponds to a simplified variant of the permanen= t >failover operation proposed in [CAR002] with alpha =3D beta =3D >SCTP_PEER_ADDR:THLDS. The mode of operation is run with notifications of >change of primary path being provided to upper layers via RFC6458 >SCTP_PEER_ADDR_CHANGE semantics (SCTP_ADDR_MADE_PRIM). > >The mode of operation does not suit all purposes, but in networks environm= ents >where a number of equally preferred paths are available, then by this mode= of >operation one minimizes the effects of unnecessary path bouncing and the t= hereby >associated effects of throughput degradation due to path changes and slow = start >operation. > >Based on our experiences we would recommend and support that the Permanent >Failover mode of operation, at least in the simple variant described above= , is >promoted as a valid alternative approach. For the purpose of activation of= this >mode of operation a switchback (or failover) mode operation parameter coul= d be >introduced as configurable by the introduction of an appropriate new read/= write >socket option in the Socket API. > > >Yes. I agree that there will be a situation where Permanent Failover work = effectively. >OTOH, supporting this prevents us from keeping RFC4960 behavior as RFC4960 >doesn't have this mode. >But, I believe this is a very interesting point and we would like to get m= ore feedback >in order to think about this more. > I understand to continue to support RFC4960 behaviour, but I suppose that o= ne can add to RFC4960 behaviour :-) We have the simple "no switchback mode" described above runni= ng in deployment. Yes, I think that's doable. I think the question here is the degree of reco= mmendation for this. The easiest one is just saying "An implementation MAY support no switchback= mode", but I'm gueesing some people might prefer more explicit expressions= . [Karen] Yes, I agree that better than MAY is desirable. But as a starting point then I think that a MAY support other switchback mo= des is much better than discouraging such, which is like I read the draft at present. >- Section 5.4: The impact of HB timeouts in association error counter > >The draft recommends for excluding HB timeouts from contributing to the >(association) error counter. We fully support this approach for all timeou= ts of HBs >that are send to probe the state of destinations addresses that are in PF = state and >we would even propose for the draft to demand that generally timeouts stem= ming >from HBs, which are not sent on the Primary Path, will be excluded from th= e >association error counter. > >Thereby the association error counter and thus the association fate reflec= ts the >forward progress of the data transmission to peer endpoint while at the sa= me time it >will be appropriately isolated from timeouts of HBs sent on non-data carry= ing paths. > >Allowing timeout of HBs sent on the Primary Path to impact the association= error >counter will serve to validate the aliveness of the peer endpoint when the= re is no >data in transit. > >This suggestion follows the thought expressed in http://www.ietf.org/mail- >archive/web/tsvwg/current/msg11294.html and it is thus believed to fulfil = the original >intend of RFC4960. > >This is a bit difficult point for me. I don't know much about the original= intention of >RFC4960, but if we follow what is written there, i think we need to increm= ent >association error count. (Please correct me if I misunderstand this point)= So, my >personal preference is to set bigger AMR to avoid early termination so tha= t we can >keep the RFC4960 behavior. >However, we don't mind discussing to update the logic described in 4960 fo= r more >sophisticated solution. > Thanks ! Yes, I concur that the text of section 8.1 of RFC4960 stipulates that all H= B Acks and HB timeouts influence the association error counter. But from the referenced discussion= thread, http://www.ietf.org/mail-archive/web/tsvwg/current/msg11294.html (simply = copying it in here to avoid repeating the arguments) it also seems that by purpose no keywords were used when writing these par= agraphs. Further as the Potentially Feature was not defined at the time, I am not su= re that it would be valid to say that the text of RFC4960 apply (at least) to the H= Bs sent as part of this function. >From our perspective what we would like to support and see happening is that all HBs, whether sent as part of the PF function or not, influence the= association error counter if and only if they are transmitted on the Primary Path (and then with stan= dard logic running making sure that all data transmissions prevent (or cancel in race conditions) any influence from HBs). Thereby the association error counter will be influenced by (and will thus = reflect) the data transmission only. Except in idle situation where HBs on Primary Path will serve to update the= association error counter in a similar manner as data would. Thereby one get a very clean and reliable implementation of the association= error counter. By reliable, I mean that one can use the same AMR value regardless of the level of HB probing that one have acti= vated and regardless of whether the Potentially Failed feature is activated= or not. Such an implementation also makes the AMR value be independent from the num= ber of paths supported in the association context. One can choose to use a value of AMR proportional with the number of paths = in order to have all paths be tried a number of times before association cl= osure, but with the choice suggested, one is not forced to "artificially" raise the AM= R value to make room for the HBs that will fire as part of the potentially = failed feature as well as for some fraction of the Path Monitoring HBs that can happen to fire dur= ing the same timeframe. An additional thought is that in the odd cases where HBs get through wherea= s data do not, then I think that it is contra-productive to have the associ= ation error counter be reset as long as data consistently fail. I, personally, does not so much like the suggestion to use a "maximal" or "= bigger" AMR. I think that it will be complex to deduce exactly what failure time (aka number of data retransmission) that a certain AMR v= alue will guarantee you, whereas when only data transmission influences the AMR, things will be clea= n, simple and predictable. I agree that the approach described in the draft is not the best approach. = But, since it doesn't violate RFC4960, we recommend it in the draft. I think what you suggest sounds reasonable and prefer to update 4960 based = on this, although I guess we'll need more discussions. [Karen] I agree, I will try to initiate such more general discussions. > >- Section 5.1 Thoughts on the destination address state machine > >In RFC4960 address state machine, notification of cease of use of the curr= ent >primary path as transmission path for new data is provided to upper layer = via >(coupled with) the announcement of the destination as being UNREACHABLE. W= ith >the introduction of the potentially failed state as a semi-hidden state (n= ot resulting in >notified state transition to UL) the information on the fail-over to use a= new data >carrying path is lost. >While there may be merits in suppressing notifications on potentially fail= ed >addresses, then we believe that it is unfortunate that the notification of= failover from >usage of the primary path for new data is lost. >This is especially problematic in path bouncing scenarios where the primar= y path is >unstable but still works some. E.g., HBs may go through, but the path brea= ks (data >transmission fails) as soon as it is more loaded. In such a situation no n= otifications >may be generated to UL, even if new data transmission consistently cycles = to and >from the primary path. The solution to such path bouncing scenarios will h= ave to >come from more advanced path failover mechanism, like [CAR002] (and would = not >be solved just by notification), but it would be a great help if appropria= te >notifications were provided. > >I think it will be OK to send notification as long as it's a new notificat= ion type. But >we should not send notifications defined in RFC6458. ok - I assume this is for backward compatible reasons. Yes. As far as I can think that's the reason. [Karen] Ok. >I guess having a new notification type won't cause problems, but I would l= ike to get >more feedback on this. Ok - we can come back with a suggestion. Thank you so much for many valuable feedback. We really appreciate! Regards, -- Yoshifumi --_000_CF340E42AED0874C81947E18863DE77B29DBD5C24EEXMB03eutieto_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yoshifum= i,

 <= /p>

Please find some follow up below.

 

BR, Karen

 

Ple= ase accept the following addition comments:

The motivation for the 2= MTU, I now understand, is to aim to mitigate unwanted effects of
path bo= uncing resulting from a spurious T3-timeout followed by failover
and sub= sequent "immediate" switchback operation of RFC4960 once HB ACKis acknowledged within the back-off'ed RTO.

While I think that one= can very well say in this document that the CWND could be set to 2MTU
i= n case the first HB sent on a PF path is successfully ack'ed, then I would = like to note that
this then is motivated by a desire, first and foremost= , to be backward compatible with RC4960, more than it
really necessarily= addresses how to best mitigate throughput degradation effects of spurious = T3-timeouts.
Indeed for implementations that operate with different swit= chback modes than the immediate switchback operation of RFC4960,
 (= e.g. operate with certain permanent failover modes), then the set of the CW= ND to 2 MTU on the previous PF path
is not of a big significance as it c= an be most optimal, from a performance perspective,
to stay on the new d= ata carrying path, which at this point in time may have a CWND of IW, IW+1M= TU or even higher.
I think that the motivation for setting the CWND to 2= MTU possibly should be made conditionally on whether the SCTP indeed follow= s
the immediate switchback operation of RFC4960.

One further obse= rvation is that in a situation where it is only the 2dn or the 3rd (or 4th.= .) of the HBs sent on the PF path, that is successful, then
setting the = CWND to 2 MTU may actually constitute a decrease of the CWND. This is the c= ase if the implementation
follows RC4960 and raise the CWND to IW (4MTU)= after an idle period of one RTO following the T3 timeout.
When in the t= ext it is said that the CWND should be set to 1MTU at the state transition = from PF to ACTIVE does this then very explicitly
addresses the fact that= unsuccessful HBs, sent on a PF path, shall keep the CWND down at 1MTU as o= therwise data failures would ?
If so then I think that it could be good = to add this clarification.

&nb= sp;

Ok. I see your point.

I think we should explicitly say that= we should set CWND to 1MTU after unsuccessful HBs.

I don't think using 4MTU after seeing HB timeout is= good approach. Thanks for pointing out.

 

[Karen] I think that there could an issue here.= On a data carrying path then the CWND is set to 1 MTU after a data T3 time= out.

But on= other paths, then I think that it could be unfortunate if a random loss of= one HB (a periodic path monitoring HB)

made the CWND be reduced to 1 MTU.

 

I would opt for the set CWND to 1MTU after unsuccessful HBs to be performed ONLY o= n a path in PF state, i.e., not for the HB that made the path enter PF stat= e nor for HBs done of Paths that are INACTIVE state, thereby one would make= the CWND reductions be a little more robust towards random packet drops (o= f HBs).

=  

Alternativel= y one should do nothing special at all and keep the situation of RFC4960 wh= ere the fate of the HBs do not impact the CWND at all.

 

Side note: A single drop of a data packet= on a sparsely loaded path (or in data tail - not enough data for Fast Reco= very to kick in) today also results in CWND reduction and this of course co= mpares with the loss of HB situation. But I think that this is a problem, r= ather than a desired effect, in the present algorithms that one continuousl= y tries to find solutions for. We should not make this problem worse by als= o introducing if for single drop of HBs. I think.

 


Final thoughts:

We have in real deployment experienced fault s= ituations where HBs consistently were able to get through on the primary pa= th,
but where the path broke due to congestion once it got loaded with d= ata. There are different ways in which one can improve the
protocol oper= ation to best tackle such a situation. Our present solution, which is to de= ploy a permanent failover mode together with PF
and looking for a way to= add reliability to the T3 timeouts, may not be the ultimate way to solve t= his, but I would like to note that
in such a situation then consistently= returning to the primary path and setting CWND =3D 2MTU is not the right t= hing to do.



>- Section 5.3: Permanent Failover
>
>W= e have good experiences from live networks with running SCTP in a "no<= br>>switchback" mode of operation with no automatic migration back = to a preferred
>primary path. Once the primary path is left due to it= being potentially failed, then a
>selected alternative path automati= cally becomes the new primary path.
>
>This mode of operation c= orresponds to a simplified variant of the permanent
>failover operati= on proposed in [CAR002] with alpha =3D beta =3D
>SCTP_PEER_ADDR:THLDS= . The mode of operation is run with notifications of
>change of prima= ry path being provided to upper layers via RFC6458
>SCTP_PEER_ADDR_CH= ANGE semantics (SCTP_ADDR_MADE_PRIM).
>
>The mode of operation = does not suit all purposes, but in networks environments
>where a num= ber of equally preferred paths are available, then by this mode of
>o= peration one minimizes the effects of unnecessary path bouncing and the the= reby
>associated effects of throughput degradation due to path change= s and slow start
>operation.
>
>Based on our experiences = we would recommend and support that the Permanent
>Failover mode of o= peration, at least in the simple variant described above, is
>promote= d as a valid alternative approach. For the purpose of activation of this>mode of operation a switchback (or failover) mode operation parameter = could be
>introduced as configurable by the introduction of an approp= riate new read/write
>socket option in the Socket API.
>
>= ;
>Yes. I agree that there will be a situation where Permanent Failov= er work effectively.
>OTOH, supporting this prevents us from kee= ping RFC4960 behavior as RFC4960
>doesn't have this mode.
>But,= I believe this is a very interesting point and we would like to get more f= eedback
>in order to think about this more.
>

I understand to continue to support RFC4960 b= ehaviour, but I suppose that one can add to RFC4960
behaviour :-) We hav= e the simple "no switchback mode" described above running in depl= oyment.

 

Yes, I think that's doable. I think = the question here is the degree of recommendation for this.

<= /div>

The easiest one is just saying "An impl= ementation MAY support no switchback mode", but I'm gueesing some peop= le might prefer more explicit expressions. 

<= p class=3DMsoNormal> <= /p>

[Karen] Yes, I agree that better than MA= Y is desirable.

But as a starting point then I think that a MAY support other switchback = modes is much better than discouraging such,

<= p class=3DMsoNormal>which is like I read the draft at present. <= o:p>

 


>- Sec= tion 5.4: The impact of HB timeouts in association error counter
>>The draft recommends for excluding HB timeouts from contributing to th= e
>(association) error counter. We fully support this approach for al= l timeouts of HBs
>that are send to probe the state of destinations a= ddresses that are in PF state and
>we would even propose for the draf= t to demand that generally timeouts stemming
>from HBs, which are not= sent on the Primary Path, will be excluded from the
>association err= or counter.
>
>Thereby the association error counter and thus t= he association fate reflects the
>forward progress of the data transm= ission to peer endpoint while at the same time it
>will be appropriat= ely isolated from timeouts of HBs sent on non-data carrying paths.
><= br>>Allowing timeout of HBs sent on the Primary Path to impact the assoc= iation error
>counter will serve to validate the aliveness of the pee= r endpoint when there is no
>data in transit.
>
>This sug= gestion follows the thought expressed in http://www.ietf.org/mail-
>archive/web/tsvw= g/current/msg11294.html and it is thus believed to fulfil the original
&= gt;intend of RFC4960.
>
>This is a bit difficult point for me. = I don't know much about the original intention of
>RFC4960, but if we= follow what is written there, i think we need to increment
>associat= ion error count. (Please correct me if I misunderstand this point) So, my>personal preference is to set bigger AMR to avoid early termination s= o that we can
>keep the RFC4960 behavior.
>However, we don't mi= nd discussing to update the logic described in 4960 for more
>sophist= icated solution.
>

Thanks !<= br>
Yes, I concur that the text of section 8.1 of RFC4960 stipulates tha= t all HB Acks and HB timeouts
influence the association error counter. B= ut from the referenced discussion thread,
 http= ://www.ietf.org/mail-archive/web/tsvwg/current/msg11294.html  (sim= ply copying it in here to avoid repeating the arguments)
 it also s= eems that by purpose no keywords were used when writing these paragraphs.Further as the Potentially Feature was not defined at the time, I am not = sure that
it would be valid to say that the text of RFC4960 apply (at le= ast) to the HBs sent as part of this function.

From our perspective = what we would like to support and see happening is
that all HBs, whether= sent as part of the PF function or not, influence the association error co= unter
if and only if they are transmitted on the Primary Path (and then = with standard logic running making sure that all data transmissions
prev= ent (or cancel in race conditions) any influence from HBs).

Thereby = the association error counter will be influenced by (and will thus reflect)= the data transmission only.
Except in idle situation where HBs on Prima= ry Path will serve to update the association error counter in a similar man= ner as data would.
Thereby one get a very clean and reliable implementat= ion of the association error counter. By reliable, I mean that one can use<= br>the same AMR value regardless of the level of HB probing that one have a= ctivated and regardless of whether the Potentially Failed feature is activa= ted or not.
Such an implementation also makes the AMR value be independe= nt from the number of paths supported in the association context.
One ca= n choose to use a value of AMR proportional with the number of paths in ord= er to have all paths be tried a number of times before association closure,= but
with the choice suggested, one is not forced to "artificially&= quot; raise the AMR value to make room for the HBs that will fire as part o= f the potentially failed feature as well
as for some fraction of the Pat= h Monitoring HBs that can happen to fire during the same timeframe.

= An additional thought is that in the odd cases where HBs get through wherea= s data do not, then I think that it is contra-productive to have the associ= ation error counter be reset
as long as data consistently fail.

I= , personally, does not so much like the suggestion to use a "maximal&q= uot; or "bigger" AMR. I think that it will be complex to deduce e= xactly
what failure time (aka number of data retransmission)  that = a certain AMR value will guarantee you,
whereas when only data transmiss= ion influences the AMR, things will be clean, simple and predictable.<= /o:p>

 

=

I agree that the approach described in the draft = is not the best approach. But, since it doesn't violate RFC4960, we recomme= nd it in the draft.

I think what you suggest sounds reasonable and prefer= to update 4960 based on this, although I guess we'll need more discussions= .

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F49= 7D'>[Karen] I agree, I will try to initiate such more general discussions.<= /span>

>
>- Section 5.1 Thoughts on the destination address state m= achine
>
>In RFC4960 address state machine, notification of cea= se of use of the current
>primary path as transmission path for new d= ata is provided to upper layer via
>(coupled with) the announcement o= f the destination as being UNREACHABLE. With
>the introduction of the= potentially failed state as a semi-hidden state (not resulting in
>n= otified state transition to UL) the information on the fail-over to use a n= ew data
>carrying path is lost.
>While there may be merits in s= uppressing notifications on potentially failed
>addresses, then we be= lieve that it is unfortunate that the notification of failover from
>= usage of the primary path for new data is lost.
>This is especially p= roblematic in path bouncing scenarios where the primary path is
>unst= able but still works some. E.g., HBs may go through, but the path breaks (d= ata
>transmission fails) as soon as it is more loaded. In such a situ= ation no notifications
>may be generated to UL, even if new data tran= smission consistently cycles to and
>from the primary path. The solut= ion to such path bouncing scenarios will have to
>come from more adva= nced path failover mechanism, like [CAR002] (and would not
>be solved= just by notification), but it would be a great help if appropriate
>= notifications were provided.
>
>I think it will be OK to send n= otification as long as it's a new notification type. But
>we should n= ot send notifications defined in RFC6458.

ok - I assume this is for backward compatible reasons.

 

Yes. As far as I can think that's the reason.=

[Karen] Ok.<= /o:p>

 

=

>I guess having a new notification typ= e won't cause problems, but I would like to get
>more feedback on thi= s.

Ok - we can come back with a su= ggestion.

 <= /o:p>

Thank you so much for many valuabl= e feedback. We really appreciate!

 

Regards,

--

Yoshifumi 

 

= --_000_CF340E42AED0874C81947E18863DE77B29DBD5C24EEXMB03eutieto_-- From hadi@mojatatu.com Fri Jul 12 11:15:25 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233A821E80AB for ; Fri, 12 Jul 2013 11:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.939 X-Spam-Level: X-Spam-Status: No, score=-102.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5mg4pZVkNZL for ; Fri, 12 Jul 2013 11:15:18 -0700 (PDT) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by ietfa.amsl.com (Postfix) with ESMTP id 7B85521E80A9 for ; Fri, 12 Jul 2013 11:15:18 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id pb11so8439986veb.23 for ; Fri, 12 Jul 2013 11:15:17 -0700 (PDT) X-Google-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:x-gm-message-state; bh=X6IL6lfyI2WQPhdppujvUsCaTuNdQ9yn7EVRq/U1RcQ=; b=nPBPfsvmrMwZ+nR9oDEqGbgiIaqErxs+FCxlTwXRl0vF6lQ3cehbRyxgmX4yZWWCR8 L5QdZ7tKt0JPUBh9E5S+wyHOhCE2iVIr+zko8X7YCjen1L1cwQwoUDN9RXT0fPatPEI/ XkGTLTOybDRAsguDzEZxYoA5fA+DSN/jyYJFxZACWay5hFp1toRRQetaYALMWjPkZKeT JFaRAOJ+5zQfZMp9+cgjhkqIejo4NVEDw9qR4bruuGCuTlbj+w/cuOMkPzvcijZM5Fy7 ulIl+X3lClvz3oc4vnFVhC75tflBWhv+5o9eSxdl8z+335ki5suGtaE1pah7mOnwCJVN dlkw== X-Received: by 10.220.42.147 with SMTP id s19mr25089998vce.46.1373652917841; Fri, 12 Jul 2013 11:15:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.247.197 with HTTP; Fri, 12 Jul 2013 11:14:57 -0700 (PDT) In-Reply-To: References: <27BA1FEC-AE84-412F-8D8A-4857FF283149@fh-muenster.de> From: Jamal Hadi Salim Date: Fri, 12 Jul 2013 14:14:57 -0400 Message-ID: To: Michael Tuexen Content-Type: multipart/alternative; boundary=047d7b3a8d0c367fea04e1547ea1 X-Gm-Message-State: ALoCoQmFzI62PafaCYuPKKZA4C9hMjXOqQOBxX8qpO+wklsrnbSvvSepBIwzY+E81R8/FKVTs+O+ X-Mailman-Approved-At: Mon, 22 Jul 2013 05:18:57 -0700 Cc: tsvwg , "robin.seggelmann" Subject: Re: [tsvwg] comments draft-tuexen-tsvwg-sctp-prpolicies-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 18:15:25 -0000 --047d7b3a8d0c367fea04e1547ea1 Content-Type: text/plain; charset=ISO-8859-1 Hi Michael, I think this addresses my earlier comments (and thanks for the responses on the other questions earlier). cheers, jamal On Fri, Jul 12, 2013 at 11:21 AM, Michael Tuexen wrote: > On Jul 10, 2013, at 11:48 AM, Jamal Hadi Salim wrote: > > > > > Hi Michael, > > > > On Wed, Jul 10, 2013 at 3:42 AM, Michael Tuexen > wrote: > > > > Assume the sender sends a user message which is approximately of size > 3*MTU. > > So SCTP will fragment it into 3 DATA chunk and send them. If the user > > has specified that the number of retransmissions is limited to 0 and > > the last fragment gets lost in the network, the sender will increment > > sprstat_abandoned_sent. > > > > Ok, so the last fragment essentially doesnt get acknowledged before we > > abandon ship. And the other stat indicates we abandoned while we still > had some > > sitting locally. Is the intersection of the two (some are sent but not > acked and > > some are still sitting locally) implying both stats will be incremented? > > > > Other than the perceived ambiguity - why do i care to know about the > > two types of abandoned messages in a user app? I will have to sum > > those two, so why not just give me one stat? > > > > BTW: the doc will benefit from such a small description as you gave me > > above. > The new revision contains some clarification: > http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-prpolicies-02 > > Best regards > Michael > > > > What will happen at the receiver side if you assume that the first two > > fragments have been received. If partial delivery was started, you will > > get a SCTP_PARTIAL_DELIVERY_EVENT event indicating > SCTP_PARTIAL_DELIVERY_ABORTED. > > Without partial delivery being started, the receiver could also drop the > > first part of the message. > > > > > > You answered the essence of my question. > > Silly follow up: I am assuming that event will come with an EOR? > > To use your example (at receiver): > > EPOLLIN, recvmsg chunk1, chunk2, EAGAIN > > EPOLLIN, recvmsg SCTP_PARTIAL_DELIVERY_EVENT, EOR > > > > cheers, > > jamal > > --047d7b3a8d0c367fea04e1547ea1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Michael,
I think this addresses my earlier comments= (and thanks for the responses on
the other questions earlier).

cheers,
jamal


On Fri, Jul 12, 2013 at 11:21 AM, Michae= l Tuexen <tuexen@fh-muenster.de> wrote:
On Jul 10, 2013, at 11:48 AM, Jamal Hadi Salim <hadi@mojatatu.com> wrote:

>
> Hi Michael,
>
> On Wed, Jul 10, 2013 at 3:42 AM, Michael Tuexen <tuexen@fh-muenster.de> wrote:
>
> Assume the sender sends a user message which is approximately of size = 3*MTU.
> So SCTP will fragment it into 3 DATA chunk and send them. If the user<= br> > has specified that the number of retransmissions is limited to 0 and > the last fragment gets lost in the network, the sender will increment<= br> > sprstat_abandoned_sent.
>
> Ok, =A0so the last fragment essentially doesnt get acknowledged before= we
> abandon ship. And the other stat indicates we abandoned while we still= had some
> sitting locally. Is the intersection of the two (some are sent but not= acked and
> some are still sitting locally) implying both stats will be incremente= d?
>
> Other than the perceived ambiguity - =A0why do i care to know about th= e
> two types of abandoned messages in a user app? I =A0will have to sum > those two, so why not just give me one stat?
>
> BTW: the doc will benefit from such a small description as you gave me=
> above.
The new revision contains some clarification:
http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-prpo= licies-02

Best regards
Michael
>
> What will happen at the receiver side if you assume that the first two=
> fragments have been received. If partial delivery was started, you wil= l
> get a SCTP_PARTIAL_DELIVERY_EVENT event indicating SCTP_PARTIAL_DELIVE= RY_ABORTED.
> Without partial delivery being started, the receiver could also drop t= he
> first part of the message.
>
>
> You answered the essence of my question.
> Silly follow up: I am assuming that event will come with an EOR?
> To use your example (at receiver):
> EPOLLIN, recvmsg chunk1, chunk2, EAGAIN
> EPOLLIN, recvmsg SCTP_PARTIAL_DELIVERY_EVENT, EOR
>
> cheers,
> jamal


--047d7b3a8d0c367fea04e1547ea1-- From gorry@erg.abdn.ac.uk Wed Jul 24 01:21:39 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE6311E83B2 for ; Wed, 24 Jul 2013 01:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLpwITSEvMlV for ; Wed, 24 Jul 2013 01:21:21 -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 1F20611E839C for ; Wed, 24 Jul 2013 01:21:07 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 87D1F2B44B4; Wed, 24 Jul 2013 09:21:03 +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 9CF1E2B4075 for ; Wed, 24 Jul 2013 09:21:02 +0100 (BST) Message-ID: <51EF8E6D.1090506@erg.abdn.ac.uk> Date: Wed, 24 Jul 2013 09:21: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:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tsvwg] TSVWG Final Agenda - Request for Speaker Slides! X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 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: Wed, 24 Jul 2013 08:21:39 -0000 We have now uploaded the final Agenda for the meeting on Monday: http://www.ietf.org/proceedings/87/agenda/agenda-87-tsvwg There are two TSVWG sessions, the second will include a group of drafts supporting transport functions that may be applicable to RMCAT. People intending to present should note that the allocated time is expected to include time for questions. You also must send the chairs slides by Sunday 17:00. NOTE 1 - Because we have a 9:00 start on Monday, you *DO* need to send copies of your slides in advance! NOTE 2 - We will need a minute-taker. In the past few meetings we used valuable meeting time to get volunteers, if some people volunteer in advance it would be appreciated by all! Gorry, David & James. From gorry@erg.abdn.ac.uk Thu Jul 25 05:31:03 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C7521F9AA7 for ; Thu, 25 Jul 2013 05:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bb5VdCj1kE5m for ; Thu, 25 Jul 2013 05:30:58 -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 9A32021F9966 for ; Thu, 25 Jul 2013 05:30:58 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 64D372B44B5; Thu, 25 Jul 2013 13:30:57 +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 F403B2B4250 for ; Thu, 25 Jul 2013 13:30:54 +0100 (BST) Message-ID: <51F11A7E.1090906@erg.abdn.ac.uk> Date: Thu, 25 Jul 2013 13:30:54 +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:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tsvwg] TSVWG Status report 25th July 2013 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jul 2013 12:31:03 -0000 The list below shows the status of the working group documents as we see it. Please check below and comment on drafts using the list. Please do send any corrections/omissions to the chairs. Best wishes, Gorry, David & James (TSVWG Chairs) June 2013 --- Recently published: draft-ietf-tsvwg-sctpsocket was published as RFC 6458. draft-ietf-tsvwg-sctp-strrst was published as RFC 6525. draft-ietf-tsvwg-source-quench was published as RFC 6633. draft-ietf-tsvwg-sctp-udp-encap was published as RFC 6951. ------------------------------------------------------------------- IDs in RFC Editor Queue: http://www.rfc-editor.org/queue.html None. ------------------------------------------------------------------- IDs in IESG processing: None. ------------------------------------------------------------------- WG Drafts with Chairs: draft-ietf-tsvwg-sctp-sack-immediately - Document Shepherd: Gorry Replaces: draft-tuexen-tsvwg-sctp-sack-immediately - WG adoption call after IETF-85, started 13/12/2013. Support {AB, IR, SL, MB, TD} - Implemented/released in FreeBSD, partially implemented in Linux WGLC concluded Friday 5th April 2013 - No major remaining comments at IETF-86, March 2013. {Supported in WGLC: TD; MW; DB; GF; YN; AB} - summary sent 8th April 2013 {Comments include: DB; YN; AB; MW} DUE: Authors to confirm draft is ready (Editor) DUE Authors to confirm IPR status (All) DUE: Write-up to be submitted (Gorry) ------------------------------------------------------------------- WG Drafts: --- draft-ietf-tsvwg-byte-pkt-congest - Document Shepherd: Gorry IETF-81: discussed whether this should be BCP. Status changed to BCP (new-ID WG -05) WGLC concluded with comments on I-D, Friday 30th March 2012. Draft version of write-up sent to list, comments received. - Gorry working with authors to clear list of WGLC questions (5 sept 2012). WG Chair received version that includes additional feedback during WGLC WGLC Completed (post IESG Review) ended Friday, 28th June 2013. STATUS: Awaiting revised-ID (subject to another WGLC) --- draft-ietf-tsvwg-rsvp-pcn - Document Shepherd: James Replaces: draft-karagiannis-pcn-tsvwg-rsvp-pcn AD decision allowed this to be added to the milestones Document adopted, status will be EXP (IETF-84 due to dependencies on PCN R RSVP-DIR review received (BB). MILESTONE EXPIRED. DUE: Expected ready for WGLC --- draft-ietf-tsvwg-natsupp-tsvwg - Document Shepherd: James Replaces: draft-stewart-natsupp-tsvwg Dependency from BEHAVE WG. Adopted as a work item 21 Sept 2010 (Gorry). WG -00, 29/11/2010 Uploaded as: draft-ietf-natsupp-tsvwg Authors restructured draft (-03) Added support for single and multi-homed support. IETF-86: 3 people in meeting had read -04 or -05. DUE: Authors please update following comments to TSVWG. DUE: Please comment on list - MILESTONE EXPIRED. --- draft-ietf-tsvwg-sctp-failover - Document Shepherd: James Replaces: draft-nishida-tsvwg-sctp-failover Individual-00 Presented in Prague, IETF-80. - Understood not to conflict with draft-tuexen-tsvwg-sctp-multipath - PF has been coded into FreeBSD Adopted by WG 26/6/2012. [Milestone: Jul 2013, EXP] DUE: Please comment on list. --- draft-ietf-tsvwg-sctp-dtls-encaps - Document Shepherd: Gorry Replaces: draft-tuexen-tsvwg-sctp-dtls-encaps-01 WG adopted 13/12/2013. Support {AB, IR, SL, MB, TD} [Milestone: Jan 2014, PS] Implemented in Firefox (FF21). Required by RTCweb. DUE: Please comment on list. --- draft-ietf-tsvwg-intserv-multiple-tspec - Document Shepherd: David WG interest in this topic recorded at IETF-78. Charter update needed to progress this work. 5 Reviews needed to determine energy/technical direction. WG -05 (presented in Beijing, IETF-79) WG -06 (presented in Prague, IETF-80) 2 reviews from RSVP-DIR received (Bruce Davie, ?) 2 additional reviews promised (Ken Carlberg, Francois LeF) Chairs asked AD for a Charter update (IESG agreed) Draft discussed at IETF-80, and request to update charter agreed - AD advised 4 named reviewers will be required Adopted for progression as PS, for May 2012 - New approach presented following WG comments, revised MILESTONE needed. DUE: Discussion needed on list. --- draft-ietf-tsvwg-port-use - Document Shepherd: Gorry Replaces: draft-touch-tsvwg-port-use-00 - Intended to be advice to protocol designers needing a port. 5 people looked at this document, Prague IETF-80 Individual -01 July 2011 IETF-81 insufficient feedback from WG at this time. IETF-82, discussed. Adopted by WG Presented IETF-86, March 2013 Milestone updated to June 2014 DUE: Please read individual sections and provide feedback! --- draft-ietf-tsvwg-rsvp-app-id-vv-profiles Replaces: draft-polk-tsvwg-rsvp-app-id-vv-profiles -01 Presented in Beijing, IETF-79. -02, 14-Mar-2011 Presented IETF-80. Seek to coordinate with music with partner ID: draft-polk-mmusic-traffic-class-for-sdp Gorry liaised with MMUSIC WG Chairs on companion draft (norm ref from this tsvwg draft). Adopted as a TSVWG work item, December 2013, [Milestone Jul 2013]. This will update a RFC 2872 (PS). Presented at IETF-86, Mar 2013 (no comments) DUE: Expected ready for WGLC; DUE: Reviewers are needed to prepare for a WGLC. ------------------------------------------------------------------- The following have received recent discussion at TSVWG meetings or on the list. Inclusion in the list below does not indicate support for these specific drafts and other contributions are also warmly welcomed. draft-geib-tsvwg-diffserv-intercon draft-yong-tsvwg-udp-encap-4-ip-tunneling draft-shepherd-multicast-udp-guidelines draft-turner-rsvp-auth-update draft-wei-tsvwg-tunnel-congestion-feedback draft-dhesikan-tsvwg-rtcweb-qos draft-polk-tsvwg-delay-vs-loss-ds-service-classes draft-stewart-tsvwg-sctp-ndata draft-tuexen-tsvwg-sctp-prpolicies draft-tuexen-tsvwg-sctp-scheduling For other drafts linked to tsvwg, please see: http://tools.ietf.org/wg/tsvwg/ From nishida@sfc.wide.ad.jp Fri Jul 26 00:11:48 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A4721F84D1 for ; Fri, 26 Jul 2013 00:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXX-M4yKfock for ; Fri, 26 Jul 2013 00:11:47 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 0285421F84B6 for ; Fri, 26 Jul 2013 00:11:45 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id D90DD27809A for ; Fri, 26 Jul 2013 16:11:43 +0900 (JST) Received: by mail-la0-f46.google.com with SMTP id es20so2091327lab.33 for ; Fri, 26 Jul 2013 00:11:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m+sMWtt/yyar7iMPPopbswaCM9GgSCQRat8WCWaSRW4=; b=W4pugKMu3ewDdjjjszvTqj0xLjms7D91tzAJ/hg9ETAL2n8zNa1+XMjsmkZKXfqkWl klcITggH/UQTz/mE7SHLD1ixTTTCRygM/+/a/lCWJq3g6s9xkbHF2yUo2EGnk81FymZB +af3GWJwFHCBSLfrGeGoLcVQCX+G7OjAm3oYoX971tAWsh7ioyJMKHyPl6cGgS1h6pUI oxsE5vmqchFZgvvNBqS2VmXaynL9QAooCPhWYUSen9Upp6TxmDzhvlk/2Gr0d9NFZXFL wqm+jq6642BV+BxRlU3pBU+vgu+rBKrFZgeu3fy+XifuyOVYfNcezO92K5GE4ZmX+iDi 6MOA== MIME-Version: 1.0 X-Received: by 10.152.18.202 with SMTP id y10mr20169379lad.80.1374822701228; Fri, 26 Jul 2013 00:11:41 -0700 (PDT) Received: by 10.114.92.238 with HTTP; Fri, 26 Jul 2013 00:11:41 -0700 (PDT) In-Reply-To: References: <51A360E7.7020209@ericsson.com> Date: Fri, 26 Jul 2013 00:11:41 -0700 Message-ID: From: Yoshifumi Nishida To: "Karen E. E. Nielsen" Content-Type: text/plain; charset=ISO-8859-1 Cc: tsvwg , draft-ietf-tsvwg-sctp-failover@tools.ietf.org Subject: Re: [tsvwg] draft-ietf-tsvwg-sctp-failover: comments and suggestions X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 07:11:48 -0000 Hi Karen, On Mon, Jul 22, 2013 at 3:00 AM, wrote: > I think we should explicitly say that we should set CWND to 1MTU after > unsuccessful HBs. > > I don't think using 4MTU after seeing HB timeout is good approach. Thanks > for pointing out. > > > [Karen] I think that there could an issue here. On a data carrying path then > the CWND is set to 1 MTU after a data T3 timeout. > > But on other paths, then I think that it could be unfortunate if a random > loss of one HB (a periodic path monitoring HB) > > made the CWND be reduced to 1 MTU. > > > > I would opt for the set CWND to 1MTU after unsuccessful HBs to be performed > ONLY on a path in PF state, i.e., not for the HB that made the path enter PF > state nor for HBs done of Paths that are INACTIVE state, thereby one would > make the CWND reductions be a little more robust towards random packet drops > (of HBs). > Alternatively one should do nothing special at all and keep the situation of > RFC4960 where the fate of the HBs do not impact the CWND at all. Agreed. I meant for only a path in PF status since PF only sends HBs a path in PF status. I think the behavior of HB timeout on a path in other states should follow 4960. > Alternatively one should do nothing special at all and keep the situation of > RFC4960 where the fate of the HBs do not impact the CWND at all. > > > > Side note: A single drop of a data packet on a sparsely loaded path (or in > data tail - not enough data for Fast Recovery to kick in) today also results > in CWND reduction and this of course compares with the loss of HB situation. > But I think that this is a problem, rather than a desired effect, in the > present algorithms that one continuously tries to find solutions for. We > should not make this problem worse by also introducing if for single drop of > HBs. I think. I also think we need something here as single drop of HB might not be an indication of severe congestion. I'm thinking that something like draft-ietf-tcpm-newcwv might need to be considered. Thanks, -- Yoshifumi From gorry@erg.abdn.ac.uk Fri Jul 26 01:05:49 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3263721F8F29 for ; Fri, 26 Jul 2013 01:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJi92-gm+KwH for ; Fri, 26 Jul 2013 01:05:44 -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 9A51C21F8947 for ; Fri, 26 Jul 2013 01:05:39 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 525082B44B5; Fri, 26 Jul 2013 09:05:35 +0100 (BST) Received: from Gorry.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 81AB62B41D5 for ; Fri, 26 Jul 2013 09:05:32 +0100 (BST) Message-ID: <51F22DCB.1090509@erg.abdn.ac.uk> Date: Fri, 26 Jul 2013 09:05:31 +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:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: tsvwg@ietf.org References: <51F22D49.9090106@erg.abdn.ac.uk> In-Reply-To: <51F22D49.9090106@erg.abdn.ac.uk> X-Forwarded-Message-Id: <51F22D49.9090106@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tsvwg] Fwd: Request for AD to progress draft-ietf-tsvwg-sctp-sack-immediately X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 08:05:49 -0000 TSVWG for your info: We have now submitted draft-ietf-tsvwg-sctp-sack-immediately for publication and I enclose a document write-up. Gorry -------- Original Message -------- TSV AD, IESG, TSVWG would like the above draft to be considered for publication as a PS. I enclose a document write-up. Gorry (TSVWG-Chair, Document Shepherd) *** copy of write-up for draft-ietf-tsvwg-sctp-sack-immediately *** As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document is intended as a PS. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document updates RFC 4960 by defining a method for the sender of a DATA chunk to indicate that the corresponding SACK chunk should be sent back immediately and not be delayed. It is done by specifying a bit in the DATA chunk header, called the I-bit, which can get set either by the SCTP implementation or by the application using an SCTP stack. Since unknown flags in chunk headers are ignored by SCTP implementations, this extension does not introduce any interoperability problems. Working Group Summary: There was consensus to adopt this as a WG document, review by the WG, and agreement by the WG to finally publish this. Document Quality: This document is seen as ready to publish. FreeBSD supports this extension since FreeBSD 7.2, released May 2009. The Linux kernel supports it also (accessibility by a the user was added recently to netinet/sctp.h). Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? I am the document shepherd, G Fairhurst, . The responsible AD is: Spencer Dawkins (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. WGLC Announcement sent draft-ietf-tsvwg-sctp-sack-immediately-02 on 19th March 2013 and concluded Friday 5th April 2013 with comments from 6 people provided. These have been addressed in the present version. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. As far as I know, no IPR disclosures have been submitted. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There was initial discussion of whether this mechanism was needed - especially since no equivalent method exists in TCP. After use-cases were provided there was strong support for this work and no objections. There was review of the work within the WG, and consensus to publish. No objections were noted. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. None. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. None. (13) Have all references within this document been identified as either normative or informative? Yes, this OK. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No external dependencies. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. Updates: 4960 - it is a backwards-compatible SCTP update. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). OK, normal SCTP allocation. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None. From zaheduzzaman.sarker@ericsson.com Fri Jul 26 07:16:02 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E6321F9994; Fri, 26 Jul 2013 07:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yc51ejAFUfFs; Fri, 26 Jul 2013 07:15:56 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0C54021F9993; Fri, 26 Jul 2013 07:15:55 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-53-51f2849a3412 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 5E.D1.00725.A9482F15; Fri, 26 Jul 2013 16:15:54 +0200 (CEST) Received: from [150.132.141.54] (153.88.183.146) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.2.328.9; Fri, 26 Jul 2013 16:15:53 +0200 Message-ID: <51F28499.7000604@ericsson.com> Date: Fri, 26 Jul 2013 16:15:53 +0200 From: Zaheduzzaman Sarker Organization: Ericsson AB User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Wesley Eddy References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> <51E6E1D5.1050006@mti-systems.com> In-Reply-To: <51E6E1D5.1050006@mti-systems.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUyM+Jvre6slk+BBjOfiVosbVKw2Lv8HpvF jjWFFu8/81u8eDCHyWL1zQ9sFsfe3GWzuP6d3YHDY8rvjaweS5b8ZPI4eaqXLYA5issmJTUn syy1SN8ugSuj5eEBpoKLLBWLPu9nb2C8x9zFyMkhIWAiMePQCRYIW0ziwr31bF2MXBxCAocZ JXY/+swO4axhlFh54zJYB6+AtsSjA1/YQWwWAVWJZ8d+sHYxcnCwCdhIPF7sBxLmF5CU2NCw G6xcVCBKorV3KlSroMTJmU/AlokAtS6cfIQFZD6zwBYmiY1LH7KCJIQF0iRW3J7ACGILCZxh lth7zx7E5hTQl9j8fR9YnFnAVuLCnOssELa8RPPW2cwgNwgJ6Ep0vYybwCg0C8m6WUg6ZiHp WMDIvIqRPTcxMye93HATIzDQD275rbuD8dQ5kUOM0hwsSuK8m/TOBAoJpCeWpGanphakFsUX leakFh9iZOLglGpgnH7zfcaZuuul6qfVS9/mMHEtM/d/59EoeiIsv2KDWDOj2y1ZTeekGwyB QbcCpxgvnBG8obJsq5W736vmVVIpM2t5P7F4/Iu6HPvxuamQLf/V2EfmnT8E3j27+i7g186O 06ZZSW8mXM9ROn7zXOG5uIVlHpUHz+Qnnuf+wuu7NnRCzx2JJ193KrEUZyQaajEXFScCAD+y 7ERCAgAA Cc: "tsvwg@ietf.org" , "Mo Zanaty \(mzanaty\)" , "rmcat@ietf.org" , "Michael Ramalho \(mramalho\)" , "James Polk \(jmpolk\)" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 14:16:02 -0000 On 2013-07-17 20:26, Wesley Eddy wrote: > It is not wise, in my opinion, to have algorithm-specific DSCPs. The > DSCPs need to indicate the desired forwarding behavior, and not what > version of code the end-host runs. +1 BR -- Zahed ================================================== ANM ZAHEDUZZAMAN SARKER Ericsson AB Multimedia Technologies Laboratoriegränd 11 97128 Luleå, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ================================================== From mramalho@cisco.com Fri Jul 26 08:08:31 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26ADC21F98AD; Fri, 26 Jul 2013 08:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u227fqnijrTu; Fri, 26 Jul 2013 08:08:23 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id EC3FA11E80F8; Fri, 26 Jul 2013 08:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2605; q=dns/txt; s=iport; t=1374851270; x=1376060870; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xUMO7IyGy6qEI3IsI7pYc6tBk7tomgElgYaIuXUdnoY=; b=KOmmv2DDyUiP6QaAxu97kwyLQDYTHg5fjSHCxTJOsgoV0gZyInbuQBhh 0zmocQQ1ykm8QfBr88qYGEJG5DTZiJMiSXrPOAqNsJn/MI6cGcOBfPEY9 n8ZCDwmdWQWEcDmJvbnAHtu/112fSdcWyXZkfLWWMan8MA8eTxXtFffVR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAHWP8lGtJXHA/2dsb2JhbABbgwY1UL1DgRgWdIIkAQEBBEkwDAICAgEIEQQBAQEKHQcbFxQIAQgCBAENBQiICLh3BI46gQ4xBwaDEG8DiHKgOYFbgTmBcTk X-IronPort-AV: E=Sophos;i="4.89,752,1367971200"; d="scan'208";a="239880752" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 26 Jul 2013 15:07:42 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6QF7feH030894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jul 2013 15:07:41 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.124]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Fri, 26 Jul 2013 10:07:41 -0500 From: "Michael Ramalho (mramalho)" To: Zaheduzzaman Sarker , Wesley Eddy Thread-Topic: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ Thread-Index: AQHOgpz4+m0uun89XEWA3y5OIxdfmJlphOaAgA3e94D//7eAIA== Date: Fri, 26 Jul 2013 15:07:41 +0000 Message-ID: References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> <51E6E1D5.1050006@mti-systems.com> <51F28499.7000604@ericsson.com> In-Reply-To: <51F28499.7000604@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.43.48] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tsvwg@ietf.org" , "Mo Zanaty \(mzanaty\)" , "rmcat@ietf.org" , "James Polk \(jmpolk\)" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 15:08:31 -0000 All, While I agree with Wes, we all need to ask the following question: What happens if the action of your congestion control CAUSES you not to hav= e the PHB you desire under congestion? I don't think we asked ourselves that question in this way before. Let me state it a different way. If you have AF4X traffic and your network = is traffic engineered such that ALL the endpoints putting stuff in AF4X is = guaranteed (in some sense via CAC or some other bandwidth management arrang= ement) to fit within the BW allowed for all the AF4X traffic ... then all i= s OK. That is how a lot of enterprise use of AF4X is designed. But what if the AF4X traffic comes from endpoints that do not have such a C= AC/BWM arrangement ... and the endpoints desiring AF4X PHB keep increasing = their rate until loss occurs. Well, if the AF4X queue is long enough, then = NONE of the AF4X traffic will have the desired PHB! That is the rub. The endpoints "want" a certain PHB ... but if there is a b= ottleneck at a point and the CC of the endpoints all adapt based on loss ..= . then the traffic won't get the PHB it desires (it will "self-congest" its= elf). So while I agree that we ought not to request a new DSCP per new CC protoco= l/algorithm ... we need to answer this question. [I know I will regret sending this email.] Michael Ramalho -----Original Message----- From: Zaheduzzaman Sarker [mailto:zaheduzzaman.sarker@ericsson.com]=20 Sent: Friday, July 26, 2013 10:16 AM To: Wesley Eddy Cc: Mo Zanaty (mzanaty); Toerless Eckert (eckert); tsvwg@ietf.org; rmcat@ie= tf.org; Michael Ramalho (mramalho); James Polk (jmpolk); Cheng-Jia Lai (che= lai) Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only r= ate-adaptive for DiffServ On 2013-07-17 20:26, Wesley Eddy wrote: > It is not wise, in my opinion, to have algorithm-specific DSCPs. The=20 > DSCPs need to indicate the desired forwarding behavior, and not what=20 > version of code the end-host runs. +1 BR --=20 Zahed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ANM ZAHEDUZZAMAN SARKER Ericsson AB Multimedia Technologies Laboratoriegr=E4nd 11 97128 Lule=E5, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From swb@internet2.edu Fri Jul 26 08:52:40 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C825A21F9994; Fri, 26 Jul 2013 08:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0Q2MhtjZKr9; Fri, 26 Jul 2013 08:52:31 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 00D9721F9983; Fri, 26 Jul 2013 08:52:27 -0700 (PDT) Received: from mail1-ch1-R.bigfish.com (10.43.68.228) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.22; Fri, 26 Jul 2013 15:52:27 +0000 Received: from mail1-ch1 (localhost [127.0.0.1]) by mail1-ch1-R.bigfish.com (Postfix) with ESMTP id 33EAD3E027D; Fri, 26 Jul 2013 15:52:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.241.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0810HT005.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -17 X-BigFish: S-17(zf7Izbb2dI98dI9371I936eI542I1432Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1de098h1033IL1de097hz2dh2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1f5fh1b1cn1b1bi1155h) Received: from mail1-ch1 (localhost.localdomain [127.0.0.1]) by mail1-ch1 (MessageSwitch) id 1374853944925237_21910; Fri, 26 Jul 2013 15:52:24 +0000 (UTC) Received: from CH1EHSMHS030.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail1-ch1.bigfish.com (Postfix) with ESMTP id CA40034004E; Fri, 26 Jul 2013 15:52:24 +0000 (UTC) Received: from BL2PRD0810HT005.namprd08.prod.outlook.com (157.56.241.101) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 26 Jul 2013 15:52:21 +0000 Received: from swbi2mbp.local (69.38.252.85) by pod51019.outlook.com (10.255.110.40) with Microsoft SMTP Server (TLS) id 14.16.329.3; Fri, 26 Jul 2013 15:52:18 +0000 Message-ID: <51F29B32.3010602@internet2.edu> Date: Fri, 26 Jul 2013 11:52:18 -0400 From: Scott Brim Organization: Internet2 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Michael Ramalho (mramalho)" References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> <51E6E1D5.1050006@mti-systems.com> <51F28499.7000604@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [69.38.252.85] X-OriginatorOrg: internet2.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "tsvwg@ietf.org" , "Mo Zanaty \(mzanaty\)" , "rmcat@ietf.org" , "James Polk \(jmpolk\)" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 15:52:41 -0000 The endpoints want a particular defined service or PDB. One part of delivering that is the per-hop behaviors. They can't deliver a service alone. Scott On 07/26/13 11:07, Michael Ramalho (mramalho) allegedly wrote: > All, > > While I agree with Wes, we all need to ask the following question: > > What happens if the action of your congestion control CAUSES you not to have the PHB you desire under congestion? > > I don't think we asked ourselves that question in this way before. > > Let me state it a different way. If you have AF4X traffic and your network is traffic engineered such that ALL the endpoints putting stuff in AF4X is guaranteed (in some sense via CAC or some other bandwidth management arrangement) to fit within the BW allowed for all the AF4X traffic ... then all is OK. That is how a lot of enterprise use of AF4X is designed. > > But what if the AF4X traffic comes from endpoints that do not have such a CAC/BWM arrangement ... and the endpoints desiring AF4X PHB keep increasing their rate until loss occurs. Well, if the AF4X queue is long enough, then NONE of the AF4X traffic will have the desired PHB! > > That is the rub. The endpoints "want" a certain PHB ... but if there is a bottleneck at a point and the CC of the endpoints all adapt based on loss ... then the traffic won't get the PHB it desires (it will "self-congest" itself). > > So while I agree that we ought not to request a new DSCP per new CC protocol/algorithm ... we need to answer this question. > > [I know I will regret sending this email.] > > Michael Ramalho > > -----Original Message----- > From: Zaheduzzaman Sarker [mailto:zaheduzzaman.sarker@ericsson.com] > Sent: Friday, July 26, 2013 10:16 AM > To: Wesley Eddy > Cc: Mo Zanaty (mzanaty); Toerless Eckert (eckert); tsvwg@ietf.org; rmcat@ietf.org; Michael Ramalho (mramalho); James Polk (jmpolk); Cheng-Jia Lai (chelai) > Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ > > > On 2013-07-17 20:26, Wesley Eddy wrote: >> It is not wise, in my opinion, to have algorithm-specific DSCPs. The >> DSCPs need to indicate the desired forwarding behavior, and not what >> version of code the end-host runs. > +1 > > BR > From brian.e.carpenter@gmail.com Fri Jul 26 13:54:41 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EBB11E8150; Fri, 26 Jul 2013 13:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.287 X-Spam-Level: X-Spam-Status: No, score=-102.287 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+1DO-qudLRq; Fri, 26 Jul 2013 13:54:37 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2060A11E815F; Fri, 26 Jul 2013 13:54:37 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id 10so3300531pdi.11 for ; Fri, 26 Jul 2013 13:54:36 -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=ipoTXUkgoPbzmsZrhgUq0LcYWqbexoPYq3YU8qN2x2Q=; b=TLTAQQgjv/VQ8bQFiooDVqDMKhrGYoaoyDQLQRG2n1s66ybfTa9OXVUq8zq7U3aog0 l2GNm+Fo4F0rh7LgoAUcbqqPglEULDrkKCLWlzPEDM0ZoDM3Lchan1LU1v0lz72LzC8q giv3LA9niPc1HMBCD02FUv/GkJ9LDavDaTHgRKQxHGxeSwlos/M3EXbU/VfUXubY0PZQ 8M5YwA5k2k7X5HOjoSI2x6uMzCdpUpQFAo5Efn17jAiWyYx6u9Qx/6+2p6fx/hrUT1NO XpSK2sUaJSTJy+CJtP9hoWqFGpdRpMlVQftVjwYR/x3zaBweYFZDPDA0pQiF3Nx7r4xc Pocw== X-Received: by 10.66.155.67 with SMTP id vu3mr57241555pab.42.1374872076008; Fri, 26 Jul 2013 13:54:36 -0700 (PDT) Received: from [192.168.178.23] (202.192.69.111.dynamic.snap.net.nz. [111.69.192.202]) by mx.google.com with ESMTPSA id ht5sm61908086pbb.29.2013.07.26.13.54.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Jul 2013 13:54:35 -0700 (PDT) Message-ID: <51F2E215.4000203@gmail.com> Date: Sat, 27 Jul 2013 08:54:45 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Scott Brim References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> <51E6E1D5.1050006@mti-systems.com> <51F28499.7000604@ericsson.com> <51F29B32.3010602@internet2.edu> In-Reply-To: <51F29B32.3010602@internet2.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "rmcat@ietf.org" , "James Polk \(jmpolk\)" , "Mo Zanaty \(mzanaty\)" , "Michael Ramalho \(mramalho\)" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 20:54:41 -0000 On 27/07/2013 03:52, Scott Brim wrote: > The endpoints want a particular defined service or PDB. One part of > delivering that is the per-hop behaviors. They can't deliver a service > alone. There are two aphorisms that apply here: 1. Queueing theory wins every time. 2. There is no such thing as free lunch. I'm not trying to be funny. As Michael observes, if there isn't enough capacity for the offered load, no queueing discipline can fix the problem. Well-designed PHBs can make things better for a fraction of the traffic, but only if there's a sufficient background of BE traffic to be dropped or delayed when necessary. And if you overload the AF4X queue at a given point, it will inevitably end up behaving like a BE queue. That's why the diffserv model includes the need for admission control. Brian > > Scott > > On 07/26/13 11:07, Michael Ramalho (mramalho) allegedly wrote: >> All, >> >> While I agree with Wes, we all need to ask the following question: >> >> What happens if the action of your congestion control CAUSES you not to have the PHB you desire under congestion? >> >> I don't think we asked ourselves that question in this way before. >> >> Let me state it a different way. If you have AF4X traffic and your network is traffic engineered such that ALL the endpoints putting stuff in AF4X is guaranteed (in some sense via CAC or some other bandwidth management arrangement) to fit within the BW allowed for all the AF4X traffic ... then all is OK. That is how a lot of enterprise use of AF4X is designed. >> >> But what if the AF4X traffic comes from endpoints that do not have such a CAC/BWM arrangement ... and the endpoints desiring AF4X PHB keep increasing their rate until loss occurs. Well, if the AF4X queue is long enough, then NONE of the AF4X traffic will have the desired PHB! >> >> That is the rub. The endpoints "want" a certain PHB ... but if there is a bottleneck at a point and the CC of the endpoints all adapt based on loss ... then the traffic won't get the PHB it desires (it will "self-congest" itself). >> >> So while I agree that we ought not to request a new DSCP per new CC protocol/algorithm ... we need to answer this question. >> >> [I know I will regret sending this email.] >> >> Michael Ramalho >> >> -----Original Message----- >> From: Zaheduzzaman Sarker [mailto:zaheduzzaman.sarker@ericsson.com] >> Sent: Friday, July 26, 2013 10:16 AM >> To: Wesley Eddy >> Cc: Mo Zanaty (mzanaty); Toerless Eckert (eckert); tsvwg@ietf.org; rmcat@ietf.org; Michael Ramalho (mramalho); James Polk (jmpolk); Cheng-Jia Lai (chelai) >> Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ >> >> >> On 2013-07-17 20:26, Wesley Eddy wrote: >>> It is not wise, in my opinion, to have algorithm-specific DSCPs. The >>> DSCPs need to indicate the desired forwarding behavior, and not what >>> version of code the end-host runs. >> +1 >> >> BR >> > > From michawe@ifi.uio.no Fri Jul 26 23:33:54 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C1111E81C4; Fri, 26 Jul 2013 23:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlYOjfXpF4tz; Fri, 26 Jul 2013 23:33:49 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 7361511E80AD; Fri, 26 Jul 2013 23:33:48 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1V2y4Y-0005I0-0c; Sat, 27 Jul 2013 08:33:46 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.103]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1V2y4X-0005Cw-I3; Sat, 27 Jul 2013 08:33:45 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Welzl In-Reply-To: <51F2E215.4000203@gmail.com> Date: Sat, 27 Jul 2013 08:33:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <312469BF-347D-4427-8636-51536549DAC4@ifi.uio.no> References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> <51E6E1D5.1050006@mti-systems.com> <51F28499.7000604@ericsson.com> <51F29B32.3010602@internet2.edu> <51F2E215.4000203@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1508) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 1 sum rcpts/h 8 sum msgs/h 1 total rcpts 6089 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 2DB309E1F200F41F298B94352EBABCB8BD7275E4 X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 3 max/h 1 blacklist 0 greylist 0 ratelimit 0 Cc: "tsvwg@ietf.org" , "Mo Zanaty \(mzanaty\)" , "rmcat@ietf.org" , "Michael Ramalho \(mramalho\)" , "James Polk \(jmpolk\)" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 06:33:54 -0000 On Jul 26, 2013, at 10:54 PM, Brian E Carpenter = wrote: [..] > That's why the diffserv model includes the need for admission control. +1, exactly my thinking when I read Michael Ramalho's message. So, with rtcweb planning to use DSCPs just because the application = decides to do so, rtcweb steps away from this usage of DiffServ, and yes = you get prioritization between classes, but any form of guarantees for = go out of the window. I always assumed that ISPs would protect DiffServ traffic that needs to = get a certain PHB by having their ingress routers scratch the DSCP for = all other traffic (e.g. everything that didn't do admission control). If = they don't, they better do now=85 and that would pretty much eliminate = the problem, I think: rtcweb would then get priorities applied between = its own flows wherever it can, and it won't harm anything that needs to = be protected - in such situations, the network just defaults to putting = all the rtcweb stuff in the same BE class, and not much harm is being = done, I think rtcweb was meant for the BE Internet from day 1 anyway. Problem solved? Cheers, Michael From swb@internet2.edu Sat Jul 27 06:31:19 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E2C21F9A29; Sat, 27 Jul 2013 06:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEQrIurtvJGV; Sat, 27 Jul 2013 06:31:13 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4D89921F99AE; Sat, 27 Jul 2013 06:31:04 -0700 (PDT) Received: from mail6-co9-R.bigfish.com (10.236.132.246) by CO9EHSOBE005.bigfish.com (10.236.130.68) with Microsoft SMTP Server id 14.1.225.22; Sat, 27 Jul 2013 13:31:03 +0000 Received: from mail6-co9 (localhost [127.0.0.1]) by mail6-co9-R.bigfish.com (Postfix) with ESMTP id 558DE1C0277; Sat, 27 Jul 2013 13:31:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.241.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0810HT001.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 7 X-BigFish: S7(zf7Izbb2dI98dIzz1f42h1d77h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzzz2dh2a8h668h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1f5fh1b1cn1b1bi1155h) Received: from mail6-co9 (localhost.localdomain [127.0.0.1]) by mail6-co9 (MessageSwitch) id 1374931860830448_20497; Sat, 27 Jul 2013 13:31:00 +0000 (UTC) Received: from CO9EHSMHS015.bigfish.com (unknown [10.236.132.246]) by mail6-co9.bigfish.com (Postfix) with ESMTP id C472D240031; Sat, 27 Jul 2013 13:31:00 +0000 (UTC) Received: from BL2PRD0810HT001.namprd08.prod.outlook.com (157.56.241.101) by CO9EHSMHS015.bigfish.com (10.236.130.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 27 Jul 2013 13:31:00 +0000 Received: from swbi2mbp.local (46.189.28.124) by pod51019.outlook.com (10.255.110.36) with Microsoft SMTP Server (TLS) id 14.16.341.1; Sat, 27 Jul 2013 13:30:59 +0000 Message-ID: <51F3CB90.6040202@internet2.edu> Date: Sat, 27 Jul 2013 15:30:56 +0200 From: Scott Brim Organization: Internet2 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> <51E6E1D5.1050006@mti-systems.com> <51F28499.7000604@ericsson.com> <51F29B32.3010602@internet2.edu> <51F2E215.4000203@gmail.com> <312469BF-347D-4427-8636-51536549DAC4@ifi.uio.no> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [46.189.28.124] X-OriginatorOrg: internet2.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "tsvwg@ietf.org" , Michael Welzl , "Mo Zanaty \(mzanaty\)" , "rmcat@ietf.org" , "Michael Ramalho \(mramalho\)" , "James Polk \(jmpolk\)" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 13:31:19 -0000 On 07/27/13 09:35, Kenneth Carlberg allegedly wrote: > well, be it right or wrong, industry long ago expanded the model so that > one can have a case of only the application deciding the code point I don't mind the application deciding the codepoint, but the app still needs to understand that the network will (should, anyway) do traffic conditioning, and have a plan for adapting to it. Scott (at the Pullman) From dave.taht@gmail.com Sat Jul 27 11:14:35 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9CB11E80ED; Sat, 27 Jul 2013 11:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrdT+QrEh-JY; Sat, 27 Jul 2013 11:14:33 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 86D6811E80DF; Sat, 27 Jul 2013 11:14:31 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id h1so10141895oag.33 for ; Sat, 27 Jul 2013 11:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cv0w83ZHeSRnEO1eFCi7ehxSdW6uxM4fh9zRR+atCC4=; b=OK0B+tDsNFmVU+js0VPHXrxg4oBFHm4rWjll7oOqN3hiHxdM2Nf+9YvePKOWTQ89wT 5cCPkv9bqJETr1xu7woogFvpBDp11NPSbyIMVyb/o9APqxMY/t+1nobqOPpCN/JTX5DQ KqqBMEcjFc2HKAY3F41DjgCt9Ibt8BrsWr/ooCrtBtGy5MZ0BiwYlpn1O4esbYLUzQzE OegMCI7i7GXeM8tMMN2v38laTczKAgci9rzaYmlmpAnFhcS2veazcZ/oRDV/qW5UfAIv avPifgrYcvIgvAs26VwarP0CjTkc/gv69i3jdM326fc8fUV4LWiu6vUFXRQCYfyr9M5g LXWA== MIME-Version: 1.0 X-Received: by 10.50.65.99 with SMTP id w3mr357634igs.37.1374948862947; Sat, 27 Jul 2013 11:14:22 -0700 (PDT) Received: by 10.64.62.106 with HTTP; Sat, 27 Jul 2013 11:14:22 -0700 (PDT) In-Reply-To: <312469BF-347D-4427-8636-51536549DAC4@ifi.uio.no> References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> <51E6E1D5.1050006@mti-systems.com> <51F28499.7000604@ericsson.com> <51F29B32.3010602@internet2.edu> <51F2E215.4000203@gmail.com> <312469BF-347D-4427-8636-51536549DAC4@ifi.uio.no> Date: Sat, 27 Jul 2013 11:14:22 -0700 Message-ID: From: Dave Taht To: Michael Welzl Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "tsvwg@ietf.org" , "Mo Zanaty \(mzanaty\)" , "rmcat@ietf.org" , "Michael Ramalho \(mramalho\)" , "James Polk \(jmpolk\)" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 18:14:35 -0000 On Fri, Jul 26, 2013 at 11:33 PM, Michael Welzl wrote: > > On Jul 26, 2013, at 10:54 PM, Brian E Carpenter wrote: > > [..] > >> That's why the diffserv model includes the need for admission control. > > +1, exactly my thinking when I read Michael Ramalho's message. > > So, with rtcweb planning to use DSCPs just because the application decide= s to do so, rtcweb steps away from this usage of DiffServ, and yes you get = prioritization between classes, but any form of guarantees for go out of th= e window. > > I always assumed that ISPs would protect DiffServ traffic that needs to g= et a certain PHB by having their ingress routers scratch the DSCP for all o= ther traffic (e.g. everything that didn't do admission control). If they do= n't, they better do now=85 What I observe is the only diffserv marking with e2e survivability on ipv4 is CS1. Everything else gets re-marked. IPv6 has thus far That said, there is a great deal of internal-to-site traffic that might benefit, and if the bottleneck gateway from that site is respecting some markings you have some hope in case of congestion to the outside. Where it might matter some more is on wifi, although the current (vs expected) results of 802.11e, at least on Linux, is dismal, without admission control. (aggregation works much better) Given that the only marking I see consistently respected is BE and BK, I can suggest a couple things for rtcweb - when an browser is running rtcweb it could try to open less flows than normal for other tasks, and it could also signal e2e intent by dropping the classification to CS1 on things like tabs loading in the background. >and that would pretty much eliminate the problem, I think: rtcweb would th= en get priorities applied between its own flows wherever it can, and it won= 't harm anything that needs to be protected - in such situations, the netwo= rk just defaults to putting all the rtcweb stuff in the same BE class, and = not much harm is being done, I think rtcweb was meant for the BE Internet f= rom day 1 anyway. One of the things I like very much about rtcweb is that traffic inside your own domain - a call from upstairs to downstairs - STAYS inside your own network, so IF CS4/CS5 classification is used, over wifi, you would see this traffic drop into the underused hardware wifi VI queue. Whether or not this would be a good thing would require some testing... > Cheers, > Michael > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From dave.taht@gmail.com Sat Jul 27 12:18:50 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21ED11E80EF; Sat, 27 Jul 2013 12:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7mddQz1OZlC; Sat, 27 Jul 2013 12:18:48 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id B4EA211E80DF; Sat, 27 Jul 2013 12:18:48 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id fb19so6612772obc.23 for ; Sat, 27 Jul 2013 12:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Ixn6d1tEGgOLKKYzKbP8GETSxydOdOkYaFlRyazqLaI=; b=kZ2cDZKSwMMCPACBcOjbhMjLc5qBPV8ODmgk5Qal7hrV+OPjKcywa4NEMf5VOgw462 Swemb72GghefXrJwcK7Occi16CfQxftDWexwMtqJyzo0oJqbC726vnY2NT1GmDXwR4nK jEslHYdwJif//4zg+5nQctJCr7DduGJwiaAnqHUmiQBp0hsvzqVQzm84LNEWidq8YXQJ Dyx5qC1dBUn81Sg4pTSWl0HYQTpDWUzc+qHQuTy6uT8kUgjPiR87oivfYLy5GGGlOiLV NgnI3QS+BSTXMA9CgZlOu4UyZjYzBaO7BTltGF3FR53E03PmJSE1C+SwDybNZ6yldnq0 J2zA== MIME-Version: 1.0 X-Received: by 10.50.70.34 with SMTP id j2mr374301igu.42.1374952728099; Sat, 27 Jul 2013 12:18:48 -0700 (PDT) Received: by 10.64.62.106 with HTTP; Sat, 27 Jul 2013 12:18:47 -0700 (PDT) In-Reply-To: References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> <51E6E1D5.1050006@mti-systems.com> <51F28499.7000604@ericsson.com> <51F29B32.3010602@internet2.edu> <51F2E215.4000203@gmail.com> <312469BF-347D-4427-8636-51536549DAC4@ifi.uio.no> Date: Sat, 27 Jul 2013 12:18:47 -0700 Message-ID: From: Dave Taht To: Michael Welzl Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "tsvwg@ietf.org" , "Mo Zanaty \(mzanaty\)" , "rmcat@ietf.org" , "Michael Ramalho \(mramalho\)" , "James Polk \(jmpolk\)" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 19:18:50 -0000 On Sat, Jul 27, 2013 at 11:14 AM, Dave Taht wrote: > On Fri, Jul 26, 2013 at 11:33 PM, Michael Welzl wrot= e: >> >> On Jul 26, 2013, at 10:54 PM, Brian E Carpenter wrote: >> >> [..] >> >>> That's why the diffserv model includes the need for admission control. >> >> +1, exactly my thinking when I read Michael Ramalho's message. >> >> So, with rtcweb planning to use DSCPs just because the application decid= es to do so, rtcweb steps away from this usage of DiffServ, and yes you get= prioritization between classes, but any form of guarantees for go out of t= he window. >> >> I always assumed that ISPs would protect DiffServ traffic that needs to = get a certain PHB by having their ingress routers scratch the DSCP for all = other traffic (e.g. everything that didn't do admission control). If they d= on't, they better do now=85 > > What I observe is the only diffserv marking with e2e survivability on > ipv4 is CS1. Everything else gets re-marked. IPv6 has thus far "escaped much of the same fate." Sorry, thinko. Some experiments with mosh on ipv4 set to AF42 by default showed a couple middleboxes that would drop such-marked packets after a few seconds, btw. So I'd argue that even attempting to use classification should be dynamic and fall back to BE in case of a failure of connectivity. JG recently posted a summary of our thinking about latency management in general which I hope could inform this debate somewhat: http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-t= raditional-aqm-is-not-enough/ > > That said, there is a great deal of internal-to-site traffic that > might benefit, and if the bottleneck gateway from that site is > respecting some markings you have some hope in case of congestion to > the outside. > > Where it might matter some more is on wifi, although the current (vs > expected) results of 802.11e, at least on Linux, is dismal, without > admission control. (aggregation works much better) > > Given that the only marking I see consistently respected is BE and BK, > I can suggest a couple things for rtcweb - when an browser is running > rtcweb it could try to open less flows than normal for other tasks, > and it could also signal e2e intent by dropping the classification to > CS1 on things like tabs loading in the background. > >>and that would pretty much eliminate the problem, I think: rtcweb would t= hen get priorities applied between its own flows wherever it can, and it wo= n't harm anything that needs to be protected - in such situations, the netw= ork just defaults to putting all the rtcweb stuff in the same BE class, and= not much harm is being done, I think rtcweb was meant for the BE Internet = from day 1 anyway. > > One of the things I like very much about rtcweb is that traffic inside > your own domain - a call from upstairs to downstairs - STAYS inside > your own network, so IF CS4/CS5 classification is used, over wifi, you > would see this traffic drop into the underused hardware wifi VI queue. > Whether or not this would be a good thing would require some > testing... > > >> Cheers, >> Michael >> > > > > -- > Dave T=E4ht > > Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscrib= e.html --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From brian.e.carpenter@gmail.com Sat Jul 27 13:44:09 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D9E11E80F7; Sat, 27 Jul 2013 13:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+XGNawVCfcx; Sat, 27 Jul 2013 13:44:08 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B104711E80F3; Sat, 27 Jul 2013 13:44:08 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id 3so3030972pdj.5 for ; Sat, 27 Jul 2013 13:44:08 -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=WMcE7nlw8d3cRCBOND7qhE7jIIB4huEQcjE5NFUTJ+E=; b=VXUTKMA7ffQ9T55fFbZcBfeICz2CGarFv5Njqy71AVZe0CmvxuDorREcqNrtmvmSoO p3n9wePW+9Px7wRKQZsCxOSnSonPamNf8cPzqrNXKWeOdXec/nU7OTeA3aqX9MaIEPIB sZFVJJXvX+KJB2wySg+e11LhSD0wXe658OP4GyAsPXHPpltMob1oVPuRmd/v4AsT92b6 A6Cln/4lmyqN9lKCXuyDDVo7zw3CUM7kJm9GxYuFSXVeVTKNyXg+bJFJSLRg0sgyPgqm Ikvay/IE6W0Uvv61QEMmXtYi+t/p61c1SeJhhPqkOkUNKOF+iv6IsuQUyvVAv5SKvknl UnYw== X-Received: by 10.68.190.133 with SMTP id gq5mr3069511pbc.167.1374957848390; Sat, 27 Jul 2013 13:44:08 -0700 (PDT) Received: from [192.168.178.23] (125.198.69.111.dynamic.snap.net.nz. [111.69.198.125]) by mx.google.com with ESMTPSA id qb15sm11290689pab.13.2013.07.27.13.44.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 27 Jul 2013 13:44:07 -0700 (PDT) Message-ID: <51F43123.8010101@gmail.com> Date: Sun, 28 Jul 2013 08:44:19 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Scott Brim References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com> <51E6E1D5.1050006@mti-systems.com> <51F28499.7000604@ericsson.com> <51F29B32.3010602@internet2.edu> <51F2E215.4000203@gmail.com> <312469BF-347D-4427-8636-51536549DAC4@ifi.uio.no> <51F3CB90.6040202@internet2.edu> In-Reply-To: <51F3CB90.6040202@internet2.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "tsvwg@ietf.org" , Michael Welzl , "Mo Zanaty \(mzanaty\)" , "rmcat@ietf.org" , "Michael Ramalho \(mramalho\)" , "James Polk \(jmpolk\)" Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 20:44:09 -0000 On 28/07/2013 01:30, Scott Brim wrote: > On 07/27/13 09:35, Kenneth Carlberg allegedly wrote: >> well, be it right or wrong, industry long ago expanded the model so that >> one can have a case of only the application deciding the code point > > I don't mind the application deciding the codepoint, but the app still > needs to understand that the network will (should, anyway) do traffic > conditioning, and have a plan for adapting to it. Indeed, and of course a classifier somewhere downstream can always override the code point set by the application, if the traffic exits the initial domain. Brian From david.black@emc.com Sun Jul 28 05:14:17 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59B321F9D12 for ; Sun, 28 Jul 2013 05:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wc77okobvh-6 for ; Sun, 28 Jul 2013 05:14:11 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 31EE121F9C6E for ; Sun, 28 Jul 2013 05:14:10 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6SCEAK0031521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 28 Jul 2013 08:14:10 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Sun, 28 Jul 2013 08:13:55 -0400 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6SCDtjL025913 for ; Sun, 28 Jul 2013 08:13:55 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub21.corp.emc.com ([128.222.70.133]) with mapi; Sun, 28 Jul 2013 08:13:55 -0400 From: "Black, David" To: "tsvwg@ietf.org" Date: Sun, 28 Jul 2013 08:13:52 -0400 Thread-Topic: Two problems with draft-geib-tsvwg-diffserv-intercon-03 Thread-Index: Ac6Li+q885reIzk8SCqTThlAJwSIdw== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712984AD589@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-EMM-MHVC: 1 Subject: [tsvwg] Two problems with draft-geib-tsvwg-diffserv-intercon-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 12:14:17 -0000 There are two items that I believe need to be corrected in draft-geib-tsvwg-diffserv-intercon-03 before it's reasonable to consider th= at draft for adoption as an official tsvwg WG draft. (1) The draft confuses the Class Selector Codepoints (see RFC 2474) with se= rvice classes (see RFC 4594). This paragraph in the introduction illustrates the problems which occur in numerous places in the draft: IP Precedence has been deprecated when DiffServ was standardised. It is common practice today however to copy the DSCPs Bits 0-2 (called Class Selector Codepoints in the following) into MPLS TC or Ethernet P-Bits. This is also reflected by the DiffServ codepoint definitions of AF and EF. The Class Selector Codepoints shouldn't be used for backward compatibility only. Class based PHBs may be applied in core network sections rather than then DSCP based PHBs.=20 a) The class selector codepoints are *not* DSCP bits 0-2, see RFC 2474. Th= e attempt to redefine that term in Section 2 is not acceptable. I realize that this draft is defining the class select*ion* codepoints in contrast to the class select*or* codepoints in RFC 2474, but I suspect that the latter were intended, and if not, those two terms are too close and easily confusable. b) The class selector codepoints are used for more than backwards compatibi= lity, see RFC 4594. c) "Class based PHBs" means Service Classes, see RFC 4594. PHBs are not "b= ased on codepoints" - see the specifications of EF and AF for examples or RFC 4594. (2) The discussion of CS6 and routing traffic at the end of Section 4 is problematic. This draft sets out to define 4 interconnect classes, and the= n effectively adds a fifth based on CS6, but is rather unclear about it, weak= ening the entire draft. I believe we've received enough input from the Routing Area on the importan= ce of CS6 for BGP at carrier interconnects that it needs to be dealt with dire= ctly in contrast to this draft's approach of admitting that it might be necessar= y to use CS6, but discouraging its use. I would also suggest revising the discussion about abstract classes at the = end of Section 2 and connecting it to RFC 4594's discussion of service classes = as much of this has already been covered there. 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 david.black@emc.com Sun Jul 28 05:58:12 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E0321F8F29; Sun, 28 Jul 2013 05:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeKrnovZc9qv; Sun, 28 Jul 2013 05:58:08 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 805FC21F84CD; Sun, 28 Jul 2013 05:58:04 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6SCveiQ011990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Jul 2013 08:57:45 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sun, 28 Jul 2013 08:57:31 -0400 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6SCvUP4002504; Sun, 28 Jul 2013 08:57:30 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Sun, 28 Jul 2013 08:57:30 -0400 From: "Black, David" To: "Shitanshu Shah (svshah)" , "idr@ietf.org" , "tsvwg@ietf.org" Date: Sun, 28 Jul 2013 08:57:29 -0400 Thread-Topic: I-D Action: draft-ietf-idr-sla-exchange-01.txt Thread-Index: AQHOc0Ki0np6g8+K9U6RkYxz8y4hCplJf5+AgDC8IgA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712984AD58B@MX15A.corp.emc.com> References: <20130627142833.21297.87327.idtracker@ietfa.amsl.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-EMM-MHVC: 1 Subject: Re: [tsvwg] I-D Action: draft-ietf-idr-sla-exchange-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 12:58:12 -0000 Shitanshu, The use of the IPFIX IANA registry and the TSpec are significant improvemen= ts. I noticed one more thing: The 0x07 =3D DROP_THRESHOLD Classifier Element value in a Traffic Class ap= pears to allow mixing of different types of drop thresholds. That seems like a b= ad idea, as I would expect most networks to be managed with a single primary t= ype of drop thresholds. I'd suggest one of two approaches: - Put the drop threshold type in the classifier element, and remove it from each drop-priority record. - Leave the type where it is, and state that mixing types SHOULD NOT be done, with a warning that inconsistent and unexpected behavior may result if types are mixed because the mappings between types may vary by network. Thanks, --David > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > Shitanshu Shah (svshah) > Sent: Thursday, June 27, 2013 10:37 AM > To: idr@ietf.org; tsvwg@ietf.org > Subject: [tsvwg] FW: I-D Action: draft-ietf-idr-sla-exchange-01.txt >=20 >=20 > Dear WG, >=20 > Following is a revised draft incorporating feed-back/comments from the > last IETF. >=20 > Notable changes from the last revision, > - use of IPFIX IANA registry for Classifier Elements > - use of Tspec for SLA rates > - L2_OVERHEAD attribute to allow SLA advertise L3, L2 or customized L2 > rates >=20 > Please provide comments, >=20 > Regards, > Shitanshu >=20 >=20 > On 6/27/13 7:28 AM, "internet-drafts@ietf.org" > wrote: >=20 > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > This draft is a work item of the Inter-Domain Routing Working Group of > >the IETF. > > > > Title : Inter-domain SLA Exchange > > Author(s) : Shitanshu Shah > > Keyur Patel > > Sandeep Bajaj > > Luis Tomotaki > > Mohamed Boucadair > > Filename : draft-ietf-idr-sla-exchange-01.txt > > Pages : 24 > > Date : 2013-06-27 > > > >Abstract: > > Network administrators typically provision QoS (Quality of Service) > > policies for their application traffic (such as voice, video) based > > on SLAs (Service Level Agreements) negotiated with their providers, > > and translate those SLAs to vendor specific configuration language. > > Both learning of SLA, either thru SLA documents or via some other > > out-of-band method, and translating them to vendor specific > > configuration language is a complex, many times manual, process and > > prone to errors. This document proposes an in-band method of SLA > > signaling which can help to simplify some of the complexities. > > > > This document defines an operational transitive attribute to signal > > SLA details in-band, across administrative boundaries (considered as > > Autonomous Systems (AS)), thus simplify and speed-up some of the > > complex provisioning tasks. > > > > Though the use case with the proposed attribute is explicitly defined > > in this document, purpose of this attribute is not limited to this > > use case only. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-ietf-idr-sla-exchange-01 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-sla-exchange-01 > > > > > >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 >=20 From gorry@erg.abdn.ac.uk Sun Jul 28 13:00:25 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43E821F9C6A for ; Sun, 28 Jul 2013 13:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bei-eajzfZ0o for ; Sun, 28 Jul 2013 13:00:21 -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 EBDDD21F9C2C for ; Sun, 28 Jul 2013 13:00:20 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 264262B4438; Sun, 28 Jul 2013 21:00:20 +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 539AC2B436A for ; Sun, 28 Jul 2013 21:00:18 +0100 (BST) Message-ID: <51F57851.8070601@erg.abdn.ac.uk> Date: Sun, 28 Jul 2013 22:00:17 +0200 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:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: tsvwg@ietf.org References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tsvwg] TSVWG Final Agenda - *FINAL* Request for Speaker Slides! X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 28 Jul 2013 20:00:25 -0000 There are still some presenters listed in the Agenda who have not yet sent us slides. Could you please send me any slides you wish to present asap? - If I don't receive slides by 7:00am tomorrow, I'll assume you do not need to present (some others will appreciate the extra time to discuss other drafts!) Gorry -------- Original Message -------- We have now uploaded the final Agenda for the meeting on Monday: http://www.ietf.org/proceedings/87/agenda/agenda-87-tsvwg There are two TSVWG sessions, the second will include a group of drafts supporting transport functions that may be applicable to RMCAT. People intending to present should note that the allocated time is expected to include time for questions. You also must send the chairs slides by Sunday 17:00. NOTE 1 - Because we have a 9:00 start on Monday, you *DO* need to send copies of your slides in advance! NOTE 2 - We will need a minute-taker. In the past few meetings we used valuable meeting time to get volunteers, if some people volunteer in advance it would be appreciated by all! Gorry, David & James. From brian.e.carpenter@gmail.com Sun Jul 28 13:07:27 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8722621F9E0B for ; Sun, 28 Jul 2013 13:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5e9yCFKjWO4Z for ; Sun, 28 Jul 2013 13:07:26 -0700 (PDT) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A8DDB21F9E02 for ; Sun, 28 Jul 2013 13:07:26 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id un1so3863201pbc.29 for ; Sun, 28 Jul 2013 13:07:26 -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=UrhqE2NGQXUMLWiETfUi6iyUsN1SLlbTCOnyWdrYvcA=; b=JY4Ger17R6rzHejzbH65y+L4KkTQtIloOOG91zqjwkMOJhI/yb+4zciLchR4apnFk0 y8CutTIavJpZmVhoyFGhlyg6XlQd31pNBv4Qz955fuzb2c5Rg7VPLzG869sExqbpWYWw NSKyjTNFFHYWJiXzEGssY3ubTEguvx6uOQZns0Fsr8VoW0YsQH/RV8qAW7VecTl69jiP pOORSNS0UQLjSx7tKH/zgm4sXZdnogZFhsn6hqi7myhetZzhEcYibSolPErMdihs7RHh ENCO2FviU1cqe5PWcwQL046OC7Os6YLet/2HZtkkaE7nVHUle3bIvIWJ/RBAXiX2UXCL AD4Q== X-Received: by 10.68.201.226 with SMTP id kd2mr63910674pbc.45.1375042045411; Sun, 28 Jul 2013 13:07:25 -0700 (PDT) Received: from [192.168.178.23] (62.194.69.111.dynamic.snap.net.nz. [111.69.194.62]) by mx.google.com with ESMTPSA id a5sm2174121pbw.4.2013.07.28.13.07.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Jul 2013 13:07:24 -0700 (PDT) Message-ID: <51F579F1.4030100@gmail.com> Date: Mon, 29 Jul 2013 08:07:13 +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: <8D3D17ACE214DC429325B2B98F3AE712984AD589@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712984AD589@MX15A.corp.emc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Two problems with draft-geib-tsvwg-diffserv-intercon-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 20:07:27 -0000 On 29/07/2013 00:13, Black, David wrote: > > > There are two items that I believe need to be corrected in > draft-geib-tsvwg-diffserv-intercon-03 before it's reasonable to consider that > draft for adoption as an official tsvwg WG draft. > > (1) The draft confuses the Class Selector Codepoints (see RFC 2474) with service > classes (see RFC 4594). This paragraph in the introduction illustrates the > problems which occur in numerous places in the draft: > > IP Precedence has been deprecated when DiffServ was standardised. It > is common practice today however to copy the DSCPs Bits 0-2 (called > Class Selector Codepoints in the following) into MPLS TC or Ethernet > P-Bits. This is also reflected by the DiffServ codepoint definitions > of AF and EF. It's a fact that the CS PHBs (with mandatory 6-bit DSCPs) and the EF and AF PHBs (with recommended 6-bit DSCPs) were artfully chosen such that if they were interpreted by a legacy router supporting 3-bit IP Precedence, something reasonable would happen. An unintended side-effect of that is that if bits 0-2 are mapped into a 3-bit priority field in another technology, something reasonable will happen. But *that's all*. It's a logical error to assert anything else. I fully agree with David's comments below. > The Class Selector Codepoints shouldn't be used for > backward compatibility only. Class based PHBs may be applied in core > network sections rather than then DSCP based PHBs. > > a) The class selector codepoints are *not* DSCP bits 0-2, see RFC 2474. The > attempt to redefine that term in Section 2 is not acceptable. I realize > that this draft is defining the class select*ion* codepoints in contrast > to the class select*or* codepoints in RFC 2474, but I suspect that the > latter were intended, and if not, those two terms are too close and > easily confusable. > b) The class selector codepoints are used for more than backwards compatibility, > see RFC 4594. > c) "Class based PHBs" means Service Classes, see RFC 4594. PHBs are not "based > on codepoints" - see the specifications of EF and AF for examples or > RFC 4594. > > (2) The discussion of CS6 and routing traffic at the end of Section 4 is > problematic. This draft sets out to define 4 interconnect classes, and then > effectively adds a fifth based on CS6, but is rather unclear about it, weakening > the entire draft. > > I believe we've received enough input from the Routing Area on the importance > of CS6 for BGP at carrier interconnects that it needs to be dealt with directly > in contrast to this draft's approach of admitting that it might be necessary > to use CS6, but discouraging its use. Absolutely. That's been true for 20+ years, too. Brian > > > > > > I would also suggest revising the discussion about abstract classes at the end > of Section 2 and connecting it to RFC 4594's discussion of service classes as > much of this has already been covered there. > > > > 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 Karen.Nielsen@tieto.com Sun Jul 28 23:08:03 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE33421F918F for ; Sun, 28 Jul 2013 23:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gOOJEPkBczJ for ; Sun, 28 Jul 2013 23:07:58 -0700 (PDT) Received: from ebb05.tieto.com (ebb05.tieto.com [131.207.168.36]) by ietfa.amsl.com (Postfix) with ESMTP id 70ACF21F9F77 for ; Sun, 28 Jul 2013 23:07:57 -0700 (PDT) X-AuditID: 83cfa824-b7f718e000000f53-c2-51f606bcbdd6 Received: from FIHGA-EXHUB01.eu.tieto.com ( [131.207.136.34]) by ebb05.tieto.com (SMTP Mailer) with SMTP id EC.12.03923.CB606F15; Mon, 29 Jul 2013 09:07:56 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.151]) by FIHGA-EXHUB01.eu.tieto.com ([131.207.136.34]) with mapi; Mon, 29 Jul 2013 09:07:55 +0300 From: To: Date: Mon, 29 Jul 2013 09:07:54 +0300 Thread-Topic: draft-ietf-tsvwg-sctp-failover: comments and suggestions Thread-Index: Ac6MIfS3gAQpUOFBThaD+MVfP6XZkg== Message-ID: 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-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJKsWRmVeSWpSXmKPExsXSfL5DSXcP27dAg61v+Cw+vN3HbLFxyQ02 i7t/tzFbHHtzl82BxePX16tsHkuW/GTyuPj6OrPHl8uf2QJYorhsUlJzMstSi/TtErgy7s39 z1bQx12x7dhZ9gbGpxxdjJwcEgImEjtnP2WCsMUkLtxbz9bFyMUhJLCKUeLStsUsEM4URome /kOMIFVsAvISc/euYgexRQRkJP5++c8KYjMLZEhMfNPIAmKzCKhKbFl2EiwuLOAq8f3BNDaI ejeJt6smA9kcQLaexKK1diBhXgEfifU3doGNZwQ64vupNUwQI8Ulbj2ZD3WcgMSSPeeZIWxR iZeP/7FC1ItK3GlfzwhRryOxYPcnNghbW2LZwtfMEPMFJU7OfMIygVFkFpKxs5C0zELSMgtJ ywJGllWM/KlJSQameiWZqSX5esn5uZsYwbGyQmUH49kHUocYBTgYlXh4LVy/BAqxJpYVV+Ye YpTkYFIS5X3P8i1QiC8pP6UyI7E4I76oNCe1+BCjBAezkggvh9HXQCHelMTKqtSifJiUNAeL kjiv4fp7gUIC6YklqdmpqQWpRTBZGQ4OJQleLWBKEBIsSk1PrUjLzClBSDNxcIIM5wEafpUV qIa3uCAxtzgzHSJ/ilGXY/LZLe8ZhVjy8vNSpcR5dUAGCYAUZZTmwc2BpbhXjOJAbwnzCoFU 8QDTI9ykV0BLmICWbNr5CWRJSSJCSqqBsenP2cjFqzzVHyx6JXR4ub40y+4+/annTwjJd/m6 sot80K7TnFnP5Mb50CJB9tbUCRO1Jap7KmZY8vzU19myJ23v/4J712I/zvdj5epbY2+hZhqV NOWW1+4Wr4g3js1XYvn2PJ6/rWXf6dslOZdfJiXZeV9+NaX/Znk67+/slp7gq8tXb9ylq8RS nJFoqMVcVJwIAC0tbdZMAwAA Cc: tsvwg@ietf.org, draft-ietf-tsvwg-sctp-failover@tools.ietf.org Subject: Re: [tsvwg] draft-ietf-tsvwg-sctp-failover: comments and suggestions X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 06:08:04 -0000 >> Side note: A single drop of a data packet on a sparsely loaded path >> (or in data tail - not enough data for Fast Recovery to kick in) today >> also results in CWND reduction and this of course compares with the loss= of HB >situation. >> But I think that this is a problem, rather than a desired effect, in >> the present algorithms that one continuously tries to find solutions >> for. We should not make this problem worse by also introducing if for >> single drop of HBs. I think. > >I also think we need something here as single drop of HB might not be an i= ndication >of severe congestion. >I'm thinking that something like draft-ietf-tcpm-newcwv might need to be >considered. > Yes, I think that it is relevant to consider to complement or replace the e= xponential decay of the=20 CWND of SCTP with the mechanisms of draft-ietf-tcmp-newcwv. However, I see = this as a more general issue. The problem space here, I believe, is more in the area of F_RTO, TPL and al= ikes. Namely to avoid "unnecessary" T3-timeouts and resulting undesirable effects= in terms of drastic CWND reduction and, for SCTP, path failover. For now, in this draft, still the best may simply be to stick with RFC4960 = operation and do nothing special with the CWND in the PF state. Then more advanced handling in PF states could co= me in a follow up ? Thanks, Karen >Thanks, >-- >Yoshifumi From internet-drafts@ietf.org Mon Jul 29 05:27:39 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1776A21F9BFF; Mon, 29 Jul 2013 05:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkZWWxYNljpu; Mon, 29 Jul 2013 05:27:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC03421F9E43; Mon, 29 Jul 2013 05:27:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130729122711.17008.34873.idtracker@ietfa.amsl.com> Date: Mon, 29 Jul 2013 05:27:11 -0700 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-pcn-06.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 12:27:40 -0000 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 Grou= p of the IETF. Title : Generic Aggregation of Resource ReSerVation Protocol (RS= VP) for IPv4 And IPv6 Reservations over PCN domains Author(s) : Georgios Karagiannis Anurag Bhargava Filename : draft-ietf-tsvwg-rsvp-pcn-06.txt Pages : 27 Date : 2013-07-29 Abstract: This document specifies extensions to Generic Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- Congestion Notification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-pcn-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rsvp-pcn-06 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 karagian@cs.utwente.nl Mon Jul 29 05:36:22 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1341121F9E3A for ; Mon, 29 Jul 2013 05:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usOzEzBWUQBO for ; Mon, 29 Jul 2013 05:36:16 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6468821F9C05 for ; Mon, 29 Jul 2013 05:34:56 -0700 (PDT) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 29 Jul 2013 14:34:50 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.13]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0328.009; Mon, 29 Jul 2013 14:34:48 +0200 From: To: Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-pcn-06.txt Thread-Index: AQHOjFcKfW/uxwAbtU2H4zRDrEeyVJl7loD8gAAA5I0= Date: Mon, 29 Jul 2013 12:34:47 +0000 Message-ID: References: <20130729122711.17008.34873.idtracker@ietfa.amsl.com> In-Reply-To: <20130729122711.17008.34873.idtracker@ietfa.amsl.com> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [130.129.22.47] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3BAA17EXMBX23adutwent_" MIME-Version: 1.0 Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-pcn-06.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 12:36:22 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3BAA17EXMBX23adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, After working out the comments of Bob we have just submitted v06, see below= ! In order to see the differences between v05 and v06, please see: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rsvp-pcn-06 Best regards, Georgios ________________________________ Van: tsvwg-bounces@ietf.org [tsvwg-bounces@ietf.org] namens internet-drafts= @ietf.org [internet-drafts@ietf.org] Verzonden: maandag 29 juli 2013 14:27 To: i-d-announce@ietf.org Cc: tsvwg@ietf.org Onderwerp: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-pcn-06.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 Grou= p of the IETF. Title : Generic Aggregation of Resource ReSerVation Proto= col (RSVP) for IPv4 And IPv6 Reservations over PCN domains Author(s) : Georgios Karagiannis Anurag Bhargava Filename : draft-ietf-tsvwg-rsvp-pcn-06.txt Pages : 27 Date : 2013-07-29 Abstract: This document specifies extensions to Generic Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- Congestion Notification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-pcn-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rsvp-pcn-06 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_FF1A9612A94D5C4A81ED7DE1039AB80F4F3BAA17EXMBX23adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi all,

 

After working out the comments of Bob we have just submitted v06, see be= low!

 

In order to see the differences between v05 and v06, please see:

http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-r= svp-pcn-06

 

Best regards,

Georgios 

Van: tsvwg-bounces@ietf.org [tsvwg-bounces@ietf.org] namens inte= rnet-drafts@ietf.org [internet-drafts@ietf.org]
Verzonden: maandag 29 juli 2013 14:27
To: i-d-announce@ietf.org
Cc: tsvwg@ietf.org
Onderwerp: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-pcn-06.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= Group of the IETF.

        Title    &nb= sp;      : Generic Aggregation of Resource ReSerVa= tion Protocol (RSVP) for IPv4 And IPv6 Reservations over PCN domains
        Author(s)    = ;   : Georgios Karagiannis
            &nb= sp;            = Anurag Bhargava
        Filename    =     : draft-ietf-tsvwg-rsvp-pcn-06.txt
        Pages    &nb= sp;      : 27
        Date    &nbs= p;       : 2013-07-29

Abstract:
   This document specifies extensions to Generic Aggregated RSVP<= br>    [RFC4860] for support of the PCN Controlled Load (CL) and Sing= le
   Marking (SM) edge behaviors over a Diffserv cloud using Pre-    Congestion Notification.





The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-pcn-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rsvp= -pcn-06


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_FF1A9612A94D5C4A81ED7DE1039AB80F4F3BAA17EXMBX23adutwent_-- From svshah@cisco.com Mon Jul 29 07:23:34 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B1711E80D7; Mon, 29 Jul 2013 07:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcN3pQ4g5i7h; Mon, 29 Jul 2013 07:23:26 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 471D321F9EA7; Mon, 29 Jul 2013 07:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4698; q=dns/txt; s=iport; t=1375107806; x=1376317406; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=KUy0tsBbTaT1T7ln9JcIZNr8PwVGuGN522gp+MGMmVE=; b=Ak16M3L3fvgx4/uQixDdynyl+0QvyHPAgPAYkfxJeOOom9G0Kyew/7R1 bm/xtcIrNcrz4f905vGMVMUK6AZGy/PAFb45rCUbvx55vSKpvuLCI5HQE VGDXBzlnhmQefTUOfCzCmuSgw02vggktSXJFZyMQ4tR83P6+Q64bZZs0l 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFABd69lGtJXHB/2dsb2JhbABbgwY1Sga9WIEXFnSCJAEBAQQBAQE3MwEXBgEIEQQBAQEKFAkuCxQJCAIEARIIAYgHBwW4HI5IgQQzBQaDEm8DmQiLAIUjgxSBaEI X-IronPort-AV: E=Sophos;i="4.89,769,1367971200"; d="scan'208";a="240824634" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 29 Jul 2013 14:23:24 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6TENOxl013104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jul 2013 14:23:24 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.98]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Mon, 29 Jul 2013 09:23:24 -0500 From: "Shitanshu Shah (svshah)" To: "Black, David" , "idr@ietf.org" , "tsvwg@ietf.org" Thread-Topic: I-D Action: draft-ietf-idr-sla-exchange-01.txt Thread-Index: AQHOc0Ki0np6g8+K9U6RkYxz8y4hCplJf5+AgDC8IgCAAYqMAA== Date: Mon, 29 Jul 2013 14:23:23 +0000 Message-ID: In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712984AD58B@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.21.148.123] Content-Type: text/plain; charset="us-ascii" Content-ID: <32509D7901595B4490A6EE0990677433@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tsvwg] I-D Action: draft-ietf-idr-sla-exchange-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 14:23:35 -0000 Thank you David for your review and comments.. Regarding drop thresholds, indeed intention is to provide a facility to take multiple (type-value, burst) pairs but for a single primary type. Agreed, current definition in the draft is loose to interpret eligible use of multiple types for drop thresholds. I'll modify the structure for drop thresholds to take type definition once with multiple (type-value, burst) pairs. Regards, Shitanshu On 7/28/13 5:57 AM, "Black, David" wrote: > >Shitanshu, > >The use of the IPFIX IANA registry and the TSpec are significant >improvements. > >I noticed one more thing: > >The 0x07 =3D DROP_THRESHOLD Classifier Element value in a Traffic Class >appears >to allow mixing of different types of drop thresholds. That seems like a >bad >idea, as I would expect most networks to be managed with a single primary >type >of drop thresholds. I'd suggest one of two approaches: > > - Put the drop threshold type in the classifier element, and remove it > from each drop-priority record. > - Leave the type where it is, and state that mixing types SHOULD NOT be > done, with a warning that inconsistent and unexpected behavior > may result if types are mixed because the mappings between types > may vary by network. > >Thanks, >--David > > >> -----Original Message----- >> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf >>Of >> Shitanshu Shah (svshah) >> Sent: Thursday, June 27, 2013 10:37 AM >> To: idr@ietf.org; tsvwg@ietf.org >> Subject: [tsvwg] FW: I-D Action: draft-ietf-idr-sla-exchange-01.txt >>=20 >>=20 >> Dear WG, >>=20 >> Following is a revised draft incorporating feed-back/comments from the >> last IETF. >>=20 >> Notable changes from the last revision, >> - use of IPFIX IANA registry for Classifier Elements >> - use of Tspec for SLA rates >> - L2_OVERHEAD attribute to allow SLA advertise L3, L2 or customized L2 >> rates >>=20 >> Please provide comments, >>=20 >> Regards, >> Shitanshu >>=20 >>=20 >> On 6/27/13 7:28 AM, "internet-drafts@ietf.org" >> >> wrote: >>=20 >> > >> >A New Internet-Draft is available from the on-line Internet-Drafts >> >directories. >> > This draft is a work item of the Inter-Domain Routing Working Group of >> >the IETF. >> > >> > Title : Inter-domain SLA Exchange >> > Author(s) : Shitanshu Shah >> > Keyur Patel >> > Sandeep Bajaj >> > Luis Tomotaki >> > Mohamed Boucadair >> > Filename : draft-ietf-idr-sla-exchange-01.txt >> > Pages : 24 >> > Date : 2013-06-27 >> > >> >Abstract: >> > Network administrators typically provision QoS (Quality of Service) >> > policies for their application traffic (such as voice, video) based >> > on SLAs (Service Level Agreements) negotiated with their providers, >> > and translate those SLAs to vendor specific configuration language. >> > Both learning of SLA, either thru SLA documents or via some other >> > out-of-band method, and translating them to vendor specific >> > configuration language is a complex, many times manual, process and >> > prone to errors. This document proposes an in-band method of SLA >> > signaling which can help to simplify some of the complexities. >> > >> > This document defines an operational transitive attribute to signal >> > SLA details in-band, across administrative boundaries (considered as >> > Autonomous Systems (AS)), thus simplify and speed-up some of the >> > complex provisioning tasks. >> > >> > Though the use case with the proposed attribute is explicitly >>defined >> > in this document, purpose of this attribute is not limited to this >> > use case only. >> > >> > >> >The IETF datatracker status page for this draft is: >> >https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange >> > >> >There's also a htmlized version available at: >> >http://tools.ietf.org/html/draft-ietf-idr-sla-exchange-01 >> > >> >A diff from the previous version is available at: >> >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-sla-exchange-01 >> > >> > >> >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 >>=20 > From bob.briscoe@bt.com Mon Jul 29 10:37:53 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1972721F9956 for ; Mon, 29 Jul 2013 10:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[AWL=-0.641, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYiifMvy0-ah for ; Mon, 29 Jul 2013 10:37:46 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 7900B21F99FA for ; Mon, 29 Jul 2013 10:37:02 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 29 Jul 2013 18:36:57 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 29 Jul 2013 18:36:58 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.342.3; Mon, 29 Jul 2013 18:36:58 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.108.36]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6THasV4009963; Mon, 29 Jul 2013 18:36:55 +0100 Message-ID: <201307291736.r6THasV4009963@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 29 Jul 2013 18:36:53 +0100 To: "Black, David" , "gorry@erg.abdn.ac.uk" From: Bob Briscoe In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712984AD623@MX15A.corp.emc.co m> References: <8D3D17ACE214DC429325B2B98F3AE712984AD617@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712984AD623@MX15A.corp.emc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1149764013==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: tsvwg IETF list , "anuragb@cisco.com" , "jmpolk@cisco.com" Subject: Re: [tsvwg] resolution with draft-ietf-tsvwg-rsvp-pcn X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 17:37:53 -0000 --=====================_1149764013==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable David, Gorry, Just to confirm that - we resolved the outstanding issue over=20 aggregation over lunch - I was concerned it would=20 delay response to flash crowds, but it was a=20 misunderstanding on my part - so no change needed to the draft on this= count. - the deltas posted in -06 this afternoon do what=20 I asked (not sending PCN-specific error messages=20 to end-systems). My original review requested=20 this, and Georgios had tried to comply, but there=20 were some places in the doc that still said the=20 old stuff (incl in IANA Considerations). Fixed now. So I'm OK with WGLC - and I'll try to give it one last read over for that. Bob At 12:35 29/07/2013, Black, David wrote: >Not a problem =96 we ran ahead of time on other=20 >agenda items and decided to dispense w/the=20 >rsvp-pcn draft in the morning in order to free=20 >up some time this afternoon =96 Anurag was there,=20 >and everything=92s in fine shape wrt this draft=20 >now. I look forward to seeing the revised version. > >Thanks, >--David > >From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] >Sent: Monday, July 29, 2013 7:31 AM >To: Black, David; bhargava.anurag@gmail.com;=20 >gorry@erg.abdn.ac.uk; bob.briscoe@bt.com; anuragb@cisco.com >Cc: jmpolk@cisco.com >Subject: RE: resolution with draft-ietf-tsvwg-rsvp-pcn > > >Hi all, > > > >Thanks very much! As already mentined by Anurag=20 >we will make the requested changes by Bob and=20 >upload the new version before tomorrow morning! > >Sorry for not attending the tsvwg meeting, but I=20 >had to attend another meeting at that time! I=20 >thought that the rsvp-pcn draft will be presented during the afternoon= slot! > > > >Best regards, > >Georgios > >---------- >Van: Black, David [david.black@emc.com] >Verzonden: maandag 29 juli 2013 13:04 >To: Anurag Bhargava;=20 >gorry@erg.abdn.ac.uk;=20 >bob.briscoe@bt.com;=20 >Karagiannis, G. (EWI); anuragb@cisco.com >Cc: James Polk (jmpolk)=20 >(jmpolk@cisco.com); Black, David >Onderwerp: RE: resolution with draft-ietf-tsvwg-rsvp-pcn >Excellent =96 that sounds like a plan. > >Thanks, >--David > >From: Anurag Bhargava=20 >[mailto:bhargava.anurag@gmail.com] >Sent: Monday, July 29, 2013 6:57 AM >To:=20 >gorry@erg.abdn.ac.uk;=20 >Black, David;=20 >bob.briscoe@bt.com;=20 >Georgios Karagiannis; anuragb@cisco.com >Subject: Re: resolution with draft-ietf-tsvwg-rsvp-pcn > >Hi Gorry/David, > > Bob, Georgios and I just had a discussion on=20 > the draft. Bob is quite comfortable now and=20 > have asked us to make a couple of changes. >We will be doing the change today and will post=20 >a new version later today or tomorrow morning. >After we post the new version, please see if=20 >WGLC can be started (that will put pressure on the folks to review :)). > >-- >BR, >-Anurag ________________________________________________________________ Bob Briscoe, BT=20 --=====================_1149764013==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David, Gorry,

Just to confirm that
- we resolved the outstanding issue over aggregation over lunch - I was concerned it would delay response to flash crowds, but it was a misunderstanding on my part - so no change needed to the draft on this count.
- the deltas posted in -06 this afternoon do what I asked (not sending PCN-specific error messages to end-systems). My original review requested this, and Georgios had tried to comply, but there were some places in the doc that still said the old stuff (incl in IANA Considerations). Fixed now.

So I'm OK with WGLC - and I'll try to give it one last read over for that.


Bob

At 12:35 29/07/2013, Black, David wrote:
Not a problem =96 we ran= ahead of time on other agenda items and decided to dispense w/the rsvp-pcn draft in the morning in order to free up some time this afternoon =96 Anurag was there, and everything=92s in fine shape wrt this draft now.  I look forward to seeing the revised version.
 
Thanks,
--David
 
From: karagian@cs.utwente.nl [ mailto:karagian@cs.utwente.nl]
Sent: Monday, July 29, 2013 7:31 AM
To: Black, David; bhargava.anurag@gmail.com; gorry@erg.abdn.ac.uk; bob.briscoe@bt.com; anuragb@cisco.com
Cc: jmpolk@cisco.com
Subject: RE: resolution with draft-ietf-tsvwg-rsvp-pcn
 

Hi all,

 

Thanks very much! As already mentined by Anurag we will make the requested changes by Bob and upload the new version before tomorrow morning!

Sorry for not attending the tsvwg meeting, but I had to attend another meeting  at that time! I thought that the rsvp-pcn draft will be presented during the afternoon slot!

 

Best regards,

Georgios
Van: Black, David [david.black@emc.com]
Verzonden: maandag 29 juli 2013 13:04
To: Anurag Bhargava; gorry@erg.abdn.ac.uk; bob.briscoe@bt.com; Karagiannis, G. (EWI); anuragb@cisco.com
Cc: James Polk (jmpolk) (jmpolk@cisco.com); Black, David
Onderwerp: RE: resolution with draft-ietf-tsvwg-rsvp-pcn
Excellent =96 that sounds like a plan.
 
Thanks,
--David
 
From: Anurag Bhargava [ mailto:bhargava.anurag@gmail.com]
Sent: Monday, July 29, 2013 6:57 AM
To: gorry@erg.abdn.ac.uk; Black, David; bob.briscoe@bt.com; Georgios Karagiannis; anuragb@cisco.com
Subject: Re: resolution with draft-ietf-tsvwg-rsvp-pcn
 
Hi Gorry/David,
 
  Bob, Georgios and I just had a discussion on the draft. Bob is quite comfortable now and have asked us to make a couple of changes.
We will be doing the change today and will post a new version later today or tomorrow morning.
After we post the new version, please see if WGLC can be started (that will put pressure on the folks to review :)).

--
BR,
-Anurag

________________________________________________________________
Bob Briscoe,           &n= bsp;            =             &nbs= p;             BT --=====================_1149764013==.ALT-- From david.black@emc.com Mon Jul 29 11:20:00 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518B921F9CD7 for ; Mon, 29 Jul 2013 11:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzpyArO6WpTl for ; Mon, 29 Jul 2013 11:19:54 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3584621F9D02 for ; Mon, 29 Jul 2013 11:19:36 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6TIJ7jC023036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jul 2013 14:19:07 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Mon, 29 Jul 2013 14:18:54 -0400 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6TIIrhR022987; Mon, 29 Jul 2013 14:18:53 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Mon, 29 Jul 2013 14:18:53 -0400 From: "Black, David" To: Bob Briscoe , "gorry@erg.abdn.ac.uk" Date: Mon, 29 Jul 2013 14:18:51 -0400 Thread-Topic: resolution with draft-ietf-tsvwg-rsvp-pcn Thread-Index: Ac6Mgj+AOHKEZ/UHT6eaVWim9kCqngABY7fw Message-ID: <8D3D17ACE214DC429325B2B98F3AE7129857DE55@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712984AD617@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712984AD623@MX15A.corp.emc.com> <201307291736.r6THasV4009963@bagheera.jungle.bt.co.uk> In-Reply-To: <201307291736.r6THasV4009963@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE7129857DE55MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "anuragb@cisco.com" , tsvwg IETF list , "jmpolk@cisco.com" Subject: Re: [tsvwg] resolution with draft-ietf-tsvwg-rsvp-pcn X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 18:20:01 -0000 --_000_8D3D17ACE214DC429325B2B98F3AE7129857DE55MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bob, Thank you for following up on this. I've also taken a closer look at the two text changes reported on the rsvp-= pcn draft slides used today, and they both look fine to me (one was wrt a c= omment of mine). Gorry and I will consult on getting the WGLC started for = this draft. Thanks, --David From: Bob Briscoe [mailto:bob.briscoe@bt.com] Sent: Monday, July 29, 2013 1:37 PM To: Black, David; gorry@erg.abdn.ac.uk Cc: karagian@cs.utwente.nl; bhargava.anurag@gmail.com; anuragb@cisco.com; j= mpolk@cisco.com; Black, David; tsvwg IETF list Subject: RE: resolution with draft-ietf-tsvwg-rsvp-pcn David, Gorry, Just to confirm that - we resolved the outstanding issue over aggregation over lunch - I was con= cerned it would delay response to flash crowds, but it was a misunderstandi= ng on my part - so no change needed to the draft on this count. - the deltas posted in -06 this afternoon do what I asked (not sending PCN-= specific error messages to end-systems). My original review requested this,= and Georgios had tried to comply, but there were some places in the doc th= at still said the old stuff (incl in IANA Considerations). Fixed now. So I'm OK with WGLC - and I'll try to give it one last read over for that. Bob At 12:35 29/07/2013, Black, David wrote: Not a problem - we ran ahead of time on other agenda items and decided to d= ispense w/the rsvp-pcn draft in the morning in order to free up some time t= his afternoon - Anurag was there, and everything's in fine shape wrt this d= raft now. I look forward to seeing the revised version. Thanks, --David From: karagian@cs.utwente.nl [ mailto:karagi= an@cs.utwente.nl] Sent: Monday, July 29, 2013 7:31 AM To: Black, David; bhargava.anurag@gmail.com; gorry@erg.abdn.ac.uk; bob.briscoe@bt.com; anuragb@cisco.com Cc: jmpolk@cisco.com Subject: RE: resolution with draft-ietf-tsvwg-rsvp-pcn Hi all, Thanks very much! As already mentined by Anurag we will make the requested = changes by Bob and upload the new version before tomorrow morning! Sorry for not attending the tsvwg meeting, but I had to attend another meet= ing at that time! I thought that the rsvp-pcn draft will be presented duri= ng the afternoon slot! Best regards, Georgios ________________________________ Van: Black, David [david.black@emc.com] Verzonden: maandag 29 juli 2013 13:04 To: Anurag Bhargava; gorry@erg.abdn.ac.uk; bob= .briscoe@bt.com; Karagiannis, G. (EWI); anuragb@= cisco.com Cc: James Polk (jmpolk) (jmpolk@cisco.com); Black,= David Onderwerp: RE: resolution with draft-ietf-tsvwg-rsvp-pcn Excellent - that sounds like a plan. Thanks, --David From: Anurag Bhargava [ mailto:bhargava.anurag@gmail.com] Sent: Monday, July 29, 2013 6:57 AM To: gorry@erg.abdn.ac.uk; Black, David; bob.br= iscoe@bt.com; Georgios Karagiannis; anuragb@cisc= o.com Subject: Re: resolution with draft-ietf-tsvwg-rsvp-pcn Hi Gorry/David, Bob, Georgios and I just had a discussion on the draft. Bob is quite comf= ortable now and have asked us to make a couple of changes. We will be doing the change today and will post a new version later today o= r tomorrow morning. After we post the new version, please see if WGLC can be started (that will= put pressure on the folks to review :)). -- BR, -Anurag ________________________________________________________________ Bob Briscoe, BT --_000_8D3D17ACE214DC429325B2B98F3AE7129857DE55MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bob,

 

Thank y= ou for following up on this.

&nb= sp;

I’ve also taken a closer look at= the two text changes reported on the rsvp-pcn draft slides used today, and= they both look fine to me (one was wrt a comment of mine).  Gorry and= I will consult on getting the WGLC started for this draft.

 

Thanks,
--David

=  

From: B= ob Briscoe [mailto:bob.briscoe@bt.com]
Sent: Monday, July 29, 20= 13 1:37 PM
To: Black, David; gorry@erg.abdn.ac.uk
Cc: k= aragian@cs.utwente.nl; bhargava.anurag@gmail.com; anuragb@cisco.com; jmpolk= @cisco.com; Black, David; tsvwg IETF list
Subject: RE: resolution= with draft-ietf-tsvwg-rsvp-pcn

 

David, Gorry,
Just to confirm that
- we resolved the outstanding issue over aggregat= ion over lunch - I was concerned it would delay response to flash crowds, b= ut it was a misunderstanding on my part - so no change needed to the draft = on this count.
- the deltas posted in -06 this afternoon do what I asked= (not sending PCN-specific error messages to end-systems). My original revi= ew requested this, and Georgios had tried to comply, but there were some pl= aces in the doc that still said the old stuff (incl in IANA Considerations)= . Fixed now.

So I'm OK with WGLC - and I'll try to give it one last = read over for that.


Bob

At 12:35 29/07/2013, Black, David= wrote:

Not a problem – we= ran ahead of time on other agenda items and decided to dispense w/the rsvp= -pcn draft in the morning in order to free up some time this afternoon R= 11; Anurag was there, and everything’s in fine shape wrt this draft n= ow.  I look forward to seeing the revised version.
 
Thanks= ,
--David
 
From: karagian@cs.utwente.nl [ mailto:karagian@cs.utwente.nl]
Sent: Monday, July 29, 2013= 7:31 AM
To: Black, David; bhargava.anurag@gmail.com; gorry@erg.abdn.ac.uk; bob.bris= coe@bt.com; anuragb@cisco.com<= br>Cc: jmpolk@cisco.com
<= b>Subject: RE: resolution with draft-ietf-tsvwg-rsvp-pcn
 
<= br>Hi all,

 

Thanks very much! As already mentined by An= urag we will make the requested changes by Bob and upload the new version b= efore tomorrow morning!

Sorry for not attending the tsvwg meeting, b= ut I had to attend another meeting  at that time! I thought that the r= svp-pcn draft will be presented during the afternoon slot!

 
Best regards,

Georgios

Van: Black, David [david.black@= emc.com]
Verzonden: maandag 29 juli 2013 13:04
To: Anur= ag Bhargava; gorry@erg.abdn.ac.uk; bob.briscoe@bt.com; Karagiann= is, G. (EWI); anuragb@cisco.comCc: James Polk (jmpolk) (jmpolk= @cisco.com); Black, David
Onderwerp: RE: resolution with draf= t-ietf-tsvwg-rsvp-pcn
Excellent – that sounds like a plan.
&nbs= p;
Thanks,
--David
 
From: Anurag Bhargava [ mailto:bhargava.anurag@gmail.com= ]
Sent: Monday, July 29, 2013 6:57 AM
To: gorry@erg.abdn.ac.uk; Black, David; bob.briscoe@bt.com; Georgios Karagiannis= ; anuragb@cisco.com
Subject:= Re: resolution with draft-ietf-tsvwg-rsvp-pcn
 
Hi Gorry/Da= vid,
 
  Bob, Georgios and I just had a discussion on the d= raft. Bob is quite comfortable now and have asked us to make a couple of ch= anges.
We will be doing the change today and will post a new version lat= er today or tomorrow morning.
After we post the new version, please see = if WGLC can be started (that will put pressure on the folks to review :)).<= br>
--
BR,
-Anurag

____________________________= ____________________________________
Bob Briscoe,    = ;            &n= bsp;            = ;            &n= bsp;        BT

= --_000_8D3D17ACE214DC429325B2B98F3AE7129857DE55MX15Acorpemccom_-- From bhargava.anurag@gmail.com Mon Jul 29 16:42:11 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D258121E80B2 for ; Mon, 29 Jul 2013 16:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhpaNexy7CmZ for ; Mon, 29 Jul 2013 16:42:11 -0700 (PDT) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id A435921E8054 for ; Mon, 29 Jul 2013 16:42:10 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id c1so3181834eek.38 for ; Mon, 29 Jul 2013 16:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=GEHGu81J38HGyW/tiX3SPCDIXcSR/D3KiAuqiMTfvPI=; b=OP47bnhQ0ws1lvCtqYj0BB+Fla5rXq3V+hod7UO+MD0m/PdWDx+PfNLlknLKckw0Cw xNxbcUGwSWwoMD9pIQmp6Pwu7sLC4GMhO3QQ6LxD4M9M42oKOGibjchyFCEUBvlRSltU 4UOQZRgGSxFJiNXCRT7s16uIEeUZ340u8BHMwh7Radk4hs2fYFHoYEDwxXsHc2UVgwl2 a7fkaYd3ruZGqzwKqVqE8ooTXmrYZPefH4PiXgmtIzVoFynpPBABZaKckT89Fn14pa2w b64aVO4Nw6N2aF18P9V/93MjT7Y216oQ9is1I8oGYIxLNpxmsLHvrtBUywD0jjdDevbJ rYzA== X-Received: by 10.14.251.202 with SMTP id b50mr61854809ees.85.1375141329598; Mon, 29 Jul 2013 16:42:09 -0700 (PDT) Received: from [192.168.4.71] (p5DDB4D8B.dip0.t-ipconnect.de. [93.219.77.139]) by mx.google.com with ESMTPSA id p49sm105723571eeu.2.2013.07.29.16.42.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 16:42:08 -0700 (PDT) References: <8D3D17ACE214DC429325B2B98F3AE712984AD617@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712984AD623@MX15A.corp.emc.com> <201307291736.r6THasV4009963@bagheera.jungle.bt.co.uk> <8D3D17ACE214DC429325B2B98F3AE7129857DE55@MX15A.corp.emc.com> Mime-Version: 1.0 (1.0) In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7129857DE55@MX15A.corp.emc.com> Content-Type: multipart/alternative; boundary=Apple-Mail-38D1F41F-EF6F-4226-97DF-557A1671C152 Content-Transfer-Encoding: 7bit Message-Id: <0E204725-3221-4B15-9D63-BC2B9FA173A3@gmail.com> X-Mailer: iPhone Mail (10B350) From: bhargava.anurag@gmail.com Date: Tue, 30 Jul 2013 01:42:06 +0200 To: "Black, David" Cc: "gorry@erg.abdn.ac.uk" , tsvwg IETF list , "anuragb@cisco.com" , "jmpolk@cisco.com" Subject: Re: [tsvwg] resolution with draft-ietf-tsvwg-rsvp-pcn X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 23:42:11 -0000 --Apple-Mail-38D1F41F-EF6F-4226-97DF-557A1671C152 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks all. Br, Anurag Sent from my iPhone On Jul 29, 2013, at 8:18 PM, "Black, David" wrote: > Bob, > =20 > Thank you for following up on this. > =20 > I=E2=80=99ve also taken a closer look at the two text changes reported on t= he rsvp-pcn draft slides used today, and they both look fine to me (one was w= rt a comment of mine). Gorry and I will consult on getting the WGLC started= for this draft. > =20 > Thanks, > --David > =20 > From: Bob Briscoe [mailto:bob.briscoe@bt.com]=20 > Sent: Monday, July 29, 2013 1:37 PM > To: Black, David; gorry@erg.abdn.ac.uk > Cc: karagian@cs.utwente.nl; bhargava.anurag@gmail.com; anuragb@cisco.com; j= mpolk@cisco.com; Black, David; tsvwg IETF list > Subject: RE: resolution with draft-ietf-tsvwg-rsvp-pcn > =20 > David, Gorry, >=20 > Just to confirm that=20 > - we resolved the outstanding issue over aggregation over lunch - I was co= ncerned it would delay response to flash crowds, but it was a misunderstandi= ng on my part - so no change needed to the draft on this count. > - the deltas posted in -06 this afternoon do what I asked (not sending PCN= -specific error messages to end-systems). My original review requested this,= and Georgios had tried to comply, but there were some places in the doc tha= t still said the old stuff (incl in IANA Considerations). Fixed now. >=20 > So I'm OK with WGLC - and I'll try to give it one last read over for that.= >=20 >=20 > Bob >=20 > At 12:35 29/07/2013, Black, David wrote: >=20 > Not a problem =E2=80=93 we ran ahead of time on other agenda items and dec= ided to dispense w/the rsvp-pcn draft in the morning in order to free up som= e time this afternoon =E2=80=93 Anurag was there, and everything=E2=80=99s i= n fine shape wrt this draft now. I look forward to seeing the revised versi= on. > =20 > Thanks, > --David > =20 > From: karagian@cs.utwente.nl [ mailto:karagian@cs.utwente.nl]=20 > Sent: Monday, July 29, 2013 7:31 AM > To: Black, David; bhargava.anurag@gmail.com; gorry@erg.abdn.ac.uk; bob.bri= scoe@bt.com; anuragb@cisco.com > Cc: jmpolk@cisco.com > Subject: RE: resolution with draft-ietf-tsvwg-rsvp-pcn > =20 >=20 > Hi all, >=20 > =20 >=20 > Thanks very much! As already mentined by Anurag we will make the requested= changes by Bob and upload the new version before tomorrow morning! >=20 > Sorry for not attending the tsvwg meeting, but I had to attend another mee= ting at that time! I thought that the rsvp-pcn draft will be presented duri= ng the afternoon slot! >=20 > =20 >=20 > Best regards, >=20 > Georgios > Van: Black, David [david.black@emc.com] > Verzonden: maandag 29 juli 2013 13:04 > To: Anurag Bhargava; gorry@erg.abdn.ac.uk; bob.briscoe@bt.com; Karagiannis= , G. (EWI); anuragb@cisco.com > Cc: James Polk (jmpolk) (jmpolk@cisco.com); Black, David > Onderwerp: RE: resolution with draft-ietf-tsvwg-rsvp-pcn > Excellent =E2=80=93 that sounds like a plan. > =20 > Thanks, > --David > =20 > From: Anurag Bhargava [ mailto:bhargava.anurag@gmail.com]=20 > Sent: Monday, July 29, 2013 6:57 AM > To: gorry@erg.abdn.ac.uk; Black, David; bob.briscoe@bt.com; Georgios Karag= iannis; anuragb@cisco.com > Subject: Re: resolution with draft-ietf-tsvwg-rsvp-pcn > =20 > Hi Gorry/David, > =20 > Bob, Georgios and I just had a discussion on the draft. Bob is quite com= fortable now and have asked us to make a couple of changes. > We will be doing the change today and will post a new version later today o= r tomorrow morning. > After we post the new version, please see if WGLC can be started (that wil= l put pressure on the folks to review :)). >=20 > --=20 > BR, > -Anurag > ________________________________________________________________ > Bob Briscoe, BT --Apple-Mail-38D1F41F-EF6F-4226-97DF-557A1671C152 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks all.

B= r,
Anurag

Sent from my iPhone

On Jul 2= 9, 2013, at 8:18 PM, "Black, David" <david.black@emc.com> wrote:

Bob,

&nbs= p;

Thank you for following up on= this.

 

I=E2=80=99ve also taken a closer look at= the two text changes reported on the rsvp-pcn draft slides used today, and t= hey both look fine to me (one was wrt a comment of mine).  Gorry and I w= ill consult on getting the WGLC started for this draft.

 

Thanks,
--David

<= /div>

 

From: Bob Bri= scoe [mailto:bob.briscoe@bt.com] <= br>Sent: Monday, July 29, 2013 1:37 PM
To: Black, David; gorry@erg.abdn.ac.uk
Cc:= karagian@cs.utwente.nl; bhargava.anurag@gmail.com; anuragb@cisco.com; jmpolk@cisco.com; Black, David; tsvwg IETF list
Sub= ject: RE: resolution with draft-ietf-tsvwg-rsvp-pcn

 

David, Gorry,

Just to confirm that
- we resolved the outstand= ing issue over aggregation over lunch - I was concerned it would delay respo= nse to flash crowds, but it was a misunderstanding on my part - so no change= needed to the draft on this count.
- the deltas posted in -06 this after= noon do what I asked (not sending PCN-specific error messages to end-systems= ). My original review requested this, and Georgios had tried to comply, but t= here were some places in the doc that still said the old stuff (incl in IANA= Considerations). Fixed now.

So I'm OK with WGLC - and I'll try to gi= ve it one last read over for that.


Bob

At 12:35 29/07/2013= , Black, David wrote:

Not a pro= blem =E2=80=93 we ran ahead of time on other agenda items and decided to dis= pense w/the rsvp-pcn draft in the morning in order to free up some time this= afternoon =E2=80=93 Anurag was there, and everything=E2=80=99s in fine shap= e wrt this draft now.  I look forward to seeing the revised version. 
Thanks,
--David
 
From: karagian@cs.utwente.nl [ mailto:karagian@cs.utwente.nl]
Sent: Monday,= July 29, 2013 7:31 AM
To: Black, David; bhargava.anurag@gmail.com; gorry@erg.abdn.ac.uk; bob.briscoe@bt.com; anuragb@cisc= o.com
Cc: jmpolk@cisco.com=
Subject: RE: resolution with draft-ietf-tsvwg-rsvp-pcn
&nb= sp;

Hi all,

 

Thanks very much! As already mentine= d by Anurag we will make the requested changes by Bob and upload the new ver= sion before tomorrow morning!

Sorry for not attending the tsvwg meeti= ng, but I had to attend another meeting  at that time! I thought that t= he rsvp-pcn draft will be presented during the afternoon slot!

 =

Best regards,

Georgios

Van: Black, David [david.black@emc.com]
Verzonden:<= /b> maandag 29 juli 2013 13:04
To: Anurag Bhargava; gorry@erg.abdn.ac.uk; bob.briscoe@bt.com; Karagiannis, G. (EWI); anuragb@cisco.com
Cc: James Polk (jmpolk= ) (jmpolk@cisco.com); Black, DavidOnderwerp: RE: resolution with draft-ietf-tsvwg-rsvp-pcn
Excelle= nt =E2=80=93 that sounds like a plan.
 
Thanks,
--David
&nb= sp;
From: Anurag Bhargava [ mailto:bhargava.anurag@gmail.com]
Sent: Monday, July 2= 9, 2013 6:57 AM
To: gorry@= erg.abdn.ac.uk; Black, David; bob.= briscoe@bt.com; Georgios Karagiannis; anuragb@cisco.com
Subject: Re: resolution with draft-ietf-t= svwg-rsvp-pcn
 
Hi Gorry/David,
 
  Bob, Georgios= and I just had a discussion on the draft. Bob is quite comfortable now and h= ave asked us to make a couple of changes.
We will be doing the change tod= ay and will post a new version later today or tomorrow morning.
After we p= ost the new version, please see if WGLC can be started (that will put pressu= re on the folks to review :)).

--
BR,
-Anurag

<= p>________________________________________________________________
Bob Br= iscoe,           &nbs= p;            &n= bsp;            =              BT<= o:p>

= --Apple-Mail-38D1F41F-EF6F-4226-97DF-557A1671C152-- From Ruediger.Geib@telekom.de Wed Jul 31 01:12:05 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8C721E812A; Wed, 31 Jul 2013 01:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FPWBLefvPST; Wed, 31 Jul 2013 01:11:45 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 6F32821F9E9E; Wed, 31 Jul 2013 01:11:19 -0700 (PDT) Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 31 Jul 2013 10:11:07 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 31 Jul 2013 10:11:07 +0200 From: To: Date: Wed, 31 Jul 2013 10:11:05 +0200 Thread-Topic: [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) Thread-Index: Ac5+myIfjYPS5jaWQ0qZ0s3PmyqMpwPJs6TA Message-ID: References: <20130710180147.GA614@cisco.com> <20130712005930.GB30036@cisco.com> In-Reply-To: <20130712005930.GB30036@cisco.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: rmcat@ietf.org, rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 08:12:07 -0000 Toerless, discussion seems to conclude with: - fairness must be enforced if senders don't set DSCPs according to the glo= bal fairness scheme. - video applications have a hard time setting DSCPs anyway due to a missing= API. - ECN is not meant to indicate drop priorities and offers an insufficient number of states. It might be easier to use a single PHB/DSCP and add PCN like ECN. In an e2e= mode with receivers giving PCN congestion feedback to senders. My definiti= on of PCN would be "rate control on a congested link" (rather than admissio= n control and traffic termination as applied by the WG - I've been involved= in the WGs work). This should result in: - avoidance of sudden overload in that class (no burst drops) - rate adaption of senders if congestion is pending - a simpler design as compared to what you and Ken discussed I'm going to drop another message soon. Regards, Ruediger -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of T= oerless Eckert (eckert) Sent: Friday, July 12, 2013 3:00 AM To: Dave Taht Cc: rmcat@ietf.org; rtcweb@ietf.org; tsvwg@ietf.org Subject: Re: [tsvwg] Using intelligent dropping to improve video quality un= der congestion (draft-lai-tsvwg-normalizer-00.txt) On Wed, Jul 10, 2013 at 12:02:26PM -0700, Dave Taht wrote: > I've begun to look at webrtc of late in the context of fq_codel. > > One thing that might work would be ECN marking important frames and > not ECN marking others. True. But i think there are at least 3 layers of priority that would really be great to have: really important packet (long term reference frames), "normal" packets, and low-proirity-packets (eg: discardable P). And ECN could only do two. Most of the time when you would want intelligent dropping, your drop rate should be fairly low, eg< 20% instantaneous within the queue. If you can do discardable P-frames it's of course best to drop those first. Only when you instantaneously have really big bursts would you want to drop "normal" packets and refrain to protection really important packets. This does work really well with different queue-length (or WRED profiles). If you only had two priorities (via ECN) it's hard to say how you would best assign these two priorities to at least those three priority levels. > Problem overall is that ecn can be gamed and is largely not > enabled, and so on... Well. The gaming could be inhibited exactly by this draft because it would try to guarantee the same amount of drops on a per-flow or "class" basis, so if you're trying to game the system, you would be put into your own class and would still see the same amount of drops as other flows. Well, the main issue is really to redesignate ECN for a different semantic than what it has today. And indicating packet priority is just not quite the same as congestion feedback. > In the case of the fq_codel algorithm I can see a "delayed drop" > mechanism happening, > where upon deciding to drop, it could defer a drop up to a few packets > based on the classification > of the packet, say 3 packets at most. Since flows are already > identified, this is kind of easy > by adding another state variable... Yes, this is all quite interesting. We also played around with droppping during enqueuing vs. during dequeuing, so there are a bunch of things that could optimize intelligent dropping if you can build a more intelligent queue. [...] > > So I can see trying to utilize the AF markings as you describe in your > draft in codel's > drop decision. While this is also subject to being gamed, the > disincentives are slight. Lets separate the marking from the mechanism to inhibit gaming. This draft really is about the latter, and the marking described with AF is really just an example. Yes, it would be lovely to agree on markings too. > And what codel depends on is a definition of "TCP friendly". That if a > stream is not going to behave in a tcp friendly manner, then an entirely > different strategy for such flows seems necessary, and glomming on some > additional state isn't going to be the right thing. Who stood up at RMCAT some time back and claimed to have worked for > 10 years on TCP and declared TCP not self friendly to itself, so RMCAT shouldn't bother ? ;-)) Kidding aside: Intelligent dropping IMHO makes perfect sense when being applied to RT traffic sharing a queue friendly with TCP. And intelligent dropping can then still improve the performance. I am pretty positive though that RMCAT traffic in general will behave better and get lower delay and more video-appropriate loss if it can have its own queue. Primarily because it will just take decates to root out all the bad TCP traffic. I don't think that the strategies if you do or if you don't share the queue with TCP would be fundamentally be different. > a) how well can it work in routers to shift packet drops to low-prio pack= ets > > I guess where I fall apart here is how to shift the encoders to send thin= ner > streams at any level of packet drop. Video codec coders are known to be able to do crazy cool things. There are a bunch of known mechanisms and probably more proprietary ones. > I'd be interested in specific codecs, example video streams, and test > scripts to try and fiddle with this, as well as viable metrics. Sure. Best done in person. If we're going to be at the WG for this, we can talk on the side how we've been doing this. Cheers Toerless > > Thanks! > > Toerless > > > > In-Reply-To: > > > > On Sat, Feb 09, 2013 at 03:00:48AM +0000, Cheng-Jia Lai (chelai) wrote: > >> Hi all, > >> > >> We have submitted a new Internet draft to describe a Normalization Mar= ker (NM) for DiffServ AF PHB groups, based on our work at Cisco. The goal o= f NM deployment is to create a new incentive for video encoders to generate= more discardable packets when using AF PHB in DIffServ. We are looking for= ward to your review comments. > >> > >> Best regards, > >> CJ > >> > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Friday, February 08, 2013 6:25 PM > >> To: Cheng-Jia Lai (chelai) > >> Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (ecke= rt); Fred Yip (fyip) > >> Subject: New Version Notification for draft-lai-tsvwg-normalizer-00.tx= t > >> > >> > >> A new version of I-D, draft-lai-tsvwg-normalizer-00.txt > >> has been successfully submitted by Cheng-Jia Lai and posted to the > >> IETF repository. > >> > >> Filename: draft-lai-tsvwg-normalizer > >> Revision: 00 > >> Title: Normalization Marker for AF PHB Group in DiffSe= rv > >> Creation date: 2013-02-08 > >> WG ID: Individual Submission > >> Number of pages: 15 > >> URL: http://www.ietf.org/internet-drafts/draft-lai-tsvwg-n= ormalizer-00.txt > >> Status: http://datatracker.ietf.org/doc/draft-lai-tsvwg-norma= lizer > >> Htmlized: http://tools.ietf.org/html/draft-lai-tsvwg-normalizer= -00 > >> > >> > >> Abstract: > >> This memo describes a Normalization Marker (NM) at DiffServ (DS) > >> nodes to normalize the distribution of DS codepoint (DSCP) markings > >> for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM is > >> useful for traffic conditioning with Active Queue Management (AQM) > >> when the AF PHB group is deployed for multimedia service classes th= at > >> carry video packets with advanced codec technologies. Using NM can > >> offer an incentive that is however missing in today's ecosystem of > >> practical deployment, i.e., when congestion occurs in the AF PHB > >> group, the network should allow a video codec to benefit from its > >> effort of generating finer layers of intra-flow precedence (IFP) wi= th > >> discardable packets in a more balanced distribution. > >> > >> > >> > >> > >> The IETF Secretariat > >> > > > > -- > > --- > > Toerless Eckert, eckert@cisco.com > > Cisco NSSTG Systems & Technology Architecture > > SDN: Let me play with the network, mommy! > > > > > > -- > Dave T=E4ht > > Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscrib= e.html -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From Ruediger.Geib@telekom.de Wed Jul 31 01:28:44 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B5D21E8055; Wed, 31 Jul 2013 01:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.886, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zx6gRZKc-jTg; Wed, 31 Jul 2013 01:28:17 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1829021F9E96; Wed, 31 Jul 2013 01:26:51 -0700 (PDT) Received: from he113656.emea1.cds.t-internal.com ([10.134.99.16]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 31 Jul 2013 10:26:50 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113656.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 31 Jul 2013 10:26:49 +0200 From: To: Date: Wed, 31 Jul 2013 10:26:48 +0200 Thread-Topic: [tsvwg] Using intelligent dropping to improve video.....adding admission control? Thread-Index: Ac5+myIfjYPS5jaWQ0qZ0s3PmyqMpwPKmREw Message-ID: References: <20130710180147.GA614@cisco.com> <20130712005930.GB30036@cisco.com> In-Reply-To: <20130712005930.GB30036@cisco.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: rmcat@ietf.org, rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] Using intelligent dropping to improve video.....adding admission control? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 08:28:45 -0000 Toerless, prior to setting up a new call, some kind of available bandwidth measuremen= t or indication might be added. This isn't part of your draft. But an addit= ional video stream may cause congestion on a bottleneck. Measurement based admission control has been controversial so far. If used,= the main point is to use a measurement class sharing the same queue as the= traffic to be admitted, but having a higher drop probability. - PCN is an option, but requires a new marking behaviour (threshold marker). End to end PCN as mentioned in another email. - Using AF41 for admitted traffic and AF42 to perform measurements is an option to me, both should support ECN marking (AF42 seeing the higher marking and drop probability). As marked packets indicating an issue can be interpreted by routers along a= path, while packets dropped earlier elsewhere can't be, I prefer marking t= o dropping. I also think, it is easier to detect packet marks than delay va= riation measurements in routers, if it is about detecting congestion. Take the above as an example. I used a separate thread as this isn't part o= f your draft an I accept if this shouldn't be discussed in the context of t= his draft. It fit's well to the RTCWeb QoS discussion though, I think. Regards, Ruediger