From jeff.morriss.ws@gmail.com Thu Nov 1 08:24:05 2012 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 E3D7021F8E02 for ; Thu, 1 Nov 2012 08:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zk9gA+BlD6yq for ; Thu, 1 Nov 2012 08:23:58 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4F621F8E01 for ; Thu, 1 Nov 2012 08:23:57 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3108699vcb.31 for ; Thu, 01 Nov 2012 08:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=/TOzjjN0E4CLimGny10nZcFdFY2QVxIsdQ+bhjxfgkA=; b=mbfHDkxjrojMdAm5YSgXhux3OuP9kFNqMYvU7e6ha4hxS6gqBW8Bd3eYp4u8uq8OhX E64m1mT5NjkTHa5jQGzSt3WHudwuvQbsU0J47df/ukBqHL5eVKlgr9lIlwhkrzVX6BD3 O8VaD9PQimo0b73M9QIrXXPg8uOvD82Zbd/hhru+xUriPkT4I5XhPLg70YF9zMctDwJP r45s/fWYXFFQBlJygI+gg3nITZf6p7xkDwiaLlxYImxGwcFbnIsPbwKH/ODPgKZFnGMr gVQn2UbY6EBa0CzSJiE444I7JsnuARg+WH3BNysX69m+NIca8k1NI4qpDm+GjJHY2g2c lNQQ== Received: by 10.52.76.103 with SMTP id j7mr51211382vdw.22.1351783437098; Thu, 01 Nov 2012 08:23:57 -0700 (PDT) Received: from nj-morriss-test.ulticom.com ([74.8.208.5]) by mx.google.com with ESMTPS id d4sm3674223vew.7.2012.11.01.08.23.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Nov 2012 08:23:56 -0700 (PDT) Message-ID: <5092940A.2010805@gmail.com> Date: Thu, 01 Nov 2012 11:23:54 -0400 From: Jeff Morriss User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: "tsvwg@ietf.org" Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [tsvwg] SCTP: abort after excessive errors? 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, 01 Nov 2012 15:24:06 -0000 Hi list, I recently had a problem at an interop event where my system was responding to message from an SCTP peer with an ABORT. A little analysis showed me the problem: - the T-bit was set in the ABORT - (and, after more digging) the application had received notification that the association in question had been closed some time before So my local SCTP had torn down the association but neither I (looking in Wireshark but not at the application logs) nor the peer were made aware of it. More analysis in Wireshark showed that my system's SCTP had experienced a sufficient number of association errors (lack of responses from the peer) to bring down the association (the peer clearly had not experienced that many errors since it kept the assoc up). What confuses me is that I would expect SCTP to send an ABORT when this happens; other implementations with which I am familiar do. In re-reading the RFC, the relevant section doesn't explicitly mention sending an ABORT: ~~~ 8.1. Endpoint Failure Detection An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (this includes retransmissions to all the destination transport addresses of the peer if it is multi-homed), including unacknowledged HEARTBEAT chunks. If the value of this counter exceeds the limit indicated in the protocol parameter ’Association.Max.Retrans’, the endpoint shall consider the peer endpoint unreachable and shall stop transmitting any more data to it (and thus the association enters the CLOSED state). In addition, the endpoint MAY report the failure to the upper layer and optionally report back all outstanding user data remaining in its outbound queue. The association is automatically closed when the peer endpoint becomes unreachable ~~~ But I think that such an association closure is certainly an ungraceful one and thus section 9.1 applies: ~~~ 9.1. Abort of an Association When an endpoint decides to abort an existing association, it MUST send an ABORT chunk to its peer endpoint. The sender MUST fill in... ~~~ Would you agree? If so, would a clarification be useful in section 8.1? Personally I think that an ABORT must be sent in such situations so that the peer can be aware of the situation (before a subsequent message or heartbeat from the peer finally provokes an ABORT); in my case the peer could easily have re-established the association before it came time to send the message which my system treated as OOTB. Regards, -Jeff From carlberg@g11.org.uk Thu Nov 1 13:21:31 2012 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 D1DD821F96D7 for ; Thu, 1 Nov 2012 13:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHi-r4apqH+D for ; Thu, 1 Nov 2012 13:21:29 -0700 (PDT) Received: from portland.eukhosting.net (portland.ukserverhosting.net [92.48.103.133]) by ietfa.amsl.com (Postfix) with ESMTP id 21F1821F96C6 for ; Thu, 1 Nov 2012 13:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=Mime-Version:To:Cc:Message-Id:Date:Subject:Content-Transfer-Encoding:Content-Type:From; bh=GfIFW/seQfiprQPDoM6ivvlc790tI7UoObwU+B0kwLQ=; b=J2l7eCKeBtYzaxYsj94qIzOA9spxVHTUU9yUqQ9PkQzquAlXA/4+IC7VFA0oMentUoWgIJW9nD6vncrL1fIOVcgC4DM7anjus7jatqFXpvxcVdmBOhOTnTmq/g7CvNsC; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:53021 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.80) (envelope-from ) id 1TU1GV-00070z-6g; Thu, 01 Nov 2012 20:21:23 +0000 From: ken carlberg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Nov 2012 16:21:21 -0400 Message-Id: <87644A58-0C27-4F5A-B09B-BD8EC1F9A10A@g11.org.uk> To: tsvwg Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) 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-Source: X-Source-Args: X-Source-Dir: Cc: anuragb@cisco.com, g.karagiannis@utwente.nl Subject: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-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: Thu, 01 Nov 2012 20:21:32 -0000 Hi Georgios and Anurag, I took a look at the draft and overall, it seems fine, though I do have = a few comments. Mostly for clarification. 1) The Introduction dives right into what I would see as background = information. You need to add some text in the beginning of Section 1 = that tells the reader what you plan to do (ie, leverage RSVP in support = of PCN) and explain that PCN needs a signaling protocol to complete a = feedback loop from egress to ingress. 2) You need to review the terminology section in more detail. Some of = the items in this section are not found anywhere else in the body of the = draft (eg, t_meas). I would also move the terminology subsection = further up in the section because you start talking about some terms = early on and then you define them later. 3) in some cases, you duplicate the definition of the terminology in the = body of the draft, and in one instance with some different = text/references. I think once you define the term, you don't need to = define it again. (eg, ingress-egress-aggregate) 4) in quite a few places, you defer additional explanation to a = particular RFC. An example being: 2.1.3. Deaggregator (PCN-egress-node) Determination In this document it is considered that for the determination = of the=20 Deaggregator, the same methods can be used as the ones = described in=20 [RFC4860]. =20 However, you do not point the reader to the specific section within that = reference. Given how often this is done, I think it would be helpful to = be more specific and identify the section/subsection in that refernce = that you are referring to. 5) On page 5, you state the following: The PCN-egress-nodes measure the rates of differently marked=20= PCN-traffic in periodic intervals and report these rates to = the=20 decision points for admission control and flow termination, = based on =09 which they take their decisions. The decision points may be=20= collocated with the PCN-ingress-nodes or their function may = be=20 implemented in a centralized node. For more details see = [RFC5559],=20 [RFC6661], [RFC6662]. In this document it is considered that = the=20 decision point is collocated with the PCN-ingress-node. The last sentence catches my attention because there is no additional = rationale stating why you made this decision, which in itself does not = sound like it was made with conviction (its a writing style nit). I = think you need to expand on this. For example, if we were to assume = that the decision point is a centralized node, how does this affect the = rest of your draft? 6) This comment is just for you to contemplate -- I'm not expecting any = changes. I noticed that you have a fair number of SHOULD, and some = SHOULD NOTs. And it seems a lot of this is a carry over from rfc-4860, = so in a sense you are inheriting an approach that was agreed to from an = earlier effort. But I wonder in the back of my mind, what impact occurs = if an implementor doesn't follow the SHOULD? Does the design break in = supporting PCN? Again, I want to stress that this isnt a show stopper, = but I would appreciate it if you gave it some thought. 7) For the security sections, at a minimum, you should add reference to = rfc-2205 and rfc-4230. You may also want to add reference to rfc6411. = And if the Router Alert Option is to be used, then you may want to look = at the Security Section of rfc-6401 for guidance on what to say about = RAO -ken From randall@lakerest.net Thu Nov 1 14:21:32 2012 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 C794021F9223 for ; Thu, 1 Nov 2012 14:21: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhJj8ss7Jaxq for ; Thu, 1 Nov 2012 14:21:32 -0700 (PDT) Received: from lakerest.net (lakerest.net [70.155.160.98]) by ietfa.amsl.com (Postfix) with ESMTP id 0276221F91DF for ; Thu, 1 Nov 2012 14:21:31 -0700 (PDT) Received: from [10.1.1.101] (bsd4.lakerest.net [70.155.160.102]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id qA1LLVH7023130 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 1 Nov 2012 17:21:31 -0400 (EDT) (envelope-from randall@lakerest.net) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Randy Stewart In-Reply-To: <5092940A.2010805@gmail.com> Date: Thu, 1 Nov 2012 17:21:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <08A63E33-058E-4295-9FC3-95D0991B3F22@lakerest.net> References: <5092940A.2010805@gmail.com> To: Jeff Morriss X-Mailer: Apple Mail (2.1283) Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] SCTP: abort after excessive errors? 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, 01 Nov 2012 21:21:32 -0000 Jeff: No I don't know if I do agree. I don't think you are required to in TCP = either. I do think that *many* implementations (both TCP and SCTP) do this. But = lets think about this, its quite possible the host is unreachable and adding yet = another packet to the network does not gain anything =85 yes its small =85 but = it is one more packet. I think that is why the wording is left loose so that implementations = have a choice. Most do send the ABORT, but not all do. I prefer that this remain an = implementation choice=85 but I would be glad to hear other opinions.. R On Nov 1, 2012, at 11:23 AM, Jeff Morriss wrote: > Hi list, >=20 > I recently had a problem at an interop event where my system was = responding to message from an SCTP peer with an ABORT. A little = analysis showed me the problem: >=20 > - the T-bit was set in the ABORT > - (and, after more digging) the application had received notification = that the association in question had been closed some time before >=20 > So my local SCTP had torn down the association but neither I (looking = in Wireshark but not at the application logs) nor the peer were made = aware of it. >=20 > More analysis in Wireshark showed that my system's SCTP had = experienced a sufficient number of association errors (lack of responses = from the peer) to bring down the association (the peer clearly had not = experienced that many errors since it kept the assoc up). >=20 > What confuses me is that I would expect SCTP to send an ABORT when = this happens; other implementations with which I am familiar do. >=20 > In re-reading the RFC, the relevant section doesn't explicitly mention = sending an ABORT: >=20 > ~~~ > 8.1. Endpoint Failure Detection > An endpoint shall keep a counter on the total number of consecutive > retransmissions to its peer (this includes retransmissions to all the > destination transport addresses of the peer if it is multi-homed), > including unacknowledged HEARTBEAT chunks. If the value of this > counter exceeds the limit indicated in the protocol parameter > =92Association.Max.Retrans=92, the endpoint shall consider the peer > endpoint unreachable and shall stop transmitting any more data to it > (and thus the association enters the CLOSED state). In addition, the > endpoint MAY report the failure to the upper layer and optionally > report back all outstanding user data remaining in its outbound > queue. The association is automatically closed when the peer > endpoint becomes unreachable > ~~~ >=20 > But I think that such an association closure is certainly an = ungraceful one and thus section 9.1 applies: >=20 > ~~~ > 9.1. Abort of an Association >=20 > When an endpoint decides to abort an existing association, it MUST > send an ABORT chunk to its peer endpoint. The sender MUST fill = in... > ~~~ >=20 > Would you agree? If so, would a clarification be useful in section = 8.1? >=20 > Personally I think that an ABORT must be sent in such situations so = that the peer can be aware of the situation (before a subsequent message = or heartbeat from the peer finally provokes an ABORT); in my case the = peer could easily have re-established the association before it came = time to send the message which my system treated as OOTB. >=20 > Regards, > -Jeff >=20 ----- Randall Stewart randall@lakerest.net From cbenson@adax.com Thu Nov 1 14:47:51 2012 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 1D3F921F927B for ; Thu, 1 Nov 2012 14:47:51 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrXjfJjxeMQ7 for ; Thu, 1 Nov 2012 14:47:50 -0700 (PDT) Received: from mail1.adax.com (mail1.adax.com [70.36.226.176]) by ietfa.amsl.com (Postfix) with ESMTP id 22F8E21F94EC for ; Thu, 1 Nov 2012 14:47:50 -0700 (PDT) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id CB9881E1121; Thu, 1 Nov 2012 14:47:49 -0700 (PDT) Received: by adax (Postfix, from userid 243) id BE76F8EDE6; Thu, 1 Nov 2012 14:47:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id B8CDD8EDE5; Thu, 1 Nov 2012 14:47:49 -0700 (PDT) Date: Thu, 1 Nov 2012 14:47:49 -0700 (PDT) From: Chris Benson X-X-Sender: cbenson@adax.adax To: Jeff Morriss In-Reply-To: <5092940A.2010805@gmail.com> Message-ID: References: <5092940A.2010805@gmail.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="808960-667497092-1351805151=:15687" Content-ID: Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] SCTP: abort after excessive errors? 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, 01 Nov 2012 21:47:51 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --808960-667497092-1351805151=:15687 Content-Type: TEXT/PLAIN; CHARSET=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Jeff, As stated at the beginning of Section 8.1, this error condition is reached when there has been no response in the last N retransmission periods, and as you quoted ... "[this] endpoint shall consider the peer endpoint unreachable" I am sure it is this logic that suggests that an ABORT message=20 won't get there either, though there's probably little harm in trying. To address your concern at the lack of notification, the remote=20 peer will (!) notice that this side has disappeared, by reaching=20 the same condition at least due to unacknowledged SCTP=20 HEARTBEATs if no DATA is being transmitted. The local=20 application will (!) be informed by the compulsory indication issed by the local SCTP as described in RFC 4960 Section 10.2.=20 E) "COMMUNICATION LOST notification" to the local Upper Layer Protocol. With best regards, from Chris Benson. On Thu, 1 Nov 2012, Jeff Morriss wrote: >> Date: Thu, 01 Nov 2012 11:23:54 -0400 >> From: Jeff Morriss >> To: "tsvwg@ietf.org" >> Subject: [tsvwg] SCTP: abort after excessive errors? >> =20 >> Hi list, >> =20 >> I recently had a problem at an interop event where my system was respon= ding >> to message from an SCTP peer with an ABORT. A little analysis showed m= e the >> problem: >> =20 >> - the T-bit was set in the ABORT >> - (and, after more digging) the application had received notification t= hat >> the association in question had been closed some time before >> =20 >> So my local SCTP had torn down the association but neither I (looking i= n >> Wireshark but not at the application logs) nor the peer were made aware= of >> it. >> =20 >> More analysis in Wireshark showed that my system's SCTP had experienced= a >> sufficient number of association errors (lack of responses from the pee= r) to >> bring down the association (the peer clearly had not experienced that m= any >> errors since it kept the assoc up). >> =20 >> What confuses me is that I would expect SCTP to send an ABORT when this >> happens; other implementations with which I am familiar do. >> =20 >> In re-reading the RFC, the relevant section doesn't explicitly mention >> sending an ABORT: >> =20 >> ~ ~ ~ >> 8.1. Endpoint Failure Detection >> An endpoint shall keep a counter on the total number of consecutive >> retransmissions to its peer (this includes retransmissions to all the >> destination transport addresses of the peer if it is multi-homed), >> including unacknowledged HEARTBEAT chunks. If the value of this >> counter exceeds the limit indicated in the protocol parameter >> =E2=80=99Association.Max.Retrans=E2=80=99, the endpoint shall consider= the peer >> endpoint unreachable and shall stop transmitting any more data to it >> (and thus the association enters the CLOSED state). In addition, the >> endpoint MAY report the failure to the upper layer and optionally >> report back all outstanding user data remaining in its outbound >> queue. The association is automatically closed when the peer >> endpoint becomes unreachable >> ~ ~ ~ >> =20 >> But I think that such an association closure is certainly an ungraceful= one >> and thus section 9.1 applies: >> =20 >> ~ ~ ~ >> 9.1. Abort of an Association >> =20 >> When an endpoint decides to abort an existing association, it MUST >> send an ABORT chunk to its peer endpoint. The sender MUST fill in..= =2E >> ~ ~ ~ >> =20 >> Would you agree? If so, would a clarification be useful in section 8.1= ? >> =20 >> Personally I think that an ABORT must be sent in such situations so tha= t the >> peer can be aware of the situation (before a subsequent message or hear= tbeat >> from the peer finally provokes an ABORT); in my case the peer could eas= ily >> have re-established the association before it came time to send the mes= sage >> which my system treated as OOTB. >> =20 >> Regards, >> -Jeff >> =20 --808960-667497092-1351805151=:15687-- From jeff.morriss.ws@gmail.com Thu Nov 1 15:56:44 2012 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 CBB6421F9606 for ; Thu, 1 Nov 2012 15:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbh8OuCavxbe for ; Thu, 1 Nov 2012 15:56:44 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0156A21F9602 for ; Thu, 1 Nov 2012 15:56:43 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3583596vcb.31 for ; Thu, 01 Nov 2012 15:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+I8HQa4tD5pLxg5vLsRfvAJIpD8vDUd5fTNo4PJqyTo=; b=JIDvSY83OfnpZ71KxMydRxBx36v0Sj7jvTdXzQ6hofKuH5xcs+fGPzeAq/tJBgru8M uOI0FkBTRxdaNeQEj/wxMnKhH4/7BSZAXmU2AAWuHBhC+SVG5bVLHAmoxOXhteyIDj4s d62lnWBt+wcOoFhItURKWQOXdRs7OZEBvUVVDOJfAEYAoFsguxstFC0bReYn90SDQq5D +CE5jUeGkNNhQlAf2HfDWZWokRkZwkTP0jWW8XRAPJ3ipSucAlTWWgNiWM9GliXbJzul jp+IzDLDOchSb6e7buGQ2jjXCjpVtDbeeOir3RqdVKA10/h8dHiXFZy7eMlDQo0P5Tx8 1ZSw== Received: by 10.52.92.11 with SMTP id ci11mr52218584vdb.7.1351810603429; Thu, 01 Nov 2012 15:56:43 -0700 (PDT) Received: from nj-morriss-test.ulticom.com ([74.8.208.5]) by mx.google.com with ESMTPS id b8sm4322523veq.1.2012.11.01.15.56.42 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Nov 2012 15:56:42 -0700 (PDT) Message-ID: <5092FE27.7030407@gmail.com> Date: Thu, 01 Nov 2012 18:56:39 -0400 From: Jeff Morriss User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Chris Benson References: <5092940A.2010805@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] SCTP: abort after excessive errors? 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, 01 Nov 2012 22:56:44 -0000 Hi Chris, In this particular case the peer was not down (and neither was the network) there was simply "excessive" packet loss between the two (I think the network was overloaded--certainly not by this association). My system's SCTP had the *bad luck* to see N consecutive failures (retransmissions and/or lack of heartbeat acknowledgements) but the peer obviously did not: it kept the association up and sent us another data packet long (seconds or 10's or seconds?--nuts, where did that capture file go?) after my system tore down the association. I understand that after N consecutive failures the chances of the ABORT making it may not be that great but the peer was able--after it got the ABORT we did send--to immediately reestablish the association. Regards, -Jeff Chris Benson wrote: > Jeff, > > As stated at the beginning of Section 8.1, this error condition > is reached when there has been no response in the last N > retransmission periods, and as you quoted ... > > "[this] endpoint shall consider the peer endpoint unreachable" > > I am sure it is this logic that suggests that an ABORT message > won't get there either, though there's probably little harm in > trying. > > To address your concern at the lack of notification, the remote > peer will (!) notice that this side has disappeared, by reaching > the same condition at least due to unacknowledged SCTP > HEARTBEATs if no DATA is being transmitted. The local > application will (!) be informed by the compulsory indication > issed by the local SCTP as described in RFC 4960 Section 10.2. > E) "COMMUNICATION LOST notification" to the local Upper Layer > Protocol. > > With best regards, from Chris Benson. > > On Thu, 1 Nov 2012, Jeff Morriss wrote: > >>> Date: Thu, 01 Nov 2012 11:23:54 -0400 >>> From: Jeff Morriss >>> To: "tsvwg@ietf.org" >>> Subject: [tsvwg] SCTP: abort after excessive errors? >>> >>> Hi list, >>> >>> I recently had a problem at an interop event where my system was responding >>> to message from an SCTP peer with an ABORT. A little analysis showed me the >>> problem: >>> >>> - the T-bit was set in the ABORT >>> - (and, after more digging) the application had received notification that >>> the association in question had been closed some time before >>> >>> So my local SCTP had torn down the association but neither I (looking in >>> Wireshark but not at the application logs) nor the peer were made aware of >>> it. >>> >>> More analysis in Wireshark showed that my system's SCTP had experienced a >>> sufficient number of association errors (lack of responses from the peer) to >>> bring down the association (the peer clearly had not experienced that many >>> errors since it kept the assoc up). >>> >>> What confuses me is that I would expect SCTP to send an ABORT when this >>> happens; other implementations with which I am familiar do. >>> >>> In re-reading the RFC, the relevant section doesn't explicitly mention >>> sending an ABORT: >>> >>> ~ ~ ~ >>> 8.1. Endpoint Failure Detection >>> An endpoint shall keep a counter on the total number of consecutive >>> retransmissions to its peer (this includes retransmissions to all the >>> destination transport addresses of the peer if it is multi-homed), >>> including unacknowledged HEARTBEAT chunks. If the value of this >>> counter exceeds the limit indicated in the protocol parameter >>> ’Association.Max.Retrans’, the endpoint shall consider the peer >>> endpoint unreachable and shall stop transmitting any more data to it >>> (and thus the association enters the CLOSED state). In addition, the >>> endpoint MAY report the failure to the upper layer and optionally >>> report back all outstanding user data remaining in its outbound >>> queue. The association is automatically closed when the peer >>> endpoint becomes unreachable >>> ~ ~ ~ >>> >>> But I think that such an association closure is certainly an ungraceful one >>> and thus section 9.1 applies: >>> >>> ~ ~ ~ >>> 9.1. Abort of an Association >>> >>> When an endpoint decides to abort an existing association, it MUST >>> send an ABORT chunk to its peer endpoint. The sender MUST fill in... >>> ~ ~ ~ >>> >>> Would you agree? If so, would a clarification be useful in section 8.1? >>> >>> Personally I think that an ABORT must be sent in such situations so that the >>> peer can be aware of the situation (before a subsequent message or heartbeat >>> from the peer finally provokes an ABORT); in my case the peer could easily >>> have re-established the association before it came time to send the message >>> which my system treated as OOTB. >>> >>> Regards, >>> -Jeff >>> From lei.zhu@huawei.com Thu Nov 1 16:06:25 2012 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 D83F621F97E7 for ; Thu, 1 Nov 2012 16:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.845 X-Spam-Level: X-Spam-Status: No, score=-4.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9AruHdguXrm for ; Thu, 1 Nov 2012 16:06:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C68A921F97E8 for ; Thu, 1 Nov 2012 16:06:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMG74280; Thu, 01 Nov 2012 23:06:14 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 1 Nov 2012 23:00:21 +0000 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 1 Nov 2012 23:00:56 +0000 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.86]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 2 Nov 2012 07:00:43 +0800 From: Zhulei To: "jmpolk@cisco.com" , "gorry@erg.abdn.ac.uk" Thread-Topic: Request of tsvwg meeting in next week Thread-Index: Ac24g8GIBA2tAAkCS7ae90i/Fp+Blw== Date: Thu, 1 Nov 2012 23:00:43 +0000 Message-ID: <470F27D1263A1B4EB73491ED995DE625249BFD6A@szxeml504-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.218] Content-Type: multipart/alternative; boundary="_000_470F27D1263A1B4EB73491ED995DE625249BFD6Aszxeml504mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "tsvwg@ietf.org" Subject: [tsvwg] Request of tsvwg meeting in next week 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, 01 Nov 2012 23:06:26 -0000 --_000_470F27D1263A1B4EB73491ED995DE625249BFD6Aszxeml504mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSmFtZXMgYW5kIGFsbCwNCg0KDQoNClRoZSBkcmFmdCBvZiB1cyB3YXMgZ2V0dGluZyB0aW1l IHNsb3RzIG9mIDE1IG1pbnV0ZXMgb2YgSUVURiA4NXRoIG1lZXRpbmcsIGJ5IGUtbWFpbCBzZW50 IHRvIENoYWlyLiBUaGUgZHJhZnQgaXMgbGlua2VkIGJlbG93OiBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC16aGFuZy10c3Z3Zy10dW5uZWwtY29uZ2VzdGlvbi1leHBvc3VyZS0wMCAu DQoNCg0KDQpFLW1haWwgY291bGQgYmUgbG9zdCBvciBpZ25vcmVkIGJ5IHN5c3RlbSwgc28gc2Vu dCByZXF1ZXN0IG9mIHNsb3QgdG8geW91IHdpdGggZm9sbG93aW5nIHByZXNlbnRlciBpbmZvcm1h dGlvbi4NCg0KDQoNCkJlc3QgcmVnYXJkcywNCg0KWmh1IExlaQ0K --_000_470F27D1263A1B4EB73491ED995DE625249BFD6Aszxeml504mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable --_000_470F27D1263A1B4EB73491ED995DE625249BFD6Aszxeml504mbxchi_-- From cbenson@adax.com Thu Nov 1 16:40:00 2012 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 83BAC21F9832 for ; Thu, 1 Nov 2012 16:40:00 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfTdIIqf+gz2 for ; Thu, 1 Nov 2012 16:39:59 -0700 (PDT) Received: from mail1.adax.com (mail1.adax.com [70.36.226.176]) by ietfa.amsl.com (Postfix) with ESMTP id 9523521F9831 for ; Thu, 1 Nov 2012 16:39:59 -0700 (PDT) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id 53FAE1E10D3; Thu, 1 Nov 2012 16:39:59 -0700 (PDT) Received: by adax (Postfix, from userid 243) id 470728EDE6; Thu, 1 Nov 2012 16:39:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id 3DA7B8EDE5; Thu, 1 Nov 2012 16:39:59 -0700 (PDT) Date: Thu, 1 Nov 2012 16:39:59 -0700 (PDT) From: Chris Benson X-X-Sender: cbenson@adax.adax To: Jeff Morriss In-Reply-To: <5092FE27.7030407@gmail.com> Message-ID: References: <5092940A.2010805@gmail.com> <5092FE27.7030407@gmail.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="808960-1214224769-1351813199=:15687" Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] SCTP: abort after excessive errors? 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, 01 Nov 2012 23:40:00 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --808960-1214224769-1351813199=:15687 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Jeff, There are current efforts to improve SCTP failover and I haven't been able to follow them closely. Perhaps others on this list could suggest if these new practices could show improvement in=20 your "almost unusable" network conditions. I understand your frustration. SCTP doesn't do well in such=20 network conditions. If the packets were just being delayed (not lost forever), then you could set RTO to be longer, but=20 then it would take correspondingly longer to notice any actual loss of a peer. The same applies to any effort to increase the value of Association.Max.Retrans (N) to handle truly dropped packets. As network delays start to exceed RTO, SCTP of course INCREASES=20 its network usage (with frequent retransmissions), often making=20 bad conditions worse. To be very specific about sending an ABORT in this circumstance, Section 8.1 describes an automatic (instant and silent) closure=20 of the association. This is not the same as the SCTP meaning of=20 ABORTing an association described in Section 9.1. I think Randy Stewart observed that an implementation MAY send an ABORT message in this scenario. Your preference for a MUST here would only cover your scenario where it could be argued that the SCTP endpoints are not correctly configured for the=20 network condition actually encountered. SCTP does really well when multi-homed on actually distinct networks (and when at least one network has a decent chance of getting a packet through fairly often). A potential chance of improvement might lie in metering the=20 application data to avoid bursts. This might significantly lessen the chance of suffering N consecutive dropped packets. In a non-SCTP context, this helped me greatly one time - the=20 data metering was the accidental result of modifying UDP packets en route. By metering, I mean evening out the time gap between consecutive packets rather than sending many "at=20 once" followed by a significant silence. Chris Benson. On Thu, 1 Nov 2012, Jeff Morriss wrote: >> Date: Thu, 01 Nov 2012 18:56:39 -0400 >> From: Jeff Morriss >> To: Chris Benson >> Cc: "tsvwg@ietf.org" >> Subject: Re: [tsvwg] SCTP: abort after excessive errors? >> =20 >> Hi Chris, >> =20 >> In this particular case the peer was not down (and neither was the netw= ork) >> there was simply "excessive" packet loss between the two (I think the >> network was overloaded--certainly not by this association). My system's= SCTP >> had the *bad luck* to see N consecutive failures (retransmissions and/o= r >> lack of heartbeat acknowledgements) but the peer obviously did not: it = kept >> the association up and sent us another data packet long (seconds or 10'= s or >> seconds?--nuts, where did that capture file go?) after my system tore d= own >> the association. >> =20 >> I understand that after N consecutive failures the chances of the ABORT >> making it may not be that great but the peer was able--after it got the >> ABORT we did send--to immediately reestablish the association. >> =20 >> Regards, >> -Jeff >> =20 >> Chris Benson wrote: >> > Jeff, >> >=20 >> > As stated at the beginning of Section 8.1, this error condition >> > is reached when there has been no response in the last N >> > retransmission periods, and as you quoted ... >> >=20 >> > "[this] endpoint shall consider the peer endpoint unreachable" >> >=20 >> > I am sure it is this logic that suggests that an ABORT message won't = get >> > there either, though there's probably little harm in >> > trying. >> >=20 >> > To address your concern at the lack of notification, the remote peer = will >> > (!) notice that this side has disappeared, by reaching the same condi= tion >> > at least due to unacknowledged SCTP HEARTBEATs if no DATA is being >> > transmitted. The local application will (!) be informed by the compul= sory >> > indication >> > issed by the local SCTP as described in RFC 4960 Section 10.2. E) >> > "COMMUNICATION LOST notification" to the local Upper Layer >> > Protocol. >> >=20 >> > With best regards, from Chris Benson. >> >=20 >> > On Thu, 1 Nov 2012, Jeff Morriss wrote: >> >=20 >> > > > Date: Thu, 01 Nov 2012 11:23:54 -0400 >> > > > From: Jeff Morriss >> > > > To: "tsvwg@ietf.org" >> > > > Subject: [tsvwg] SCTP: abort after excessive errors? >> > > > =20 >> > > > Hi list, >> > > > =20 >> > > > I recently had a problem at an interop event where my system was >> > > > responding >> > > > to message from an SCTP peer with an ABORT. A little analysis s= howed >> > > > me the >> > > > problem: >> > > > =20 >> > > > - the T-bit was set in the ABORT >> > > > - (and, after more digging) the application had received notific= ation >> > > > that >> > > > the association in question had been closed some time before >> > > > =20 >> > > > So my local SCTP had torn down the association but neither I (lo= oking >> > > > in >> > > > Wireshark but not at the application logs) nor the peer were mad= e >> > > > aware of >> > > > it. >> > > > =20 >> > > > More analysis in Wireshark showed that my system's SCTP had >> > > > experienced a >> > > > sufficient number of association errors (lack of responses from = the >> > > > peer) to >> > > > bring down the association (the peer clearly had not experienced= that >> > > > many >> > > > errors since it kept the assoc up). >> > > > =20 >> > > > What confuses me is that I would expect SCTP to send an ABORT wh= en >> > > > this >> > > > happens; other implementations with which I am familiar do. >> > > > =20 >> > > > In re-reading the RFC, the relevant section doesn't explicitly >> > > > mention >> > > > sending an ABORT: >> > > > =20 >> > > > ~ ~ ~ >> > > > 8.1. Endpoint Failure Detection >> > > > An endpoint shall keep a counter on the total number of consecu= tive >> > > > retransmissions to its peer (this includes retransmissions to a= ll >> > > > the >> > > > destination transport addresses of the peer if it is multi-home= d), >> > > > including unacknowledged HEARTBEAT chunks. If the value of this >> > > > counter exceeds the limit indicated in the protocol parameter >> > > > =E2=80=99Association.Max.Retrans=E2=80=99, the endpoint shall c= onsider the peer >> > > > endpoint unreachable and shall stop transmitting any more data = to it >> > > > (and thus the association enters the CLOSED state). In addition= , the >> > > > endpoint MAY report the failure to the upper layer and optional= ly >> > > > report back all outstanding user data remaining in its outbound >> > > > queue. The association is automatically closed when the peer >> > > > endpoint becomes unreachable >> > > > ~ ~ ~ >> > > > =20 >> > > > But I think that such an association closure is certainly an >> > > > ungraceful one >> > > > and thus section 9.1 applies: >> > > > =20 >> > > > ~ ~ ~ >> > > > 9.1. Abort of an Association >> > > > =20 >> > > > When an endpoint decides to abort an existing association, it= MUST >> > > > send an ABORT chunk to its peer endpoint. The sender MUST fi= ll >> > > > in... >> > > > ~ ~ ~ >> > > > =20 >> > > > Would you agree? If so, would a clarification be useful in sect= ion >> > > > 8.1? >> > > > =20 >> > > > Personally I think that an ABORT must be sent in such situations= so >> > > > that the >> > > > peer can be aware of the situation (before a subsequent message = or >> > > > heartbeat >> > > > from the peer finally provokes an ABORT); in my case the peer co= uld >> > > > easily >> > > > have re-established the association before it came time to send = the >> > > > message >> > > > which my system treated as OOTB. >> > > > =20 >> > > > Regards, >> > > > -Jeff >> > > > =20 >> =20 --808960-1214224769-1351813199=:15687-- From bidulock@openss7.org Thu Nov 1 20:58:30 2012 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 F331321F91B5 for ; Thu, 1 Nov 2012 20:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.722 X-Spam-Level: X-Spam-Status: No, score=-5.722 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_DUL=0.877] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtAPTqV5yIRq for ; Thu, 1 Nov 2012 20:58:28 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [142.59.210.7]) by ietfa.amsl.com (Postfix) with ESMTP id 5639021F8CCC for ; Thu, 1 Nov 2012 20:58:27 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id qA23wPc7022347; Thu, 1 Nov 2012 21:58:25 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id qA23wOd7022851; Thu, 1 Nov 2012 21:58:24 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id qA23wNoQ022850; Thu, 1 Nov 2012 21:58:23 -0600 Date: Thu, 1 Nov 2012 21:58:23 -0600 From: "Brian F. G. Bidulock" To: Randy Stewart Message-ID: <20121102035823.GA13133@openss7.org> Mail-Followup-To: Randy Stewart , Jeff Morriss , "tsvwg@ietf.org" References: <5092940A.2010805@gmail.com> <08A63E33-058E-4295-9FC3-95D0991B3F22@lakerest.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <08A63E33-058E-4295-9FC3-95D0991B3F22@lakerest.net> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] SCTP: abort after excessive errors? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 03:58:30 -0000 Randy, I agree, it doesn't really matter if an ABORT is sent. In Jeff's case, the peer (still thinking the association is operational) should continue to send heartbeats even if it has no data to send and will either mark the association down if enough heartbeats get lost, or when the side that has marked the association failed responds with a T-ABORT to a received heartbeat. SCTP is not as responsive to error conditions when the user data is only flowing in one direction. The peer with nothing to send can only rely on heartbeats or other data (such as ARP failures or ICMP) to detect failures. As you say, the ABORT might no make it through either, but the heartbeat mechanism will fail the non-sending peer anyway. If one needs more responsiveness in this situation, reducing the heartbeat interval at the non-sending peer is a good way of restoring the responsiveness that would be acheived by the sending peer. --brian Randy Stewart wrote: (Thu, 01 Nov 2012 17:21:29) > Jeff: > > No I don't know if I do agree. I don't think you are required to in TCP either. I > do think that *many* implementations (both TCP and SCTP) do this. But lets think > about this, its quite possible the host is unreachable and adding yet another > packet to the network does not gain anything … yes its small … but it is one more > packet. > > I think that is why the wording is left loose so that implementations have a choice. Most > do send the ABORT, but not all do. I prefer that this remain an implementation choice… but > I would be glad to hear other opinions.. > > R > On Nov 1, 2012, at 11:23 AM, Jeff Morriss wrote: > > > Hi list, > > > > I recently had a problem at an interop event where my system was responding to message from an SCTP peer with an ABORT. A little analysis showed me the problem: > > > > - the T-bit was set in the ABORT > > - (and, after more digging) the application had received notification that the association in question had been closed some time before > > > > So my local SCTP had torn down the association but neither I (looking in Wireshark but not at the application logs) nor the peer were made aware of it. > > > > More analysis in Wireshark showed that my system's SCTP had experienced a sufficient number of association errors (lack of responses from the peer) to bring down the association (the peer clearly had not experienced that many errors since it kept the assoc up). > > > > What confuses me is that I would expect SCTP to send an ABORT when this happens; other implementations with which I am familiar do. > > > > In re-reading the RFC, the relevant section doesn't explicitly mention sending an ABORT: > > > > ~~~ > > 8.1. Endpoint Failure Detection > > An endpoint shall keep a counter on the total number of consecutive > > retransmissions to its peer (this includes retransmissions to all the > > destination transport addresses of the peer if it is multi-homed), > > including unacknowledged HEARTBEAT chunks. If the value of this > > counter exceeds the limit indicated in the protocol parameter > > ’Association.Max.Retrans’, the endpoint shall consider the peer > > endpoint unreachable and shall stop transmitting any more data to it > > (and thus the association enters the CLOSED state). In addition, the > > endpoint MAY report the failure to the upper layer and optionally > > report back all outstanding user data remaining in its outbound > > queue. The association is automatically closed when the peer > > endpoint becomes unreachable > > ~~~ > > > > But I think that such an association closure is certainly an ungraceful one and thus section 9.1 applies: > > > > ~~~ > > 9.1. Abort of an Association > > > > When an endpoint decides to abort an existing association, it MUST > > send an ABORT chunk to its peer endpoint. The sender MUST fill in... > > ~~~ > > > > Would you agree? If so, would a clarification be useful in section 8.1? > > > > Personally I think that an ABORT must be sent in such situations so that the peer can be aware of the situation (before a subsequent message or heartbeat from the peer finally provokes an ABORT); in my case the peer could easily have re-established the association before it came time to send the message which my system treated as OOTB. > > > > Regards, > > -Jeff > > > > ----- > Randall Stewart > randall@lakerest.net > > > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From randall@lakerest.net Fri Nov 2 05:48:58 2012 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 45A8421F884A for ; Fri, 2 Nov 2012 05:48:58 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HChp3Ra7e2v for ; Fri, 2 Nov 2012 05:48:57 -0700 (PDT) Received: from lakerest.net (lakerest.net [70.155.160.98]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACCA21F843C for ; Fri, 2 Nov 2012 05:48:55 -0700 (PDT) Received: from [10.1.1.101] (bsd4.lakerest.net [70.155.160.102]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id qA2CmrmK029693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 2 Nov 2012 08:48:53 -0400 (EDT) (envelope-from randall@lakerest.net) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Randy Stewart In-Reply-To: Date: Fri, 2 Nov 2012 08:48:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <223E333F-3AD2-4A94-B3F0-0894F48C1ADF@lakerest.net> References: <5092940A.2010805@gmail.com> <5092FE27.7030407@gmail.com> To: Chris Benson X-Mailer: Apple Mail (2.1283) Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] SCTP: abort after excessive errors? 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, 02 Nov 2012 12:48:58 -0000 Chris: One comment on this ;-) On Nov 1, 2012, at 7:39 PM, Chris Benson wrote: > Jeff, >=20 > There are current efforts to improve SCTP failover and I haven't > been able to follow them closely. Perhaps others on this list > could suggest if these new practices could show improvement in=20 > your "almost unusable" network conditions. >=20 > I understand your frustration. SCTP doesn't do well in such=20 > network conditions. If the packets were just being delayed > (not lost forever), then you could set RTO to be longer, but=20 > then it would take correspondingly longer to notice any > actual loss of a peer. The same applies to any effort to > increase the value of Association.Max.Retrans (N) to handle > truly dropped packets. >=20 > As network delays start to exceed RTO, SCTP of course INCREASES=20 > its network usage (with frequent retransmissions), often making=20 > bad conditions worse. >=20 > To be very specific about sending an ABORT in this circumstance, > Section 8.1 describes an automatic (instant and silent) closure=20 > of the association. This is not the same as the SCTP meaning of=20 > ABORTing an association described in Section 9.1. I think > Randy Stewart observed that an implementation MAY send an > ABORT message in this scenario. Your preference for a MUST > here would only cover your scenario where it could be argued > that the SCTP endpoints are not correctly configured for the=20 > network condition actually encountered. >=20 > SCTP does really well when multi-homed on actually distinct > networks (and when at least one network has a decent chance > of getting a packet through fairly often). >=20 > A potential chance of improvement might lie in metering the=20 > application data to avoid bursts. This might significantly > lessen the chance of suffering N consecutive dropped packets. > In a non-SCTP context, this helped me greatly one time - the=20 > data metering was the accidental result of modifying UDP packets > en route. By metering, I mean evening out the time gap > between consecutive packets rather than sending many "at=20 > once" followed by a significant silence. >=20 SCTP in FreeBSD has had max_burst (defaulting to 4 packets) for years = for this very issue. I did not realize how effective in loaded network conditions = this is until I actually was playing with TCP in FreeBSD (which does not have = this yet), and I put it in. It was amazing the difference in network conditions even with the same = load by simply having the max-burst set to 4.=20 Its not a panacea by any stretch, but in situations like this = (overloaded networks) there really is *no* such thing. You can only make small incremental improvements, = network wide, to try to help the situation.. R > Chris Benson. >=20 > On Thu, 1 Nov 2012, Jeff Morriss wrote: >=20 >>> Date: Thu, 01 Nov 2012 18:56:39 -0400 >>> From: Jeff Morriss >>> To: Chris Benson >>> Cc: "tsvwg@ietf.org" >>> Subject: Re: [tsvwg] SCTP: abort after excessive errors? >>>=20 >>> Hi Chris, >>>=20 >>> In this particular case the peer was not down (and neither was the = network) >>> there was simply "excessive" packet loss between the two (I think = the >>> network was overloaded--certainly not by this association). My = system's SCTP >>> had the *bad luck* to see N consecutive failures (retransmissions = and/or >>> lack of heartbeat acknowledgements) but the peer obviously did not: = it kept >>> the association up and sent us another data packet long (seconds or = 10's or >>> seconds?--nuts, where did that capture file go?) after my system = tore down >>> the association. >>>=20 >>> I understand that after N consecutive failures the chances of the = ABORT >>> making it may not be that great but the peer was able--after it got = the >>> ABORT we did send--to immediately reestablish the association. >>>=20 >>> Regards, >>> -Jeff >>>=20 >>> Chris Benson wrote: >>>> Jeff, >>>>=20 >>>> As stated at the beginning of Section 8.1, this error condition >>>> is reached when there has been no response in the last N >>>> retransmission periods, and as you quoted ... >>>>=20 >>>> "[this] endpoint shall consider the peer endpoint unreachable" >>>>=20 >>>> I am sure it is this logic that suggests that an ABORT message = won't get >>>> there either, though there's probably little harm in >>>> trying. >>>>=20 >>>> To address your concern at the lack of notification, the remote = peer will >>>> (!) notice that this side has disappeared, by reaching the same = condition >>>> at least due to unacknowledged SCTP HEARTBEATs if no DATA is being >>>> transmitted. The local application will (!) be informed by the = compulsory >>>> indication >>>> issed by the local SCTP as described in RFC 4960 Section 10.2. E) >>>> "COMMUNICATION LOST notification" to the local Upper Layer >>>> Protocol. >>>>=20 >>>> With best regards, from Chris Benson. >>>>=20 >>>> On Thu, 1 Nov 2012, Jeff Morriss wrote: >>>>=20 >>>>>> Date: Thu, 01 Nov 2012 11:23:54 -0400 >>>>>> From: Jeff Morriss >>>>>> To: "tsvwg@ietf.org" >>>>>> Subject: [tsvwg] SCTP: abort after excessive errors? >>>>>>=20 >>>>>> Hi list, >>>>>>=20 >>>>>> I recently had a problem at an interop event where my system was >>>>>> responding >>>>>> to message from an SCTP peer with an ABORT. A little analysis = showed >>>>>> me the >>>>>> problem: >>>>>>=20 >>>>>> - the T-bit was set in the ABORT >>>>>> - (and, after more digging) the application had received = notification >>>>>> that >>>>>> the association in question had been closed some time before >>>>>>=20 >>>>>> So my local SCTP had torn down the association but neither I = (looking >>>>>> in >>>>>> Wireshark but not at the application logs) nor the peer were made >>>>>> aware of >>>>>> it. >>>>>>=20 >>>>>> More analysis in Wireshark showed that my system's SCTP had >>>>>> experienced a >>>>>> sufficient number of association errors (lack of responses from = the >>>>>> peer) to >>>>>> bring down the association (the peer clearly had not experienced = that >>>>>> many >>>>>> errors since it kept the assoc up). >>>>>>=20 >>>>>> What confuses me is that I would expect SCTP to send an ABORT = when >>>>>> this >>>>>> happens; other implementations with which I am familiar do. >>>>>>=20 >>>>>> In re-reading the RFC, the relevant section doesn't explicitly >>>>>> mention >>>>>> sending an ABORT: >>>>>>=20 >>>>>> ~ ~ ~ >>>>>> 8.1. Endpoint Failure Detection >>>>>> An endpoint shall keep a counter on the total number of = consecutive >>>>>> retransmissions to its peer (this includes retransmissions to = all >>>>>> the >>>>>> destination transport addresses of the peer if it is = multi-homed), >>>>>> including unacknowledged HEARTBEAT chunks. If the value of this >>>>>> counter exceeds the limit indicated in the protocol parameter >>>>>> =92Association.Max.Retrans=92, the endpoint shall consider the = peer >>>>>> endpoint unreachable and shall stop transmitting any more data = to it >>>>>> (and thus the association enters the CLOSED state). In addition, = the >>>>>> endpoint MAY report the failure to the upper layer and = optionally >>>>>> report back all outstanding user data remaining in its outbound >>>>>> queue. The association is automatically closed when the peer >>>>>> endpoint becomes unreachable >>>>>> ~ ~ ~ >>>>>>=20 >>>>>> But I think that such an association closure is certainly an >>>>>> ungraceful one >>>>>> and thus section 9.1 applies: >>>>>>=20 >>>>>> ~ ~ ~ >>>>>> 9.1. Abort of an Association >>>>>>=20 >>>>>> When an endpoint decides to abort an existing association, it = MUST >>>>>> send an ABORT chunk to its peer endpoint. The sender MUST = fill >>>>>> in... >>>>>> ~ ~ ~ >>>>>>=20 >>>>>> Would you agree? If so, would a clarification be useful in = section >>>>>> 8.1? >>>>>>=20 >>>>>> Personally I think that an ABORT must be sent in such situations = so >>>>>> that the >>>>>> peer can be aware of the situation (before a subsequent message = or >>>>>> heartbeat >>>>>> from the peer finally provokes an ABORT); in my case the peer = could >>>>>> easily >>>>>> have re-established the association before it came time to send = the >>>>>> message >>>>>> which my system treated as OOTB. >>>>>>=20 >>>>>> Regards, >>>>>> -Jeff >>>>>>=20 ----- Randall Stewart randall@lakerest.net From jeff.morriss.ws@gmail.com Fri Nov 2 14:25:05 2012 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 B807D11E80E6 for ; Fri, 2 Nov 2012 14:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2B8MUkakaRw6 for ; Fri, 2 Nov 2012 14:25:05 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 145AD11E80E1 for ; Fri, 2 Nov 2012 14:25:04 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id b25so2983051qca.31 for ; Fri, 02 Nov 2012 14:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=yjbcyIyDtICKUzQhcVWPMGnt8YgYIH94C9/gXLrg1oY=; b=QO0BKCqCqxMR0mjitCpfGBMQG0Wc1bsKJaODNGjprQVKEMqDsqkbZiJLdpYthBKzX6 kRCUsJT3S5zhG3NJQo++Ueyp0YMtkCTJku5nVPHUkkLr2RhGaadXnSHnkbyiV7X0ubWO vZsIH8XPp4pSy65vAVgwXYhWwW2L5RPOwWj22SGNj1XUPG82PLx6kfXUhF8mEkqe9vjD T9yTkk7Lkb6fEP8WH2UGpcHD0BopaKXaBBUCV0+7JHBsE74Z+2g4ECxCJOIWvKVRJ43w gRKhuD1pELwky47XfScH9Tg3bdS6z+0ZekA8sz3EUQEJVp+ZEXUkaB0ng4z1pvMxnVmg 6/7w== Received: by 10.229.176.102 with SMTP id bd38mr972252qcb.76.1351891504493; Fri, 02 Nov 2012 14:25:04 -0700 (PDT) Received: from nj-morriss-test.ulticom.com ([74.8.208.5]) by mx.google.com with ESMTPS id c9sm4605474qeh.1.2012.11.02.14.25.02 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 14:25:03 -0700 (PDT) Message-ID: <50943A2E.30201@gmail.com> Date: Fri, 02 Nov 2012 17:25:02 -0400 From: Jeff Morriss User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: randall@lakerest.net, Chris Benson References: <5092940A.2010805@gmail.com> <5092FE27.7030407@gmail.com> <223E333F-3AD2-4A94-B3F0-0894F48C1ADF@lakerest.net> In-Reply-To: <223E333F-3AD2-4A94-B3F0-0894F48C1ADF@lakerest.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] SCTP: abort after excessive errors? 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, 02 Nov 2012 21:25:05 -0000 Randy Stewart wrote: > Chris: > > One comment on this ;-) > > > On Nov 1, 2012, at 7:39 PM, Chris Benson wrote: > >> Jeff, >> >> There are current efforts to improve SCTP failover and I haven't >> been able to follow them closely. Perhaps others on this list >> could suggest if these new practices could show improvement in >> your "almost unusable" network conditions. >> >> I understand your frustration. SCTP doesn't do well in such >> network conditions. If the packets were just being delayed >> (not lost forever), then you could set RTO to be longer, but >> then it would take correspondingly longer to notice any >> actual loss of a peer. The same applies to any effort to >> increase the value of Association.Max.Retrans (N) to handle >> truly dropped packets. In fact I don't really mind the fact that the association is bouncing: it's life when you don't control the network and somebody else's traffic is (occasionally) beating the snot out of it. >> A potential chance of improvement might lie in metering the >> application data to avoid bursts. This might significantly >> lessen the chance of suffering N consecutive dropped packets. >> In a non-SCTP context, this helped me greatly one time - the >> data metering was the accidental result of modifying UDP packets >> en route. By metering, I mean evening out the time gap >> between consecutive packets rather than sending many "at >> once" followed by a significant silence. >> > > SCTP in FreeBSD has had max_burst (defaulting to 4 packets) for years for this > very issue. I did not realize how effective in loaded network conditions this is > until I actually was playing with TCP in FreeBSD (which does not have this yet), and > I put it in. > > It was amazing the difference in network conditions even with the same load by > simply having the max-burst set to 4. > > Its not a panacea by any stretch, but in situations like this (overloaded networks) there really > is *no* such thing. You can only make small incremental improvements, network wide, to try > to help the situation.. Just FWIW: in one case that I found (the "problem" happened many times) the path errors were spread out over about 11 seconds (not really a burst). And it really was bad luck that the path errors happened as the peer got a data to us during that time, we responded, and the peer SACKed that data (of course data from the peer does not clear my path/assoc error count). Then 5 seconds passed before the peer sent us another message which we saw as OOTB. From Michael.Tuexen@lurchi.franken.de Fri Nov 2 16:40:14 2012 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 116CB11E8101 for ; Fri, 2 Nov 2012 16:40:14 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5moyEykWMAtt for ; Fri, 2 Nov 2012 16:40:13 -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 81A5E11E8117 for ; Fri, 2 Nov 2012 16:40:12 -0700 (PDT) Received: from [IPv6:2001:df8::64:45f1:bc80:e7ab:8120] (unknown [IPv6:2001:df8:0:64:45f1:bc80:e7ab:8120]) (Authenticated sender: macmic) by drew.franken.de (Postfix) with ESMTP id 809191C0C069E; Sat, 3 Nov 2012 00:40:09 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Michael Tuexen In-Reply-To: <50943A2E.30201@gmail.com> Date: Fri, 2 Nov 2012 19:40:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5092940A.2010805@gmail.com> <5092FE27.7030407@gmail.com> <223E333F-3AD2-4A94-B3F0-0894F48C1ADF@lakerest.net> <50943A2E.30201@gmail.com> To: Jeff Morriss X-Mailer: Apple Mail (2.1283) Cc: "tsvwg@ietf.org" , randall@lakerest.net Subject: Re: [tsvwg] SCTP: abort after excessive errors? 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, 02 Nov 2012 23:40:14 -0000 Hi Jeff, I do understand that you prefer the sending of the ABORT, I actually = agree with you. But I think it is a good way to leave this open (or a "MAY send an = ABORT"), since as Randy indicates, in general it doesn't make sense for the peer to = send another packet, if several before it haven't made it. However, there might be = situations, where the ABORT makes it: 1. Just because it is lucky and doesn't get dropped. 2. Because it is shorter and the other packets were dropped and IP = fragmentation didn't kick in 3. ... But the reason I prefer the sending is that you have some indication on = what is going on in tracefiles... So in summary, I think leaving it open is an acceptable compromise. Best regards Michael On Nov 2, 2012, at 5:25 PM, Jeff Morriss wrote: > Randy Stewart wrote: >> Chris: >> One comment on this ;-) >> On Nov 1, 2012, at 7:39 PM, Chris Benson wrote: >>> Jeff, >>>=20 >>> There are current efforts to improve SCTP failover and I haven't >>> been able to follow them closely. Perhaps others on this list >>> could suggest if these new practices could show improvement in your = "almost unusable" network conditions. >>>=20 >>> I understand your frustration. SCTP doesn't do well in such network = conditions. If the packets were just being delayed >>> (not lost forever), then you could set RTO to be longer, but then it = would take correspondingly longer to notice any >>> actual loss of a peer. The same applies to any effort to >>> increase the value of Association.Max.Retrans (N) to handle >>> truly dropped packets. >=20 > In fact I don't really mind the fact that the association is bouncing: = it's life when you don't control the network and somebody else's traffic = is (occasionally) beating the snot out of it. >=20 >>> A potential chance of improvement might lie in metering the = application data to avoid bursts. This might significantly >>> lessen the chance of suffering N consecutive dropped packets. >>> In a non-SCTP context, this helped me greatly one time - the data = metering was the accidental result of modifying UDP packets >>> en route. By metering, I mean evening out the time gap >>> between consecutive packets rather than sending many "at once" = followed by a significant silence. >>>=20 >> SCTP in FreeBSD has had max_burst (defaulting to 4 packets) for years = for this >> very issue. I did not realize how effective in loaded network = conditions this is >> until I actually was playing with TCP in FreeBSD (which does not have = this yet), and >> I put it in. >> It was amazing the difference in network conditions even with the = same load by >> simply having the max-burst set to 4. Its not a panacea by any = stretch, but in situations like this (overloaded networks) there really >> is *no* such thing. You can only make small incremental improvements, = network wide, to try >> to help the situation.. >=20 > Just FWIW: in one case that I found (the "problem" happened many = times) the path errors were spread out over about 11 seconds (not really = a burst). And it really was bad luck that the path errors happened as = the peer got a data to us during that time, we responded, and the peer = SACKed that data (of course data from the peer does not clear my = path/assoc error count). Then 5 seconds passed before the peer sent us = another message which we saw as OOTB. >=20 From karagian@cs.utwente.nl Sun Nov 4 10:55:04 2012 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 1486421F86DC for ; Sun, 4 Nov 2012 10:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qPl01utqv+k for ; Sun, 4 Nov 2012 10:55:03 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id CBFB521F8698 for ; Sun, 4 Nov 2012 10:55:02 -0800 (PST) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 4 Nov 2012 19:55:02 +0100 Received: from EXMBX01.ad.utwente.nl ([169.254.1.130]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0318.004; Sun, 4 Nov 2012 19:55:00 +0100 From: To: , Thread-Topic: draft-ietf-tsvwg-rsvp-pcn-03 Thread-Index: AQHNuG567zXDhOEf1EmojaHb3rIjiJfaAz+M Date: Sun, 4 Nov 2012 18:55:00 +0000 Message-ID: References: <87644A58-0C27-4F5A-B09B-BD8EC1F9A10A@g11.org.uk> In-Reply-To: <87644A58-0C27-4F5A-B09B-BD8EC1F9A10A@g11.org.uk> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.67.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: anuragb@cisco.com Subject: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-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, 04 Nov 2012 18:55:04 -0000 Hi Ken, Thank you very much! Please see in line! > ________________________________________ > Van: ken carlberg [carlberg@g11.org.uk] > Verzonden: donderdag 1 november 2012 21:21 > To: tsvwg > Cc: anuragb@cisco.com; Karagiannis, G. (EWI) > Onderwerp: draft-ietf-tsvwg-rsvp-pcn-03 > Hi Georgios and Anurag, > I took a look at the draft and overall, it seems fine, though I do have a= few comments. =20 > Mostly for clarification. Georgios: Thanks! > 1) The Introduction dives right into what I would see as background infor= mation. =20 > You need to add some text in the beginning=20 > of Section 1 that tells the reader what you plan to do (ie, leverage RSVP= in=20 > support of PCN) and explain that PCN needs a signaling protocol to comple= te a feedback loop from egress to ingress. Georgios: Good point we will do that! > 2) You need to review the terminology section in more detail. Some of th= e items > in this section are not found anywhere else in the body of the draft (eg= , t_meas). =20 > I would also move the terminology subsection further up in the section be= cause=20 > you start talking about some terms early on and then you define them late= r. Georgios: Good point we will do that! > 3) in some cases, you duplicate the definition of the terminology in the = body of the draft,=20 > and in one instance with some different text/references. I think once yo= u define the term,=20 > you don't need to define it again. (eg, ingress-egress-aggregate) Georgios: Good point we will do that! > 4) in quite a few places, you defer additional explanation to a particula= r RFC. An example being: > 2.1.3. Deaggregator (PCN-egress-node) Determination > In this document it is considered that for the determination of= the > Deaggregator, the same methods can be used as the ones describ= ed in > [RFC4860]. > However, you do not point the reader to the specific section within that = reference. =20 > Given how often this is done, I think it would be helpful to be more spec= ific and=20 > identify the section/subsection in that refernce that you are referring t= o. Georgios: Okay, we will also include the relevant section of the referred R= FC! > 5) On page 5, you state the following: > The PCN-egress-nodes measure the rates of differently marked > PCN-traffic in periodic intervals and report these rates to the > decision points for admission control and flow termination, bas= ed on > which they take their decisions. The decision points may be > collocated with the PCN-ingress-nodes or their function may be > implemented in a centralized node. For more details see [RFC555= 9], > [RFC6661], [RFC6662]. In this document it is considered that th= e > decision point is collocated with the PCN-ingress-node. > The last sentence catches my attention because there is no additional rat= ionale stating why you made this decision,=20 > which in itself does not sound like it was made with conviction (its a wr= iting style nit). =20 > I think you need to expand on this. For example, if we were to assume th= at the decision point is a centralized node,=20 > how does this affect the rest of your draft? Georgios: We will try to explain the rationale of why we consider that RSVP= can only be used for the situation that the decision point is collocated with the PCN-ingress-node. The main reason of = this is that in the case that the=20 decision point is collocated with the PCN-ingress-node,the required signali= ng protocol used to complete a=20 feedback loop from egress to ingress can be an entirely on-path protocol, l= ike what RSVP is.=20 In the situation that the the decision point is a centralized node, then th= e required signaling protocol=20 can be a combination of an on-path and off-path protocol. This is because t= he=20 decision point might not be located on the data path! So in this case an ad= ditional signaling protocol will be=20 needed to be specified that covers the signaling between the PCN-egress-nod= e and the centralized node=20 and between PCN-ingress-node and the centralized node. In PCN we decdided to only focus on the specification of the signaling prot= ocol that completes the=20 feedback loop from PCN-egress-node to PCN-ingress-node and to focus on the = signaling protocol=20 used between the edge nodes and the centralized node. This is also the reason of why PCN WG decided to only focus on the situatio= n that the decision point is=20 collocated with the PCN-ingress-node. =20 > 6) This comment is just for you to contemplate -- I'm not expecting any c= hanges. =20 > I noticed that you have a fair number of SHOULD, and some SHOULD NOTs. =20 > And it seems a lot of this is a carry over from rfc-4860, so in a sense y= ou are inheriting an approach that=20 > was agreed to from an earlier effort. But I wonder in the back of my min= d, what impact occurs if=20 > an implementor doesn't follow the SHOULD? Does the design break in suppo= rting PCN? =20 > Again, I want to stress that this isnt a show stopper, but I would apprec= iate it if you gave it some thought. Georgios: Yes, in several cases the design might break in supporting PCN.=20 This is also the reason of using SHOULD instead of MAY. Do you want us to e= xplain this in more detail in the draft? > 7) For the security sections, at a minimum, you should add reference to r= fc-2205 and rfc-4230. =20 > You may also want to add reference to rfc6411. And if the Router Alert O= ption is to be used,=20 > then you may want to look at the Security Section of rfc-6401 for guidanc= e on what to say about RAO Georgios: Thanks for the pointers! We will use them! > -ken Best regards, Georgios= From anuragb@cisco.com Sun Nov 4 17:52:11 2012 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 982EE21F88C6 for ; Sun, 4 Nov 2012 17:52:11 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qMiPNQLgwua for ; Sun, 4 Nov 2012 17:52:10 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 04B2C21F860D for ; Sun, 4 Nov 2012 17:52:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6157; q=dns/txt; s=iport; t=1352080330; x=1353289930; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=yW4d/agxkylAdxaSxoUqKjRXLnAja6ViUiwI3TNx048=; b=OH1Rl9ZOPbzt19dQET2GMXJmkWcDr4NmjyZP0AT/Ic2ipHNe+P9FvMI8 d9imLjhFN8zXLiAan6wLxJatG/g/x+jQ57sYAxQ1Ps3mORTcCiQoFgyi3 SQCEmNrLNroFU6Q3H7pUwDENnJlP6rMUNAA17TqQvQ24EO90mYXSX/1rp g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGMbl1CtJXHA/2dsb2JhbAA6CsM3gQiCIAEEEgEnUQEIIhRCJQIEARIIGodomW6fCIwBEIVLYQOkVIFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,712,1344211200"; d="scan'208";a="138695845" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 05 Nov 2012 01:52:09 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA51q9HN019940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 01:52:09 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.49]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Sun, 4 Nov 2012 19:52:08 -0600 From: "Anurag Bhargava (anuragb)" To: "karagian@cs.utwente.nl" , "carlberg@g11.org.uk" , "tsvwg@ietf.org" Thread-Topic: draft-ietf-tsvwg-rsvp-pcn-03 Thread-Index: AQHNuG54ycIsorhLZEWpePkDEVZ5aJfab4AAgAAQSgA= Date: Mon, 5 Nov 2012 01:52:08 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.116.186.140] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19338.004 x-tm-as-result: No--60.728400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 05 Nov 2012 02:38:46 -0800 Subject: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-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: Mon, 05 Nov 2012 01:52:11 -0000 Thx Georgios. Ken - If U still have other points, may be we can have a offline mtg on Tuesday. Br, -Anurag On 11/4/12 1:55 PM, "karagian@cs.utwente.nl" wrote: >Hi Ken, > >Thank you very much! >Please see in line! > >> ________________________________________ >> Van: ken carlberg [carlberg@g11.org.uk] >> Verzonden: donderdag 1 november 2012 21:21 >> To: tsvwg >> Cc: anuragb@cisco.com; Karagiannis, G. (EWI) >> Onderwerp: draft-ietf-tsvwg-rsvp-pcn-03 > >> Hi Georgios and Anurag, > >> I took a look at the draft and overall, it seems fine, though I do have >>a few comments. =20 >> Mostly for clarification. > >Georgios: Thanks! > > >> 1) The Introduction dives right into what I would see as background >>information. =20 >> You need to add some text in the beginning >> of Section 1 that tells the reader what you plan to do (ie, leverage >>RSVP in=20 >> support of PCN) and explain that PCN needs a signaling protocol to >>complete a feedback loop from egress to ingress. > >Georgios: Good point we will do that! > >> 2) You need to review the terminology section in more detail. Some of >>the items >> in this section are not found anywhere else in the body of the draft >>(eg, t_meas). =20 >> I would also move the terminology subsection further up in the section >>because=20 >> you start talking about some terms early on and then you define them >>later. > >Georgios: Good point we will do that! > >> 3) in some cases, you duplicate the definition of the terminology in >>the body of the draft, >> and in one instance with some different text/references. I think once >>you define the term, >> you don't need to define it again. (eg, ingress-egress-aggregate) > >Georgios: Good point we will do that! > >> 4) in quite a few places, you defer additional explanation to a >>particular RFC. An example being: > >> 2.1.3. Deaggregator (PCN-egress-node) Determination > >> In this document it is considered that for the determination >>of the >> Deaggregator, the same methods can be used as the ones >>described in >> [RFC4860]. > >> However, you do not point the reader to the specific section within >>that reference. =20 >> Given how often this is done, I think it would be helpful to be more >>specific and=20 >> identify the section/subsection in that refernce that you are referring >>to. > >Georgios: Okay, we will also include the relevant section of the referred >RFC! > >> 5) On page 5, you state the following: > >> The PCN-egress-nodes measure the rates of differently marked >> PCN-traffic in periodic intervals and report these rates to >>the >> decision points for admission control and flow termination, >>based on >> which they take their decisions. The decision points may be >> collocated with the PCN-ingress-nodes or their function may be >> implemented in a centralized node. For more details see >>[RFC5559], >> [RFC6661], [RFC6662]. In this document it is considered that >>the >> decision point is collocated with the PCN-ingress-node. > >> The last sentence catches my attention because there is no additional >>rationale stating why you made this decision, >> which in itself does not sound like it was made with conviction (its a >>writing style nit). >> I think you need to expand on this. For example, if we were to assume >>that the decision point is a centralized node, >> how does this affect the rest of your draft? > >Georgios: We will try to explain the rationale of why we consider that >RSVP can only be used for the situation that the >decision point is collocated with the PCN-ingress-node. The main reason >of this is that in the case that the >decision point is collocated with the PCN-ingress-node,the required >signaling protocol used to complete a >feedback loop from egress to ingress can be an entirely on-path protocol, >like what RSVP is. >In the situation that the the decision point is a centralized node, then >the required signaling protocol >can be a combination of an on-path and off-path protocol. This is because >the=20 >decision point might not be located on the data path! So in this case an >additional signaling protocol will be >needed to be specified that covers the signaling between the >PCN-egress-node and the centralized node >and between PCN-ingress-node and the centralized node. >In PCN we decdided to only focus on the specification of the signaling >protocol that completes the >feedback loop from PCN-egress-node to PCN-ingress-node and to focus on >the signaling protocol >used between the edge nodes and the centralized node. >This is also the reason of why PCN WG decided to only focus on the >situation that the decision point is >collocated with the PCN-ingress-node. > >=20 > >> 6) This comment is just for you to contemplate -- I'm not expecting any >>changes. =20 >> I noticed that you have a fair number of SHOULD, and some SHOULD NOTs. >> And it seems a lot of this is a carry over from rfc-4860, so in a sense >>you are inheriting an approach that >> was agreed to from an earlier effort. But I wonder in the back of my >>mind, what impact occurs if >> an implementor doesn't follow the SHOULD? Does the design break in >>supporting PCN? =20 >> Again, I want to stress that this isnt a show stopper, but I would >>appreciate it if you gave it some thought. > >Georgios: Yes, in several cases the design might break in supporting PCN. >This is also the reason of using SHOULD instead of MAY. Do you want us to >explain this in more detail in the draft? > >> 7) For the security sections, at a minimum, you should add reference to >>rfc-2205 and rfc-4230. >> You may also want to add reference to rfc6411. And if the Router Alert >>Option is to be used, >> then you may want to look at the Security Section of rfc-6401 for >>guidance on what to say about RAO > >Georgios: Thanks for the pointers! We will use them! > >> -ken > >Best regards, >Georgios From carlberg@g11.org.uk Mon Nov 5 04:24:08 2012 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 D141621F8585 for ; Mon, 5 Nov 2012 04:24:08 -0800 (PST) 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.363, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGxev2W47Oec for ; Mon, 5 Nov 2012 04:24:08 -0800 (PST) Received: from portland.eukhosting.net (portland.ukserverhosting.net [92.48.103.133]) by ietfa.amsl.com (Postfix) with ESMTP id 0478A21F8596 for ; Mon, 5 Nov 2012 04:24:08 -0800 (PST) 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:Content-Type:Mime-Version:Subject; bh=JciefKwQ2gobh5z2raTDKClVrZWiAOp9bhHGzsRiLcU=; b=MlPwDt5slrqC4+vJ1C3ycnTFYzWhYZtIrjRuQQ2gMaxy+BiLAE9EoyUuoRp47qWEJnqm9Rlessg5J7otv5UuiD8fQxejDDlEdyD+aOXvLFqE8jOMPFm3DaKJn/6agisR; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:56707 helo=[192.168.0.20]) by portland.eukhosting.net with esmtp (Exim 4.80) (envelope-from ) id 1TVLia-002eqY-AQ; Mon, 05 Nov 2012 12:23:52 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: Date: Mon, 5 Nov 2012 07:23:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87644A58-0C27-4F5A-B09B-BD8EC1F9A10A@g11.org.uk> To: X-Mailer: Apple Mail (2.1283) 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 Cc: anuragb@cisco.com, tsvwg@ietf.org Subject: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-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: Mon, 05 Nov 2012 12:24:08 -0000 Georgios, > Georgios: We will try to explain the rationale of why we consider that = RSVP can only be used for the situation that the > decision point is collocated with the PCN-ingress-node. The main = reason of this is that in the case that the=20 > decision point is collocated with the PCN-ingress-node,the required = signaling protocol used to complete a=20 > feedback loop from egress to ingress can be an entirely on-path = protocol, like what RSVP is.=20 > In the situation that the the decision point is a centralized node, = then the required signaling protocol=20 > can be a combination of an on-path and off-path protocol. This is = because the=20 > decision point might not be located on the data path! So in this case = an additional signaling protocol will be=20 > needed to be specified that covers the signaling between the = PCN-egress-node and the centralized node=20 > and between PCN-ingress-node and the centralized node. > In PCN we decdided to only focus on the specification of the signaling = protocol that completes the=20 > feedback loop from PCN-egress-node to PCN-ingress-node and to focus on = the signaling protocol=20 > used between the edge nodes and the centralized node. > This is also the reason of why PCN WG decided to only focus on the = situation that the decision point is=20 > collocated with the PCN-ingress-node. Great, this is helpful, and this is the information that needs to be in = the draft. >> 6) This comment is just for you to contemplate -- I'm not expecting = any changes. =20 >> I noticed that you have a fair number of SHOULD, and some SHOULD = NOTs. =20 >> And it seems a lot of this is a carry over from rfc-4860, so in a = sense you are inheriting an approach that=20 >> was agreed to from an earlier effort. But I wonder in the back of my = mind, what impact occurs if=20 >> an implementor doesn't follow the SHOULD? Does the design break in = supporting PCN? =20 >> Again, I want to stress that this isnt a show stopper, but I would = appreciate it if you gave it some thought. >=20 > Georgios: Yes, in several cases the design might break in supporting = PCN.=20 > This is also the reason of using SHOULD instead of MAY. Do you want us = to explain this in more detail in the draft? well, actually, I was more curious as to why a number of these cases are = SHOULD instead of MUST. Again, the SHOULD's in your document seem to be = a carry-over from rfc-4860 (which set the precedent), so its a bit = unfair for you to explain what was done in an earlier effort. I just = wanted to make sure you gave some thought to the subject. And if things = will break if SHOULD is not followed by an implementer/configuration, = then maybe you should be more stringent and change things to MUST. = Perhaps a brief private conversation with Francois Le Faucheur will be = helpful. cheers, -ken From karagian@cs.utwente.nl Mon Nov 5 04:28:06 2012 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 65F7821F85C2 for ; Mon, 5 Nov 2012 04:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.471 X-Spam-Level: X-Spam-Status: No, score=-0.471 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wm5bgdCh0oVd for ; Mon, 5 Nov 2012 04:28:03 -0800 (PST) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6D821F85BC for ; Mon, 5 Nov 2012 04:28:03 -0800 (PST) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 5 Nov 2012 13:28:06 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.76]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.02.0318.004; Mon, 5 Nov 2012 13:28:02 +0100 From: To: Thread-Topic: draft-ietf-tsvwg-rsvp-pcn-03 Thread-Index: AQHNuG567zXDhOEf1EmojaHb3rIjiJfaAz+MgAEb9QCAABFxXA== Date: Mon, 5 Nov 2012 12:28:01 +0000 Message-ID: References: <87644A58-0C27-4F5A-B09B-BD8EC1F9A10A@g11.org.uk> , In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.67.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: anuragb@cisco.com, tsvwg@ietf.org Subject: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-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: Mon, 05 Nov 2012 12:28:06 -0000 Hi Ken, Thank you very much! We will try to catch Francois and discuss the last (in line) issue with him= ! Best regards, Georgios ________________________________________ Van: ken carlberg [carlberg@g11.org.uk] Verzonden: maandag 5 november 2012 13:23 To: Karagiannis, G. (EWI) Cc: tsvwg@ietf.org; anuragb@cisco.com Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03 Georgios, > Georgios: We will try to explain the rationale of why we consider that RS= VP can only be used for the situation that the > decision point is collocated with the PCN-ingress-node. The main reason o= f this is that in the case that the > decision point is collocated with the PCN-ingress-node,the required signa= ling protocol used to complete a > feedback loop from egress to ingress can be an entirely on-path protocol,= like what RSVP is. > In the situation that the the decision point is a centralized node, then = the required signaling protocol > can be a combination of an on-path and off-path protocol. This is because= the > decision point might not be located on the data path! So in this case an = additional signaling protocol will be > needed to be specified that covers the signaling between the PCN-egress-n= ode and the centralized node > and between PCN-ingress-node and the centralized node. > In PCN we decdided to only focus on the specification of the signaling pr= otocol that completes the > feedback loop from PCN-egress-node to PCN-ingress-node and to focus on th= e signaling protocol > used between the edge nodes and the centralized node. > This is also the reason of why PCN WG decided to only focus on the situat= ion that the decision point is > collocated with the PCN-ingress-node. Great, this is helpful, and this is the information that needs to be in the= draft. >> 6) This comment is just for you to contemplate -- I'm not expecting any = changes. >> I noticed that you have a fair number of SHOULD, and some SHOULD NOTs. >> And it seems a lot of this is a carry over from rfc-4860, so in a sense = you are inheriting an approach that >> was agreed to from an earlier effort. But I wonder in the back of my mi= nd, what impact occurs if >> an implementor doesn't follow the SHOULD? Does the design break in supp= orting PCN? >> Again, I want to stress that this isnt a show stopper, but I would appre= ciate it if you gave it some thought. > > Georgios: Yes, in several cases the design might break in supporting PCN. > This is also the reason of using SHOULD instead of MAY. Do you want us to= explain this in more detail in the draft? well, actually, I was more curious as to why a number of these cases are SH= OULD instead of MUST. Again, the SHOULD's in your document seem to be a ca= rry-over from rfc-4860 (which set the precedent), so its a bit unfair for y= ou to explain what was done in an earlier effort. I just wanted to make su= re you gave some thought to the subject. And if things will break if SHOUL= D is not followed by an implementer/configuration, then maybe you should be= more stringent and change things to MUST. Perhaps a brief private convers= ation with Francois Le Faucheur will be helpful. cheers, -ken= From Ruediger.Geib@telekom.de Tue Nov 6 00:41:20 2012 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 68D1921F85D6; Tue, 6 Nov 2012 00:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[AWL=0.597, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xUtISDKSp9H; Tue, 6 Nov 2012 00:41:19 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 01D6721F85C7; Tue, 6 Nov 2012 00:41:18 -0800 (PST) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 06 Nov 2012 09:41:16 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 6 Nov 2012 09:41:09 +0100 From: To: Date: Tue, 6 Nov 2012 09:41:08 +0100 Thread-Topic: Informational: draft-geib-tsvwg-diffserv-interconnection-00.txt Thread-Index: Ac21tVjGMVqHKk3STny+++t4bxTNCw== Message-ID: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org Subject: [tsvwg] Informational: draft-geib-tsvwg-diffserv-interconnection-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, 06 Nov 2012 08:41:20 -0000 Dear TSVWG chairs, as mentioned in an earlier message, a new ID about interconnection qos whic= h I failed to finalise before submission cutt-off is now available: http://www.ietf.org/id/draft-geib-tsvwg-diffserv-intercon-00.txt This is not a request for a time slot. Comments are welcome of course. I've received a question about Layer 2 services in there. Ethernet over IP/= MPLS products are present in the market I'm aware off (some QoS codepoints = are required for classification then). The initial idea for the interconnec= tion qos resulted from national Layer 2 interconnection negotiations. If yo= u read MEF23.1, you'll find a rich set of proposed classification functions= , ranging up to Layer 4. I think, IP, MPLS and Ethernet QoS is linked and i= ntertwined. Regards, R=FCdiger From brian.e.carpenter@gmail.com Tue Nov 6 04:19:31 2012 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 5E10A21F88CB for ; Tue, 6 Nov 2012 04:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sda81C4CAvxs for ; Tue, 6 Nov 2012 04:19:30 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 795FE21F88A3 for ; Tue, 6 Nov 2012 04:19:30 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so378210pbb.31 for ; Tue, 06 Nov 2012 04:19:30 -0800 (PST) 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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=d1kghJdWfJkyEmfCHBxqiUEHTujzoeyZxchSAFti5t0=; b=CK3cyTZg9h0pmwwn3iJD1FOID98pUN+VG2j02Ez6IwrUW2kB12u/jinnOYO4Z58Q5v stIJnXaROn2SPp/6k5bThcFY+Wn+q48J+NnddQ+M2p+1Fvie480EcwiJjBUaJ7Vs8io/ qGeA7OhM8ytD/KC9en7XgjdN8P3FW//9Qe626ymaIhlg50k1hNPR+1M/S4RjOmcEp9dZ TEb6YNzR41H3RNxuzhudkaBXuCq/kdGpvKVDKBo0xP+oMsXk6BLDZEj+H3MocJUee0gE rninfAezip/wMRDmos/7qH8FwV5BSkPo3xLpxRIWRK5n7IKFSCJuHYObfp63nrKLDA1k YYJg== Received: by 10.66.80.166 with SMTP id s6mr2201106pax.21.1352204370211; Tue, 06 Nov 2012 04:19:30 -0800 (PST) Received: from [130.129.66.184] (dhcp-42b8.meeting.ietf.org. [130.129.66.184]) by mx.google.com with ESMTPS id j8sm12388642paz.30.2012.11.06.04.19.28 (version=SSLv3 cipher=OTHER); Tue, 06 Nov 2012 04:19:28 -0800 (PST) Message-ID: <50990054.80408@gmail.com> Date: Tue, 06 Nov 2012 12:19:32 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tsvwg@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [tsvwg] Informational: draft-geib-tsvwg-diffserv-interconnection-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, 06 Nov 2012 12:19:31 -0000 Some thoughts on this draft, based on a preview over the weekend: 1. I think it is a reasonable idea to specify a small set of traffic clas= ses that could be the default set in peering relationships. Getting consensus= on the best set could be tricky, of course. 2. I may be old fashioned, but I don't really understand why we bother with layer 2 values at all. If diffserv is working properly, layer 2 can just give the same service to all packets. (Unless there are non-IP servi= ces on the same wire.) In fact I'd rather that layer 2 doesn't try to impose any queue or drop behaviour other than FCFS. (ECN passed up from layer 2 to layer 3/4 makes sense. What I don't see is= the advantage in mapping traffic classes down rather than just treating layer 2 as intrinsically best effort. Layer 3 should be respecting the appropriate queueing discipline for each traffic class already.) 3. Finding good names for the selected traffic classes is indeed hard; even if you call them A, B and C there is an implied semantic. You could try names like Elastic, Inelastic and Network Control maybe. Regards Brian Carpenter Cell phone during IETF85: +1 847 219 0880 On 06/11/2012 08:41, Ruediger.Geib@telekom.de wrote: > Dear TSVWG chairs, >=20 > as mentioned in an earlier message, a new ID about interconnection qos = which I failed to finalise before submission cutt-off is now available: >=20 > http://www.ietf.org/id/draft-geib-tsvwg-diffserv-intercon-00.txt >=20 > This is not a request for a time slot. >=20 > Comments are welcome of course. >=20 > I've received a question about Layer 2 services in there. Ethernet over= IP/MPLS products are present in the market I'm aware off (some QoS codep= oints are required for classification then). The initial idea for the int= erconnection qos resulted from national Layer 2 interconnection negotiati= ons. If you read MEF23.1, you'll find a rich set of proposed classificati= on functions, ranging up to Layer 4. I think, IP, MPLS and Ethernet QoS i= s linked and intertwined. >=20 > Regards, >=20 > R=C3=BCdiger >=20 From Ruediger.Geib@telekom.de Tue Nov 6 04:53:14 2012 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 2BDA721F867B for ; Tue, 6 Nov 2012 04:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.898, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgIdBTaJz3DY for ; Tue, 6 Nov 2012 04:53:13 -0800 (PST) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC6921F8609 for ; Tue, 6 Nov 2012 04:53:12 -0800 (PST) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 06 Nov 2012 13:53:10 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 6 Nov 2012 13:53:09 +0100 From: To: Date: Tue, 6 Nov 2012 13:53:08 +0100 Thread-Topic: [tsvwg] Informational: draft-geib-tsvwg-diffserv-interconnection-00.txt Thread-Index: Ac28GT9qQoeNjpWET0mDbQBRxxIH+wAABegA Message-ID: References: <50990054.80408@gmail.com> In-Reply-To: <50990054.80408@gmail.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: tsvwg@ietf.org Subject: Re: [tsvwg] Informational: draft-geib-tsvwg-diffserv-interconnection-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, 06 Nov 2012 12:53:14 -0000 Brian, thanks for your comments. My response is related to Ethernet QoS. Ethernet QoS may be part of an end to end IP path in some cases: - if IP runs over Ethernet and a provider offers Ethernet over MPLS service. One solution is to assign QoS to a VLAN ID, another one may be to map DSCP to P-Bits and P-Bits to MPLS TC. - as soon as there's a bottleneck in a network segment which doesn't apply IP/MPLS transport, QoS differentiation on Layer 2 may be desireable. Access and interconnection interfaces may be layer 2 based. The question is, whether any Ethernet swichting or multiplexing will occur. If this isn't the case and the receiving edge terminates the virtual Ethernet link, P-Bits don't make sense. Thanks for supporting the basic principles of interconnection QoS classes and finding application agnostic class names. I'd be glad if there's more support for the ideas at the meeting. I prefer not to start discussion on details prior to the Thursday meeting. Regards, R=FCdiger -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of B= rian E Carpenter Sent: Tuesday, November 06, 2012 1:20 PM To: tsvwg@ietf.org Subject: Re: [tsvwg] Informational: draft-geib-tsvwg-diffserv-interconnecti= on-00.txt Some thoughts on this draft, based on a preview over the weekend: 1. I think it is a reasonable idea to specify a small set of traffic classe= s that could be the default set in peering relationships. Getting consensus on the best set could be tricky, of course. 2. I may be old fashioned, but I don't really understand why we bother with layer 2 values at all. If diffserv is working properly, layer 2 can just give the same service to all packets. (Unless there are non-IP service= s on the same wire.) In fact I'd rather that layer 2 doesn't try to impose any queue or drop behaviour other than FCFS. (ECN passed up from layer 2 to layer 3/4 makes sense. What I don't see is the advantage in mapping traffic classes down rather than just treating layer 2 as intrinsically best effort. Layer 3 should be respecting the appropriate queueing discipline for each traffic class already.) 3. Finding good names for the selected traffic classes is indeed hard; even if you call them A, B and C there is an implied semantic. You could try names like Elastic, Inelastic and Network Control maybe. Regards Brian Carpenter Cell phone during IETF85: +1 847 219 0880 On 06/11/2012 08:41, Ruediger.Geib@telekom.de wrote: > Dear TSVWG chairs, > > as mentioned in an earlier message, a new ID about interconnection qos wh= ich I failed to finalise before submission cutt-off is now available: > > http://www.ietf.org/id/draft-geib-tsvwg-diffserv-intercon-00.txt > > This is not a request for a time slot. > > Comments are welcome of course. > > I've received a question about Layer 2 services in there. Ethernet over I= P/MPLS products are present in the market I'm aware off (some QoS codepoint= s are required for classification then). The initial idea for the interconn= ection qos resulted from national Layer 2 interconnection negotiations. If = you read MEF23.1, you'll find a rich set of proposed classification functio= ns, ranging up to Layer 4. I think, IP, MPLS and Ethernet QoS is linked and= intertwined. > > Regards, > > R=FCdiger > From internet-drafts@ietf.org Tue Nov 6 10:50:30 2012 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 1C34121F8AAC; Tue, 6 Nov 2012 10:50:30 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7gooXifM0oc; Tue, 6 Nov 2012 10:50:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9328C21F88B5; Tue, 6 Nov 2012 10:50:29 -0800 (PST) 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.35 Message-ID: <20121106185029.7310.41012.idtracker@ietfa.amsl.com> Date: Tue, 06 Nov 2012 10:50:29 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-failover-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, 06 Nov 2012 18:50:30 -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 : Quick Failover Algorithm in SCTP Author(s) : Yoshifumi Nishida Preethi Natarajan Armando Caro Filename : draft-ietf-tsvwg-sctp-failover-00.txt Pages : 17 Date : 2012-09-10 Abstract: One of the major advantages in SCTP is supporting multi-homing communication. If a multi-homed end-point has redundant network connections, SCTP sessions can have a good chance to survive from network failures by migrating inactive network to active one. However, if we follow the SCTP standard, there can be significant delay for the network migration. During this migration period, SCTP cannot transmit much data to the destination. This issue drastically impairs the usability of SCTP in some situations. This memo describes the issue of SCTP failover mechanism and discuss its solutions which require minimal modification to the current standard. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-failover There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-failover-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gorry@erg.abdn.ac.uk Tue Nov 6 11:47:32 2012 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 A40F121F8A5D; Tue, 6 Nov 2012 11:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.168 X-Spam-Level: X-Spam-Status: No, score=-102.168 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6TyAAYwztzD; Tue, 6 Nov 2012 11:47:32 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 213DA21F8A5C; Tue, 6 Nov 2012 11:47:32 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id C4AD72B45EE; Tue, 6 Nov 2012 19:47:30 +0000 (GMT) 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 D878D2B43B2; Tue, 6 Nov 2012 19:47:29 +0000 (GMT) Message-ID: <50996950.7020602@erg.abdn.ac.uk> Date: Tue, 06 Nov 2012 14:47:28 -0500 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:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: tsvwg@ietf.org, tsvwg-chairs@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tsvwg] TSVWG Adoption call for draft-stewart-tsvwg-sctpecn 6th Nov 2012 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, 06 Nov 2012 19:47:32 -0000 The TSV WG plans to adopt the draft: draft-stewart-tsvwg-sctpecn as a TSV WG work item. The Chairs believe this falls within the Charter of our WG. This work item was discussed at previous IETF meetings and at the Paris IETF the WG decided it was good to call for adoption. This email asks for comments in support of adopting this as a work item - or notes of concerns or issues. Please send feedback to the list of chairs. We plan to discuss this at our meeting on Friday. Best wishes, Gorry & James (TSVWG Chairs) From internet-drafts@ietf.org Wed Nov 7 08:10:32 2012 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 610DE21F8C6A; Wed, 7 Nov 2012 08:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFKUGMFBJsxQ; Wed, 7 Nov 2012 08:10:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8D821F8C70; Wed, 7 Nov 2012 08:10:14 -0800 (PST) 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.35 Message-ID: <20121107161014.27560.35433.idtracker@ietfa.amsl.com> Date: Wed, 07 Nov 2012 08:10:14 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-byte-pkt-congest-09.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, 07 Nov 2012 16:10:32 -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 : Byte and Packet Congestion Notification Author(s) : Bob Briscoe Jukka Manner Filename : draft-ietf-tsvwg-byte-pkt-congest-09.txt Pages : 43 Date : 2012-11-07 Abstract: This document provides recommendations of best current practice for dropping or marking packets using active queue management (AQM) such as random early detection (RED) or pre-congestion notification (PCN). We give three strong recommendations: (1) packet size should be taken into account when transports read and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) the byte-mode packet drop variant of the RED AQM algorithm that drops fewer small packets should not be used. This memo updates RFC 2309 to deprecate deliberate preferential treatment of small packets in AQM algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-byte-pkt-congest There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-byte-pkt-congest-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-byte-pkt-congest-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From david.black@emc.com Thu Nov 8 07:53:31 2012 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 8AFB321F848D for ; Thu, 8 Nov 2012 07:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybPByPcGf1U6 for ; Thu, 8 Nov 2012 07:53:31 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 732A921F84A7 for ; Thu, 8 Nov 2012 07:53:29 -0800 (PST) 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 qA8FrSQq005664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Nov 2012 10:53:28 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Thu, 8 Nov 2012 10:53:10 -0500 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qA8Fr80d015628 for ; Thu, 8 Nov 2012 10:53:09 -0500 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Thu, 8 Nov 2012 10:53:09 -0500 From: "Black, David" To: "tsvwg@ietf.org" Date: Thu, 8 Nov 2012 10:53:07 -0500 Thread-Topic: Today's tsvwg meeting: Diffserv Thread-Index: Ac29yST0JVzEwAQAQUyDDrqSYh60uA== Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120E1DD45C@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] Today's tsvwg meeting: 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, 08 Nov 2012 15:53:31 -0000 I've agreed to act as a co-chair for today's tsvwg session on diffserv to enable James Polk to focus on his drafts. One of the goals of today's discussion is to figure out what to do with those drafts. Here's some background and context material on the Diffserv Classes topics and a related Interconnect problem that's been raised in a liaison from ITU-T SG12: http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-8.pdf 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 Ruediger.Geib@telekom.de Fri Nov 9 01:02:01 2012 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 0EF3821F85CE for ; Fri, 9 Nov 2012 01:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.674, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6kew+NM-0wY for ; Fri, 9 Nov 2012 01:02:00 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 242E121F851F for ; Fri, 9 Nov 2012 01:01:59 -0800 (PST) Received: from he113656.emea1.cds.t-internal.com ([10.134.99.16]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 09 Nov 2012 10:00:34 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113656.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 9 Nov 2012 10:00:32 +0100 From: To: Date: Fri, 9 Nov 2012 10:00:31 +0100 Thread-Topic: Tsvwg meeting: Diffserv - some thoughts Thread-Index: Ac29yST0JVzEwAQAQUyDDrqSYh60uAAiWfnQ Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE7120E1DD45C@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7120E1DD45C@MX15A.corp.emc.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: tsvwg@ietf.org Subject: [tsvwg] Tsvwg meeting: Diffserv - some thoughts 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, 09 Nov 2012 09:02:01 -0000 David, I'm not fully clear about which problem we (should) try to solve on DiffSer= v in tsvwg: - the backbone or SP networks don't seem to be a QoS issue. A few classes p= robably will be sufficient. - tsvwg isn't chartered to solve application problems (like wireless access= , rtp packets only all x milliseconds and so on. - if a bottleneck is overbooked, DiffServ can distribute capacity, but not = create additional one. Then some thoughts on streaming and teleconferencing - streaming is delay tolerant. Where would one locate the large buffer? On = a 10 GE interface? On a bottleneck interface? Very close to the application? - streaming does not reduce traffic during congestion (multicast can't). Wh= at's the effect of assigning a deep buffer for it at backbone interfaces, if there's congest= ion? - what's a good argument not to produce both across the same queue/class? In sum: what does a DS RFC reader learn from a class description in terms l= oss tolerance yes/no, delay tolerance yes/no and so on? My take: without understanding the presen= t or required transport properties of an application, a purely application based performance requir= ement description can be misleading. If we conclude that many classes are required to deal with bottleneck behav= iour and we expect this bottleneck to be present (and DiffServ t kick in), then what do we nee= d: - many classes, each of which has to be engineered by non-QoS-experts based= on a configuration guidance given by 4594? That would be preconfigured, I guess and every im= plementor will apply phantasy. If like 10 PHBs are implemented, which gets what share of= the bottleneck bandwidth? How do they compete for spare capacity? How is traffic admitte= d? - or do we try to solve an admission control (or traffic engineering) probl= em by creating ever new class defintions. Maybe it's worth to think about a problem statement to get a clear descript= ion of the issues, we want to deal with. DiffServ created a set of tools, applicable for route= rs or networks largely. It seems to me, that now the community starts to look at QoS more = from an end to end perspective, but tries to solve issues with router mechanisms. That's n= ot what DiffServ is designed for. Regards, R=FCdiger From jmpolk@cisco.com Fri Nov 9 04:44:59 2012 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 C452A21F8671 for ; Fri, 9 Nov 2012 04:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.419 X-Spam-Level: X-Spam-Status: No, score=-110.419 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VGqR+jx8zFk for ; Fri, 9 Nov 2012 04:44:58 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C47F921F866E for ; Fri, 9 Nov 2012 04:44:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3336; q=dns/txt; s=iport; t=1352465098; x=1353674698; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version:content-transfer-encoding; bh=4uPJGCM+yWfheBP+0P323FvuVpTH6YV/iMrlMszZGXo=; b=gcjOZniUHMbQOBAl41BEUfE/YV85iiZHaUDrZkSd6/LdinPJA8+6sJ5M 2eejY+KlfRxlTBsc4ALmF3c6Vf7OyL6BwhOOR/0lyqeLnJqZlzlUj4PjN BgpZj83k5nft+nGoxjNHufOGLslilVYhOfmqBFnzw4VlTv8VDDuBAbGpz g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALv5nFCtJV2a/2dsb2JhbABEw0qBCIIeAQEBBBIBJTMOEAcEGC4ZPgYTFA6HaJ0SoBOMEoZIA4glNZt5gWuDDg X-IronPort-AV: E=McAfee;i="5400,1158,6890"; a="140590488" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 09 Nov 2012 12:44:58 +0000 Received: from jmpolk-WS.cisco.com (rtp-vpn2-361.cisco.com [10.82.241.105]) (authenticated bits=0) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA9CiuKq003941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Nov 2012 12:44:57 GMT Message-Id: <201211091244.qA9CiuKq003941@rcdn-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 09 Nov 2012 06:44:56 -0600 To: From: James Polk In-Reply-To: References: <8D3D17ACE214DC429325B2B98F3AE7120E1DD45C@MX15A.corp.emc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-User: jmpolk Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Tsvwg meeting: Diffserv - some thoughts 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, 09 Nov 2012 12:44:59 -0000 Some reactions - We're chartered with everything that has to do=20 with a document we produced in the past, which includes RFC 4594. - the only interface speed you mention is 10Gb/s,=20 as it that is the only interface we need to be concerned with. - what about all the millions of Linksys, D-Link=20 and Netgear type routers that connect to the Internet? - video streaming and teleconferencing are=20 mentioned, then only examples of buffered=20 streaming are given - and nothing is said about=20 interactive communications - which is one of the=20 bigger points of this RFC4594-update draft. I think this note below is colored by looking=20 through a core interconnect lens exclusively, as=20 if that's all we should be concerned with and=20 that's the only place DS is used. James At 03:00 AM 11/9/2012, Ruediger.Geib@telekom.de wrote: >David, > >I'm not fully clear about which problem we=20 >(should) try to solve on DiffServ in tsvwg: > >- the backbone or SP networks don't seem to be a=20 >QoS issue. A few classes probably will be sufficient. >- tsvwg isn't chartered to solve application=20 >problems (like wireless access, rtp packets only > all x milliseconds and so on. >- if a bottleneck is overbooked, DiffServ can=20 >distribute capacity, but not create additional one. > >Then some thoughts on streaming and teleconferencing >- streaming is delay tolerant. Where would one=20 >locate the large buffer? On a 10 GE interface? > On a bottleneck interface? Very close to the application? >- streaming does not reduce traffic during=20 >congestion (multicast can't). What's the effect of > assigning a deep buffer for it at backbone=20 > interfaces, if there's congestion? >- what's a good argument not to produce both across the same queue/class? > >In sum: what does a DS RFC reader learn from a=20 >class description in terms loss tolerance yes/no, >delay tolerance yes/no and so on? My take:=20 >without understanding the present or required transport >properties of an application, a purely=20 >application based performance requirement description can >be misleading. > >If we conclude that many classes are required to=20 >deal with bottleneck behaviour and we expect >this bottleneck to be present (and DiffServ t kick in), then what do we= need: > >- many classes, each of which has to be=20 >engineered by non-QoS-experts based on a configuration > guidance given by 4594? That would be=20 > preconfigured, I guess and every implementor will > apply phantasy. If like 10 PHBs are=20 > implemented, which gets what share of the bottleneck > bandwidth? How do they compete for spare capacity? How is traffic= admitted? > >- or do we try to solve an admission control (or=20 >traffic engineering) problem by creating ever > new class defintions. > >Maybe it's worth to think about a problem=20 >statement to get a clear description of the issues, >we want to deal with. DiffServ created a set of=20 >tools, applicable for routers or networks >largely. It seems to me, that now the community=20 >starts to look at QoS more from an end to >end perspective, but tries to solve issues with=20 >router mechanisms. That's not what DiffServ >is designed for. > >Regards, > >R=FCdiger From david.black@emc.com Fri Nov 9 08:08:01 2012 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 7BA7621F873C for ; Fri, 9 Nov 2012 08:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dakT96j2N-q1 for ; Fri, 9 Nov 2012 08:08:00 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0C02D21F8757 for ; Fri, 9 Nov 2012 08:07:59 -0800 (PST) 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 qA9G7sjb004444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Nov 2012 11:07:56 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Fri, 9 Nov 2012 11:07:39 -0500 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 qA9G7cYF012979; Fri, 9 Nov 2012 11:07:39 -0500 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub33.corp.emc.com ([::1]) with mapi; Fri, 9 Nov 2012 11:07:38 -0500 From: "Black, David" To: "Ruediger.Geib@telekom.de" Date: Fri, 9 Nov 2012 11:07:36 -0500 Thread-Topic: Tsvwg meeting: Diffserv - some thoughts Thread-Index: Ac29yST0JVzEwAQAQUyDDrqSYh60uAAiWfnQAAyLIrA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120E1DD693@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE7120E1DD45C@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Tsvwg meeting: Diffserv - some thoughts 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, 09 Nov 2012 16:08:01 -0000 R=FCdiger, While Diffserv was significantly motivated by service provider core and backbone networks, the applicability of Diffserv has never been limited to that class of networks. For example, see slide 2 in the slide deck that James used yesterday: http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-13.pptx There are almost certainly opportunities to differentiate treatment of interactive media traffic (that needs a low jitter budget) from non-interactive media traffic selectively near known/expected bottlenecks even if there may not be a rationale for doing that differentiation globally. The sense of the room in yesterday's tsvwg meeting (will need to be confirmed on this list, separate message coming soon) was that the IETF should work on the diffserv interconnect problem represented in the ITU-T SG12 liaison and your draft. IMHO, that work is likely to result in a small number of interconnect traffic classes that may or may not resemble the treatment aggregates in RFC 5127. There will be nothing to stop a network from choosing to deploy just those interconnect classes internally in addition to using them for interconnection. A network could also internally deploy a subset of the RFC 4594 (or successor) traffic classes, or even just some or all of the four treatment aggregates in RFC 5127 (or successor). In particular, there is no current or intended requirement that any network deploy all of the diffserv service classes in RFC 4594 or any successor. I also want to be clear that I am not assuming that the interconnect traffic classes will be based on an update to RFC 5127, as they address different problems - the approach here is TBD by the WG. Thanks, --David > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Friday, November 09, 2012 4:01 AM > To: Black, David > Cc: tsvwg@ietf.org > Subject: Tsvwg meeting: Diffserv - some thoughts >=20 > David, >=20 > I'm not fully clear about which problem we (should) try to solve on DiffS= erv > in tsvwg: >=20 > - the backbone or SP networks don't seem to be a QoS issue. A few classes > probably will be sufficient. > - tsvwg isn't chartered to solve application problems (like wireless acce= ss, > rtp packets only all x milliseconds and so on. > - if a bottleneck is overbooked, DiffServ can distribute capacity, but no= t > create additional one. >=20 > Then some thoughts on streaming and teleconferencing > - streaming is delay tolerant. Where would one locate the large buffer? O= n a > 10 GE interface? On a bottleneck interface? Very close to the application= ? > - streaming does not reduce traffic during congestion (multicast can't). > What's the effect of assigning a deep buffer for it at backbone interface= s, > if there's congestion? > - what's a good argument not to produce both across the same queue/class? >=20 > In sum: what does a DS RFC reader learn from a class description in terms= loss tolerance yes/no, > delay tolerance yes/no and so on? My take: without understanding the pres= ent or required transport > properties of an application, a purely application based performance requ= irement description can > be misleading. >=20 > If we conclude that many classes are required to deal with bottleneck beh= aviour and we expect > this bottleneck to be present (and DiffServ t kick in), then what do we n= eed: >=20 > - many classes, each of which has to be engineered by non-QoS-experts bas= ed on a configuration > guidance given by 4594? That would be preconfigured, I guess and every = implementor will > apply phantasy. If like 10 PHBs are implemented, which gets what share = of the bottleneck > bandwidth? How do they compete for spare capacity? How is traffic admit= ted? >=20 > - or do we try to solve an admission control (or traffic engineering) pro= blem by creating ever > new class defintions. >=20 > Maybe it's worth to think about a problem statement to get a clear descri= ption of the issues, > we want to deal with. DiffServ created a set of tools, applicable for rou= ters or networks > largely. It seems to me, that now the community starts to look at QoS mor= e from an end to > end perspective, but tries to solve issues with router mechanisms. That's= not what DiffServ > is designed for. >=20 > Regards, >=20 > R=FCdiger >=20 >=20 >=20 >=20 >=20 >=20 From bob.briscoe@bt.com Fri Nov 9 08:23:18 2012 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 05AAC21F874D for ; Fri, 9 Nov 2012 08:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.99 X-Spam-Level: X-Spam-Status: No, score=-2.99 tagged_above=-999 required=5 tests=[AWL=0.610, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeWc5oFF3DLT for ; Fri, 9 Nov 2012 08:23:16 -0800 (PST) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 2D13221F8575 for ; Fri, 9 Nov 2012 08:23:16 -0800 (PST) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 9 Nov 2012 16:23:08 +0000 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 9 Nov 2012 16:23:10 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.309.2; Fri, 9 Nov 2012 16:23:06 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1352478185710; Fri, 9 Nov 2012 16:23:05 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.1.55]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qA9GMxVm013855; Fri, 9 Nov 2012 16:23:02 GMT Message-ID: <201211091623.qA9GMxVm013855@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 9 Nov 2012 15:33:10 +0000 To: From: Bob Briscoe In-Reply-To: References: <87644A58-0C27-4F5A-B09B-BD8EC1F9A10A@g11.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: "EARDLEY, Phil" , anuragb@cisco.com, tsvwg@ietf.org Subject: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-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: Fri, 09 Nov 2012 16:23:18 -0000 Georgios, I shall post my full review of this draft in the next few days (needs typing up - currently scribbled on a paper copy). This email is solely in response to your answer about on-path vs off-path policy. At 18:55 04/11/2012, karagian@cs.utwente.nl wrote: >So in this case an additional signaling protocol will be >needed to be specified that covers the signaling between the >PCN-egress-node and the centralized node >and between PCN-ingress-node and the centralized node. >In PCN we decdided to only focus on the specification of the >signaling protocol that completes the >feedback loop from PCN-egress-node to PCN-ingress-node and to focus >on the signaling protocol >used between the edge nodes and the centralized node. When I/we originally designed CL-PCN over RSVP (2005), the idea was that it would fit with the policy-based admission control (PBAC) architecture of RFC2753. In this architecture, an Intserv node at the ingress to a domain is the policy enforcement point (PEP), and it refers to a logically centralised 'policy decision point' (PDP) for decisions on which flows to block/terminate, typically using COPS. To make this doc fit the PBAC framework, all we have to do is: * Describe the PCN-ingress only as the PCN-ingress and not as the decision point (find 'decision' throughout doc and fix). * Add a section saying the PCN-ingress can refer flow admission and termination decisions to a central decision point (using e.g. COPS), which will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingress could itself be the policy decision point.) * Refer to this new PBAC section from Section 3.11 giving the admission decision procedure. * Some people might think this means COPS will need new protocol elements to carry PCN marking rates to the policy decision point. But PCN marking rates are irrelevant to the policy decision: the PCN-ingress just uses PCN to determine whether it needs to block or terminate, and it refers to the policy decision point for which flows to block/terminate. * Unfortunately, neither of the two PCN system descriptions [RFC6661, RFC6662] describe a PBAC-based case. The architecture [RFC5559] refers to the PBAC framework [RFC2753] but unfortunately doesn't spell out how it fits. Originally, I referenced PBAC from RFC5559, but just as the PCN w-g was closing I realised that (some?) others in the PCN w-g were working under the assumption that the only way to talk to a centralised policy node was from the egress, possibly without being aware of the contents of RFC2753. I think it's OK to introduce a new architectural arrangement in this RSVP doc, given RFC2753 is specific to the way RSVP works. Bob At 12:28 05/11/2012, karagian@cs.utwente.nl wrote: >Hi Ken, > >Thank you very much! >We will try to catch Francois and discuss the last (in line) issue with him! > >Best regards, >Georgios > >________________________________________ >Van: ken carlberg [carlberg@g11.org.uk] >Verzonden: maandag 5 november 2012 13:23 >To: Karagiannis, G. (EWI) >Cc: tsvwg@ietf.org; anuragb@cisco.com >Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03 > >Georgios, > > > Georgios: We will try to explain the rationale of why we consider > that RSVP can only be used for the situation that the > > decision point is collocated with the PCN-ingress-node. The main > reason of this is that in the case that the > > decision point is collocated with the PCN-ingress-node,the > required signaling protocol used to complete a > > feedback loop from egress to ingress can be an entirely on-path > protocol, like what RSVP is. > > In the situation that the the decision point is a centralized > node, then the required signaling protocol > > can be a combination of an on-path and off-path protocol. This is > because the > > decision point might not be located on the data path! So in this > case an additional signaling protocol will be > > needed to be specified that covers the signaling between the > PCN-egress-node and the centralized node > > and between PCN-ingress-node and the centralized node. > > In PCN we decdided to only focus on the specification of the > signaling protocol that completes the > > feedback loop from PCN-egress-node to PCN-ingress-node and to > focus on the signaling protocol > > used between the edge nodes and the centralized node. > > This is also the reason of why PCN WG decided to only focus on > the situation that the decision point is > > collocated with the PCN-ingress-node. > >Great, this is helpful, and this is the information that needs to be >in the draft. > > >> 6) This comment is just for you to contemplate -- I'm not > expecting any changes. > >> I noticed that you have a fair number of SHOULD, and some SHOULD NOTs. > >> And it seems a lot of this is a carry over from rfc-4860, so in > a sense you are inheriting an approach that > >> was agreed to from an earlier effort. But I wonder in the back > of my mind, what impact occurs if > >> an implementor doesn't follow the SHOULD? Does the design break > in supporting PCN? > >> Again, I want to stress that this isnt a show stopper, but I > would appreciate it if you gave it some thought. > > > > Georgios: Yes, in several cases the design might break in supporting PCN. > > This is also the reason of using SHOULD instead of MAY. Do you > want us to explain this in more detail in the draft? > >well, actually, I was more curious as to why a number of these cases >are SHOULD instead of MUST. Again, the SHOULD's in your document >seem to be a carry-over from rfc-4860 (which set the precedent), so >its a bit unfair for you to explain what was done in an earlier >effort. I just wanted to make sure you gave some thought to the >subject. And if things will break if SHOULD is not followed by an >implementer/configuration, then maybe you should be more stringent >and change things to MUST. Perhaps a brief private conversation >with Francois Le Faucheur will be helpful. > >cheers, > >-ken ________________________________________________________________ Bob Briscoe, BT Innovate & Design From touch@isi.edu Fri Nov 9 11:01:23 2012 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 20EDB21F845E for ; Fri, 9 Nov 2012 11:01:23 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kn2TZJvblf9F for ; Fri, 9 Nov 2012 11:01:22 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 903D621F845D for ; Fri, 9 Nov 2012 11:01:22 -0800 (PST) Received: from [192.168.1.115] (24-121-24-110.npg.sta.suddenlink.net [24.121.24.110]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id qA9J13ht002812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Nov 2012 11:01:07 -0800 (PST) Message-ID: <509D52EF.7010804@isi.edu> Date: Fri, 09 Nov 2012 11:01:03 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Brian E Carpenter References: <50990054.80408@gmail.com> In-Reply-To: <50990054.80408@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Informational: draft-geib-tsvwg-diffserv-interconnection-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, 09 Nov 2012 19:01:23 -0000 On 11/6/2012 4:19 AM, Brian E Carpenter wrote: > Some thoughts on this draft, based on a preview over the weekend: > > 1. I think it is a reasonable idea to specify a small set of traffic classes > that could be the default set in peering relationships. Getting consensus > on the best set could be tricky, of course. > > 2. I may be old fashioned, but I don't really understand why we bother > with layer 2 values at all. If diffserv is working properly, layer 2 can > just give the same service to all packets. (Unless there are non-IP services > on the same wire.) In fact I'd rather that layer 2 doesn't try to impose > any queue or drop behaviour other than FCFS. Because your assumption that IP diffserv is sufficient holds only when layer 2 is composed solely of point-to-point links AND all L2 packets consist only of IP. You addressed the latter point, but not the former. When the L2 is either switched (ethernet) or coordinated MAC (802.11), the diffserv from L3 needs to be mapped to L2 so that competing flows from different sources that are merged onto a single L2 link provide that muxing mechanism the info needed to decide what to prioritize. Joe From rs@netapp.com Fri Nov 9 16:49:45 2012 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 6B63721F868E for ; Fri, 9 Nov 2012 16:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.511 X-Spam-Level: X-Spam-Status: No, score=-10.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Fd7wbprtGxv for ; Fri, 9 Nov 2012 16:49:45 -0800 (PST) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 0186D21F8686 for ; Fri, 9 Nov 2012 16:49:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,749,1344236400"; d="scan'208";a="224158883" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 09 Nov 2012 16:49:44 -0800 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id qAA0niKb017552; Fri, 9 Nov 2012 16:49:44 -0800 (PST) Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.195]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0318.001; Fri, 9 Nov 2012 16:49:43 -0800 From: "Scheffenegger, Richard" To: Michael Tuexen , "randall@lakerest.net" Thread-Topic: draft-stewart-tsvwg-sctpecn-03 Thread-Index: Ac2+2eZ4nXq6WFYETT+H+xPENx9nxg== Date: Sat, 10 Nov 2012 00:49:42 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0D7675AD@SACEXCMBX04-PRD.hq.netapp.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tsvwg@ietf.org" Subject: [tsvwg] draft-stewart-tsvwg-sctpecn-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: Sat, 10 Nov 2012 00:49:45 -0000 Hi Randall, actually, I had read a previous version of this draft some time ago. A few nits: As a matter of personal taste, I would format the three list items in secti= on 3 with a larger indentation, or with a empty line (so that the text star= ts from left in the very next line, ie. a . In particular the sing= le space after CE makes that look almost like a regular paragraph. In section 4.3, perhaps the "o" Bit is better notified using a different sy= mbol ("R" would lend itself), to stand out more clearly after all these zer= os ("0") in the flag field... The following I mentioned earlier, you may remember. Perhaps you want to be= more pedantic (or just cater for me) in saying that the CE counter will fl= ow over from 0xffffffff to 0, instead of staying at the maximum. The backgr= ound here is to make the receiver behavior unambiguous when the sender choo= ses to never send the CWR chunk. (My argument is around this being a counte= r, or a gauge that gets reset by CWR, architecturally). Also, a simple, ove= rflowing counter is easier to implement than a gauge that stays at the max= imum, but with TCP in mind (ECE basically a 1-bit gauge, that needs to be r= eset by CWR) this should be clarified. With or without these changes, I support that draft to get adopted... While I'm at this, I found that draft-stewart-tsvwg-sctp-nonce has expired.= .. During this IETF there was some (brief) mentioning of using ECT1 to denote = "high-density marking" AQM - which was mentioned only as an idea at the mic= rophone. A light weight "sctp-nonce" draft to define chunks returning counters for E= CT(0) and ECT(1) similar to the CE counter above (but without CWR clearing = those) may be needed to support such an idea. But it's probably too early t= o think about this for SCTP yet...=20 Best regards, Richard Scheffenegger From rs@netapp.com Fri Nov 9 16:59:57 2012 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 AD6D521F8B6F for ; Fri, 9 Nov 2012 16:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.521 X-Spam-Level: X-Spam-Status: No, score=-10.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3QtbD6rRrOw for ; Fri, 9 Nov 2012 16:59:57 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5B721F8B6D for ; Fri, 9 Nov 2012 16:59:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,749,1344236400"; d="scan'208";a="708802314" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 09 Nov 2012 16:59:56 -0800 Received: from vmwexceht01-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id qAA0xuIF015806; Fri, 9 Nov 2012 16:59:56 -0800 (PST) Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.195]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0318.001; Fri, 9 Nov 2012 16:59:56 -0800 From: "Scheffenegger, Richard" To: Michael Tuexen , "randall@lakerest.net" Thread-Topic: draft-tuexen-tsvwg-sctp-dtls-encaps Thread-Index: Ac2+3hoXwQGNduo8RnSgAmzi32t2WA== Date: Sat, 10 Nov 2012 00:59:55 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0D767632@SACEXCMBX04-PRD.hq.netapp.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tsvwg@ietf.org" Subject: [tsvwg] draft-tuexen-tsvwg-sctp-dtls-encaps 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, 10 Nov 2012 00:59:57 -0000 Hi, While reading this draft, it felt more like a Info or BCP draft rather than= a STD track RFC... (overall, this draft can be paraphrased "Be sensible wh= en using SCTP over DTLS"). Apart from the obvious loose ends (dependencies on not-yet-adopted drafts) = there is also this one loose end 5.7, multiplexing large chunks. IMHO this = makes it hard, at this stage, to proceed with this draft on STD track;=20 Having that said, I would still support adoption as a WG item... Best regards, Richard Scheffenegger From rs@netapp.com Fri Nov 9 17:15:13 2012 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 590C321F88A8 for ; Fri, 9 Nov 2012 17:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.378 X-Spam-Level: X-Spam-Status: No, score=-10.378 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Wa8-hzxj9mc for ; Fri, 9 Nov 2012 17:15:12 -0800 (PST) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 94E7021F88A6 for ; Fri, 9 Nov 2012 17:15:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,749,1344236400"; d="scan'208,217";a="224162569" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 09 Nov 2012 17:14:59 -0800 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id qAA1EwVP014178; Fri, 9 Nov 2012 17:14:58 -0800 (PST) Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.195]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0318.001; Fri, 9 Nov 2012 17:14:58 -0800 From: "Scheffenegger, Richard" To: =?iso-8859-1?Q?Michael_T=FCxen?= , "randall@lakerest.net" Thread-Topic: draft-tuexen-tsvwg-sctp-sack-immediately-07.txt Thread-Index: AcxvqXzaufWYYqXzR8+4Z459R5Mj2VPNp6IA Date: Sat, 10 Nov 2012 01:14:57 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0D7676DD@SACEXCMBX04-PRD.hq.netapp.com> References: <04A38419-1229-4635-A74D-3603BA76CF19@lurchi.franken.de> In-Reply-To: <04A38419-1229-4635-A74D-3603BA76CF19@lurchi.franken.de> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F0D7676DDSACEXCMBX04PRDh_" MIME-Version: 1.0 Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] draft-tuexen-tsvwg-sctp-sack-immediately-07.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, 10 Nov 2012 01:15:13 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F0D7676DDSACEXCMBX04PRDh_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Again one stupid question: The security considerations only mention RFC4960, but a malicious receiver/= sender is not mentioned there... Could there be any adverse effect when the= I-bit is constantly set? For latency-sensitive applications that appears l= ike something an application programmer wants to do on a permanent basis, t= o never have to wait for any delayed SACK chunk... But forgive me if this is a too TCP-ish view... Regards, Richard Scheffenegger --_000_012C3117EDDB3C4781FD802A8C27DD4F0D7676DDSACEXCMBX04PRDh_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 <= /p>

Again one = stupid question:

 = ;

The securi= ty considerations only mention RFC4960, but a malicious receiver/sender is = not mentioned there… Could there be any adverse effect when the I-bit is constantly set? For latency-sensitive applications that appea= rs like something an application programmer wants to do on a permanent basi= s, to never have to wait for any delayed SACK chunk…

 = ;

But forgiv= e me if this is a too TCP-ish view…

 = ;

Regards,

 = ;

Richard Scheffenegger

--_000_012C3117EDDB3C4781FD802A8C27DD4F0D7676DDSACEXCMBX04PRDh_-- From Michael.Tuexen@lurchi.franken.de Sat Nov 10 00:33:56 2012 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 80AAD21F84B2 for ; Sat, 10 Nov 2012 00:33:56 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vk6+m1zXmvf6 for ; Sat, 10 Nov 2012 00:33:56 -0800 (PST) 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 C864F21F84B1 for ; Sat, 10 Nov 2012 00:33:55 -0800 (PST) Received: from [10.53.147.184] (unknown [80.187.201.11]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id E43C91C0C0693; Sat, 10 Nov 2012 09:33:52 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Michael Tuexen In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F0D7676DD@SACEXCMBX04-PRD.hq.netapp.com> Date: Sat, 10 Nov 2012 09:33:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7D785C4A-BEBF-400E-B420-5594512FE9BB@lurchi.franken.de> References: <04A38419-1229-4635-A74D-3603BA76CF19@lurchi.franken.de> <012C3117EDDB3C4781FD802A8C27DD4F0D7676DD@SACEXCMBX04-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1283) Cc: "tsvwg@ietf.org" , "randall@lakerest.net" Subject: Re: [tsvwg] draft-tuexen-tsvwg-sctp-sack-immediately-07.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, 10 Nov 2012 08:33:56 -0000 On Nov 10, 2012, at 2:14 AM, Scheffenegger, Richard wrote: > =20 > Again one stupid question: > =20 > The security considerations only mention RFC4960, but a malicious = receiver/sender is not mentioned there=85 Could there be any adverse = effect when the I-bit is constantly set? For latency-sensitive = applications that appears like something an application programmer wants = to do on a permanent basis, to never have to wait for any delayed SACK = chunk=85 The receiver can already now use the socket API http://tools.ietf.org/html/rfc6458#section-8.1.19 to set the SACK frequency to 1. The only point is that it can be controlled by the sender... So I don't = think there is an issue here. Best regards Michael > =20 > But forgive me if this is a too TCP-ish view=85 > =20 > Regards, > =20 > Richard Scheffenegger >=20 From Michael.Tuexen@lurchi.franken.de Sat Nov 10 00:37:40 2012 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 B8AF521F84B7 for ; Sat, 10 Nov 2012 00:37:40 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTApHWKUtFLK for ; Sat, 10 Nov 2012 00:37:40 -0800 (PST) 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 5AE7921F87A6 for ; Sat, 10 Nov 2012 00:37:39 -0800 (PST) Received: from [10.53.147.184] (unknown [80.187.201.11]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 9B11C1C0C0693; Sat, 10 Nov 2012 09:37:36 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F0D767632@SACEXCMBX04-PRD.hq.netapp.com> Date: Sat, 10 Nov 2012 09:37:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <42969507-0697-45CA-91B8-617E586BFCE0@lurchi.franken.de> References: <012C3117EDDB3C4781FD802A8C27DD4F0D767632@SACEXCMBX04-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1283) Cc: "tsvwg@ietf.org" , "randall@lakerest.net" Subject: Re: [tsvwg] draft-tuexen-tsvwg-sctp-dtls-encaps 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, 10 Nov 2012 08:37:40 -0000 On Nov 10, 2012, at 1:59 AM, Scheffenegger, Richard wrote: > Hi, >=20 >=20 > While reading this draft, it felt more like a Info or BCP draft rather = than a STD track RFC... (overall, this draft can be paraphrased "Be = sensible when using SCTP over DTLS"). We currently use RFC 2119 terms, so Informational might not be = appropriate. BCP is fine with me, we don't define anything new in the document. >=20 > Apart from the obvious loose ends (dependencies on not-yet-adopted = drafts) there is also this one loose end 5.7, multiplexing large chunks. = IMHO this makes it hard, at this stage, to proceed with this draft on = STD track;=20 The interleaving is intentionally left loose right not. I hope we have = an ID by the next IETF. >=20 > Having that said, I would still support adoption as a WG item... Great. And thanks a lot for the comments. Best regards Michael >=20 > Best regards, >=20 > Richard Scheffenegger >=20 >=20 From karagian@cs.utwente.nl Sat Nov 10 05:10:45 2012 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 D0C0521F852E for ; Sat, 10 Nov 2012 05:10:45 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6AewFHOTho9 for ; Sat, 10 Nov 2012 05:10:44 -0800 (PST) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id DA33F21F852D for ; Sat, 10 Nov 2012 05:10:43 -0800 (PST) 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.318.4; Sat, 10 Nov 2012 14:10:55 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.65]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0318.004; Sat, 10 Nov 2012 14:10:40 +0100 From: To: Thread-Topic: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 Thread-Index: AQHNuG567zXDhOEf1EmojaHb3rIjiJfaAz+MgAEb9QCAABFxXIAGi4cpgAFbBHiAAAGENg== Date: Sat, 10 Nov 2012 13:10:39 +0000 Message-ID: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> References: <87644A58-0C27-4F5A-B09B-BD8EC1F9A10A@g11.org.uk> , <201211091623.qA9GMxVm013855@bagheera.jungle.bt.co.uk> In-Reply-To: <201211091623.qA9GMxVm013855@bagheera.jungle.bt.co.uk> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.134.191.251] Content-Type: multipart/alternative; boundary="_000_87222982329F43DFBFD89D3705AFE101mimectl_" MIME-Version: 1.0 Cc: philip.eardley@bt.com, anuragb@cisco.com, tsvwg@ietf.org Subject: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-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: Sat, 10 Nov 2012 13:10:45 -0000 --_000_87222982329F43DFBFD89D3705AFE101mimectl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bob, Thanks very much for the comments! I think that they are very useful! It will be very beneficiary for the fast progress of this draft if you woul= d like to contribute as a co-author to this draft and write this additional= section that describes "that the PCN-ingress can refer flow admission and termination decisions to a central decision point (using e.g. COPS), which = will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingr= ess could itself be the policy decision point.)" Best regards, Georgios ________________________________ Van: Bob Briscoe [bob.briscoe@bt.com] Verzonden: vrijdag 9 november 2012 16:33 To: Karagiannis, G. (EWI) Cc: carlberg@g11.org.uk; anuragb@cisco.com; tsvwg@ietf.org; EARDLEY, Phil Onderwerp: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 Georgios, I shall post my full review of this draft in the next few days (needs typing up - currently scribbled on a paper copy). This email is solely in response to your answer about on-path vs off-path policy. At 18:55 04/11/2012, karagian@cs.utwente.nl wrote: >So in this case an additional signaling protocol will be >needed to be specified that covers the signaling between the >PCN-egress-node and the centralized node >and between PCN-ingress-node and the centralized node. >In PCN we decdided to only focus on the specification of the >signaling protocol that completes the >feedback loop from PCN-egress-node to PCN-ingress-node and to focus >on the signaling protocol >used between the edge nodes and the centralized node. When I/we originally designed CL-PCN over RSVP (2005), the idea was that it would fit with the policy-based admission control (PBAC) architecture of RFC2753. In this architecture, an Intserv node at the ingress to a domain is the policy enforcement point (PEP), and it refers to a logically centralised 'policy decision point' (PDP) for decisions on which flows to block/terminate, typically using COPS. To make this doc fit the PBAC framework, all we have to do is: * Describe the PCN-ingress only as the PCN-ingress and not as the decision point (find 'decision' throughout doc and fix). * Add a section saying the PCN-ingress can refer flow admission and termination decisions to a central decision point (using e.g. COPS), which will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingress could itself be the policy decision point.) * Refer to this new PBAC section from Section 3.11 giving the admission decision procedure. * Some people might think this means COPS will need new protocol elements to carry PCN marking rates to the policy decision point. But PCN marking rates are irrelevant to the policy decision: the PCN-ingress just uses PCN to determine whether it needs to block or terminate, and it refers to the policy decision point for which flows to block/terminate. * Unfortunately, neither of the two PCN system descriptions [RFC6661, RFC6662] describe a PBAC-based case. The architecture [RFC5559] refers to the PBAC framework [RFC2753] but unfortunately doesn't spell out how it fits. Originally, I referenced PBAC from RFC5559, but just as the PCN w-g was closing I realised that (some?) others in the PCN w-g were working under the assumption that the only way to talk to a centralised policy node was from the egress, possibly without being aware of the contents of RFC2753. I think it's OK to introduce a new architectural arrangement in this RSVP doc, given RFC2753 is specific to the way RSVP works. Bob At 12:28 05/11/2012, karagian@cs.utwente.nl wrote: >Hi Ken, > >Thank you very much! >We will try to catch Francois and discuss the last (in line) issue with hi= m! > >Best regards, >Georgios > >________________________________________ >Van: ken carlberg [carlberg@g11.org.uk] >Verzonden: maandag 5 november 2012 13:23 >To: Karagiannis, G. (EWI) >Cc: tsvwg@ietf.org; anuragb@cisco.com >Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03 > >Georgios, > > > Georgios: We will try to explain the rationale of why we consider > that RSVP can only be used for the situation that the > > decision point is collocated with the PCN-ingress-node. The main > reason of this is that in the case that the > > decision point is collocated with the PCN-ingress-node,the > required signaling protocol used to complete a > > feedback loop from egress to ingress can be an entirely on-path > protocol, like what RSVP is. > > In the situation that the the decision point is a centralized > node, then the required signaling protocol > > can be a combination of an on-path and off-path protocol. This is > because the > > decision point might not be located on the data path! So in this > case an additional signaling protocol will be > > needed to be specified that covers the signaling between the > PCN-egress-node and the centralized node > > and between PCN-ingress-node and the centralized node. > > In PCN we decdided to only focus on the specification of the > signaling protocol that completes the > > feedback loop from PCN-egress-node to PCN-ingress-node and to > focus on the signaling protocol > > used between the edge nodes and the centralized node. > > This is also the reason of why PCN WG decided to only focus on > the situation that the decision point is > > collocated with the PCN-ingress-node. > >Great, this is helpful, and this is the information that needs to be >in the draft. > > >> 6) This comment is just for you to contemplate -- I'm not > expecting any changes. > >> I noticed that you have a fair number of SHOULD, and some SHOULD NOTs. > >> And it seems a lot of this is a carry over from rfc-4860, so in > a sense you are inheriting an approach that > >> was agreed to from an earlier effort. But I wonder in the back > of my mind, what impact occurs if > >> an implementor doesn't follow the SHOULD? Does the design break > in supporting PCN? > >> Again, I want to stress that this isnt a show stopper, but I > would appreciate it if you gave it some thought. > > > > Georgios: Yes, in several cases the design might break in supporting PC= N. > > This is also the reason of using SHOULD instead of MAY. Do you > want us to explain this in more detail in the draft? > >well, actually, I was more curious as to why a number of these cases >are SHOULD instead of MUST. Again, the SHOULD's in your document >seem to be a carry-over from rfc-4860 (which set the precedent), so >its a bit unfair for you to explain what was done in an earlier >effort. I just wanted to make sure you gave some thought to the >subject. And if things will break if SHOULD is not followed by an >implementer/configuration, then maybe you should be more stringent >and change things to MUST. Perhaps a brief private conversation >with Francois Le Faucheur will be helpful. > >cheers, > >-ken ________________________________________________________________ Bob Briscoe, BT Innovate & Design --_000_87222982329F43DFBFD89D3705AFE101mimectl_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Bob,

 =

Thanks very much for the= comments! I think that they are very useful!

 =

It will be very benefici= ary for the fast progress of this draft if you would like to cont= ribute as a co-author to this draft and write this additional section that describes "that the PCN-ingress can refe= r flow admission and
termination decisions to a central decision point (using e.g. COPS), which = will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingr= ess could itself be the policy decision point.)"

 =

Best regards,=

Georgios

 =

Van: Bob Briscoe [bob.briscoe@bt.com]
Verzonden: vrijdag 9 november 2012 16:33
To: Karagiannis, G. (EWI)
Cc: carlberg@g11.org.uk; anuragb@cisco.com; tsvwg@ietf.org; EARDLEY,= Phil
Onderwerp: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03

Georgios,

I shall post my full review of this draft in the next few days (needs
typing up - currently scribbled on a paper copy). This email is
solely in response to your answer about on-path vs off-path policy.

At 18:55 04/11/2012, karagian@cs.utwente.nl wrote:
>So in this case an additional signaling protocol will be
>needed to be specified that covers the signaling between the
>PCN-egress-node and the centralized node
>and between PCN-ingress-node and the centralized node.
>In PCN we decdided to only focus on the specification of the
>signaling protocol that completes the
>feedback loop from PCN-egress-node to PCN-ingress-node and to focus >on the signaling protocol
>used between the edge nodes and the centralized node.

When I/we originally designed CL-PCN over RSVP (2005), the idea was
that it would fit with the policy-based admission control (PBAC)
architecture of RFC2753. In this architecture, an Intserv node at the
ingress to a domain is the policy enforcement point (PEP), and it
refers to a logically centralised 'policy decision point' (PDP) for
decisions on which flows to block/terminate, typically using COPS.

To make this doc fit the PBAC framework, all we have to do is:
* Describe the PCN-ingress only as the PCN-ingress and not as the
decision point (find 'decision' throughout doc and fix).
* Add a section saying the PCN-ingress can refer flow admission and
termination decisions to a central decision point (using e.g. COPS),
which will respond to the PCN-ingress as per RFC2753. (Alternatively
the PCN-ingress could itself be the policy decision point.)
* Refer to this new PBAC section from Section 3.11 giving the
admission decision procedure.

* Some people might think this means COPS will need new protocol
elements to carry PCN marking rates to the policy decision point. But
PCN marking rates are irrelevant to the policy decision: the
PCN-ingress just uses PCN to determine whether it needs to block or
terminate, and it refers to the policy decision point for which flows
to block/terminate.

* Unfortunately, neither of the two PCN system descriptions [RFC6661,
RFC6662] describe a PBAC-based case. The architecture [RFC5559]
refers to the PBAC framework [RFC2753] but unfortunately doesn't
spell out how it fits. Originally, I referenced PBAC from RFC5559,
but just as the PCN w-g was closing I realised that (some?) others in
the PCN w-g were working under the assumption that the only way to
talk to a centralised policy node was from the egress, possibly
without being aware of the contents of RFC2753.

I think it's OK to introduce a new architectural arrangement in this
RSVP doc, given RFC2753 is specific to the way RSVP works.


Bob



At 12:28 05/11/2012, karagian@cs.utwente.nl wrote:
>Hi Ken,
>
>Thank you very much!
>We will try to catch Francois and discuss the last (in line) issue with= him!
>
>Best regards,
>Georgios
>
>________________________________________
>Van: ken carlberg [carlberg@g11.org.uk]
>Verzonden: maandag 5 november 2012 13:23
>To: Karagiannis, G. (EWI)
>Cc: tsvwg@ietf.org; anuragb@cisco.com
>Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03
>
>Georgios,
>
> > Georgios: We will try to explain the rationale of why we consider=
> that RSVP can only be used for the situation that the
> > decision point is collocated with the PCN-ingress-node. The main =
> reason of this is that in the case that the
> > decision point is collocated with the PCN-ingress-node,the
> required signaling protocol used to complete a
> > feedback loop from egress to ingress can be an entirely on-path <= br> > protocol, like what RSVP is.
> > In the situation that the the decision point is a centralized > node, then the required signaling protocol
> > can be a combination of an on-path and off-path protocol. This is=
> because the
> > decision point might not be located on the data path! So in this =
> case an additional signaling protocol will be
> > needed to be specified that covers the signaling between the
> PCN-egress-node and the centralized node
> > and between PCN-ingress-node and the centralized node.
> > In PCN we decdided to only focus on the specification of the
> signaling protocol that completes the
> > feedback loop from PCN-egress-node to PCN-ingress-node and to > focus on the signaling protocol
> > used between the edge nodes and the centralized node.
> > This is also the reason of why PCN WG decided to only focus on > the situation that the decision point is
> > collocated with the PCN-ingress-node.
>
>Great, this is helpful, and this is the information that needs to be >in the draft.
>
> >> 6) This comment is just for you to contemplate -- I'm not > expecting any changes.
> >> I noticed that you have a fair number of SHOULD, and some SHO= ULD NOTs.
> >> And it seems a lot of this is a carry over from rfc-4860, so = in
> a sense you are inheriting an approach that
> >> was agreed to from an earlier effort.  But I wonder in t= he back
> of my mind, what impact occurs if
> >> an implementor doesn't follow the SHOULD?  Does the desi= gn break
> in supporting PCN?
> >> Again, I want to stress that this isnt a show stopper, but I =
> would appreciate it if you gave it some thought.
> >
> > Georgios: Yes, in several cases the design might break in support= ing PCN.
> > This is also the reason of using SHOULD instead of MAY. Do you > want us to explain this in more detail in the draft?
>
>well, actually, I was more curious as to why a number of these cases >are SHOULD instead of MUST.  Again, the SHOULD's in your document =
>seem to be a carry-over from rfc-4860 (which set the precedent), so >its a bit unfair for you to explain what was done in an earlier
>effort.  I just wanted to make sure you gave some thought to the <= br> >subject.  And if things will break if SHOULD is not followed by an=
>implementer/configuration, then maybe you should be more stringent
>and change things to MUST.  Perhaps a brief private conversation <= br> >with Francois Le Faucheur will be helpful.
>
>cheers,
>
>-ken

________________________________________________________________
Bob Briscoe,          &nb= sp;            =          BT Innovate & Design <= br>
--_000_87222982329F43DFBFD89D3705AFE101mimectl_-- From Ruediger.Geib@telekom.de Mon Nov 12 00:33:02 2012 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 9CA8521F84FA for ; Mon, 12 Nov 2012 00:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iS6GHCrojTaz for ; Mon, 12 Nov 2012 00:33:01 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id EDC9521F84DD for ; Mon, 12 Nov 2012 00:33:00 -0800 (PST) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail21.telekom.de with ESMTP; 12 Nov 2012 09:32:54 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 12 Nov 2012 09:32:47 +0100 From: To: , Date: Mon, 12 Nov 2012 09:32:44 +0100 Thread-Topic: Tsvwg meeting: Diffserv - some thoughts Thread-Index: Ac29yST0JVzEwAQAQUyDDrqSYh60uAAiWfnQAAyLIrAAiOuIEA== Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE7120E1DD45C@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE7120E1DD693@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7120E1DD693@MX15A.corp.emc.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: tsvwg@ietf.org Subject: Re: [tsvwg] Tsvwg meeting: Diffserv - some thoughts 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, 12 Nov 2012 08:33:02 -0000 David, James, got the point related to interconnection and no, I do not just look at DiffServ from a Backbone perspective. The company I work for runs some million DSL accesses and if any of you bothers, you'll find at least one SIP related QoS publication I wrote. The reason for my last mail was that James goes for treating video conference audio different than the pictures. That's probably based on customer feedback. What that implies is, there has been a packet dropping bottleneck. And at least one option of application based class design should assume its presence. The audio/video experts of my company (on of them Alexander Raake, http://en.wikipedia.org/wiki/Alexander_Raake) recommend forwarding audio and video frames in the same queue. His efforts on objective video quality models show, that viewers regard a loss of lip-synch as quality degradation. I'll probably see him this week and ask hom for his view. That may be a streaming versus conferencing issue (different environments and audience) and I'm open for discussion. What I suggest is to get more clarity about which problem we try to solve by DiffServ regarding bottlenecks. Sorry if that is clear to all and I'm a bit thick here. Regards, R=FCdiger -----Original Message----- From: Black, David [mailto:david.black@emc.com] Sent: Friday, November 09, 2012 5:08 PM To: Geib, R=FCdiger Cc: tsvwg@ietf.org Subject: RE: Tsvwg meeting: Diffserv - some thoughts R=FCdiger, While Diffserv was significantly motivated by service provider core and backbone networks, the applicability of Diffserv has never been limited to that class of networks. For example, see slide 2 in the slide deck that James used yesterday: http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-13.pptx There are almost certainly opportunities to differentiate treatment of interactive media traffic (that needs a low jitter budget) from non-interactive media traffic selectively near known/expected bottlenecks even if there may not be a rationale for doing that differentiation globally. The sense of the room in yesterday's tsvwg meeting (will need to be confirmed on this list, separate message coming soon) was that the IETF should work on the diffserv interconnect problem represented in the ITU-T SG12 liaison and your draft. IMHO, that work is likely to result in a small number of interconnect traffic classes that may or may not resemble the treatment aggregates in RFC 5127. There will be nothing to stop a network from choosing to deploy just those interconnect classes internally in addition to using them for interconnection. A network could also internally deploy a subset of the RFC 4594 (or successor) traffic classes, or even just some or all of the four treatment aggregates in RFC 5127 (or successor). In particular, there is no current or intended requirement that any network deploy all of the diffserv service classes in RFC 4594 or any successor. I also want to be clear that I am not assuming that the interconnect traffic classes will be based on an update to RFC 5127, as they address different problems - the approach here is TBD by the WG. Thanks, --David > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Friday, November 09, 2012 4:01 AM > To: Black, David > Cc: tsvwg@ietf.org > Subject: Tsvwg meeting: Diffserv - some thoughts > > David, > > I'm not fully clear about which problem we (should) try to solve on DiffS= erv > in tsvwg: > > - the backbone or SP networks don't seem to be a QoS issue. A few classes > probably will be sufficient. > - tsvwg isn't chartered to solve application problems (like wireless acce= ss, > rtp packets only all x milliseconds and so on. > - if a bottleneck is overbooked, DiffServ can distribute capacity, but no= t > create additional one. > > Then some thoughts on streaming and teleconferencing > - streaming is delay tolerant. Where would one locate the large buffer? O= n a > 10 GE interface? On a bottleneck interface? Very close to the appli= cation? > - streaming does not reduce traffic during congestion (multicast can't). > What's the effect of assigning a deep buffer for it at backbone int= erfaces, > if there's congestion? > - what's a good argument not to produce both across the same queue/class? > > In sum: what does a DS RFC reader learn from a class description in terms= loss tolerance yes/no, > delay tolerance yes/no and so on? My take: without understanding the pres= ent or required transport > properties of an application, a purely application based performance requ= irement description can > be misleading. > > If we conclude that many classes are required to deal with bottleneck beh= aviour and we expect > this bottleneck to be present (and DiffServ t kick in), then what do we n= eed: > > - many classes, each of which has to be engineered by non-QoS-experts bas= ed on a configuration > guidance given by 4594? That would be preconfigured, I guess and every = implementor will > apply phantasy. If like 10 PHBs are implemented, which gets what share = of the bottleneck > bandwidth? How do they compete for spare capacity? How is traffic admit= ted? > > - or do we try to solve an admission control (or traffic engineering) pro= blem by creating ever > new class defintions. > > Maybe it's worth to think about a problem statement to get a clear descri= ption of the issues, > we want to deal with. DiffServ created a set of tools, applicable for rou= ters or networks > largely. It seems to me, that now the community starts to look at QoS mor= e from an end to > end perspective, but tries to solve issues with router mechanisms. That's= not what DiffServ > is designed for. > > Regards, > > R=FCdiger > > > > > > From randall@lakerest.net Mon Nov 12 07:09:56 2012 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 3E55721F859C for ; Mon, 12 Nov 2012 07:09:56 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukQk3WRAdzSm for ; Mon, 12 Nov 2012 07:09:55 -0800 (PST) Received: from lakerest.net (lakerest.net [70.155.160.98]) by ietfa.amsl.com (Postfix) with ESMTP id 920FB21F85AD for ; Mon, 12 Nov 2012 07:09:55 -0800 (PST) Received: from [192.168.0.2] (67-5-108-133.spok.qwest.net [67.5.108.133]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id qACF9sFv057887 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Nov 2012 10:09:56 -0500 (EST) (envelope-from randall@lakerest.net) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Randy Stewart In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F0D7676DD@SACEXCMBX04-PRD.hq.netapp.com> Date: Mon, 12 Nov 2012 10:09:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <062638C4-CACF-4C07-AB87-31F1AA82FAA6@lakerest.net> References: <04A38419-1229-4635-A74D-3603BA76CF19@lurchi.franken.de> <012C3117EDDB3C4781FD802A8C27DD4F0D7676DD@SACEXCMBX04-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1283) Cc: =?iso-8859-1?Q?Michael_T=FCxen?= , "tsvwg@ietf.org" Subject: Re: [tsvwg] draft-tuexen-tsvwg-sctp-sack-immediately-07.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, 12 Nov 2012 15:09:56 -0000 Actually, if you want to be real TCPish the original TCP RFC (793) = allows you to sack every packet=85 not that folks do that but I do think its = legal.. R On Nov 9, 2012, at 8:14 PM, Scheffenegger, Richard wrote: > =20 > Again one stupid question: > =20 > The security considerations only mention RFC4960, but a malicious = receiver/sender is not mentioned there=85 Could there be any adverse = effect when the I-bit is constantly set? For latency-sensitive = applications that appears like something an application programmer wants = to do on a permanent basis, to never have to wait for any delayed SACK = chunk=85 > =20 > But forgive me if this is a too TCP-ish view=85 > =20 > Regards, > =20 > Richard Scheffenegger >=20 ----- Randall Stewart randall@lakerest.net From david.black@emc.com Mon Nov 12 11:00:23 2012 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 3E0AA21F8682 for ; Mon, 12 Nov 2012 11:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdxHvURBMKn3 for ; Mon, 12 Nov 2012 11:00:22 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 259EA21F8612 for ; Mon, 12 Nov 2012 11:00:21 -0800 (PST) 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 qACJ0HNV030699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Nov 2012 14:00:19 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Mon, 12 Nov 2012 13:59:55 -0500 Received: from mxhub02.corp.emc.com (mxhub02.corp.emc.com [10.254.141.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qACIxs0c030710; Mon, 12 Nov 2012 13:59:54 -0500 Received: from mx15a.corp.emc.com ([169.254.1.120]) by mxhub02.corp.emc.com ([10.254.141.104]) with mapi; Mon, 12 Nov 2012 13:59:55 -0500 From: "Black, David" To: "Ruediger.Geib@telekom.de" Date: Mon, 12 Nov 2012 13:59:53 -0500 Thread-Topic: Tsvwg meeting: Diffserv - some thoughts Thread-Index: Ac29yST0JVzEwAQAQUyDDrqSYh60uAAiWfnQAAyLIrAAiOuIEAAXwhyg Message-ID: <8D3D17ACE214DC429325B2B98F3AE71284B59D86@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE7120E1DD45C@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE7120E1DD693@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Tsvwg meeting: Diffserv - some thoughts 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, 12 Nov 2012 19:00:23 -0000 > That may be a streaming versus conferencing issue (different > environments and audience) and I'm open for discussion. Good - even if/when audio and video are in different service classes in RFC 4594, they don't have to be in different queues in the implementation, e.g., see RFC 5127. > What I suggest is to get more clarity about which problem we > try to solve by DiffServ regarding bottlenecks. Sorry if > that is clear to all and I'm a bit thick here. We're on the same page here. The only initial result of the discussion of James' draft last week is that we definitely have a problem with the absence of the distinction between interactive vs. non-interactive media traffic. I have the action items to draft crisp questions to the list about the other things that James proposes changing so that we can have focused discussions around whether to change them. Thanks, --David > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Monday, November 12, 2012 3:33 AM > To: Black, David; jmpolk@cisco.com > Cc: tsvwg@ietf.org > Subject: RE: Tsvwg meeting: Diffserv - some thoughts >=20 > David, James, >=20 > got the point related to interconnection and no, I do not just > look at DiffServ from a Backbone perspective. The company I work > for runs some million DSL accesses and if any of you bothers, > you'll find at least one SIP related QoS publication I wrote. >=20 > The reason for my last mail was that James goes for treating video > conference audio different than the pictures. That's probably > based on customer feedback. What that implies is, there has > been a packet dropping bottleneck. And at least one option of > application based class design should assume its presence. >=20 > The audio/video experts of my company (on of them Alexander Raake, > http://en.wikipedia.org/wiki/Alexander_Raake) > recommend forwarding audio and video frames in the same queue. > His efforts on objective video quality models show, > that viewers regard a loss of lip-synch as quality degradation. > I'll probably see him this week and ask hom for his view. >=20 > That may be a streaming versus conferencing issue (different > environments and audience) and I'm open for discussion. >=20 > What I suggest is to get more clarity about which problem we > try to solve by DiffServ regarding bottlenecks. Sorry if > that is clear to all and I'm a bit thick here. >=20 > Regards, R=FCdiger >=20 >=20 > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Friday, November 09, 2012 5:08 PM > To: Geib, R=FCdiger > Cc: tsvwg@ietf.org > Subject: RE: Tsvwg meeting: Diffserv - some thoughts >=20 > R=FCdiger, >=20 > >=20 > While Diffserv was significantly motivated by service provider core > and backbone networks, the applicability of Diffserv has never been > limited to that class of networks. For example, see slide 2 in the > slide deck that James used yesterday: >=20 > http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-13.pptx >=20 > There are almost certainly opportunities to differentiate treatment > of interactive media traffic (that needs a low jitter budget) from > non-interactive media traffic selectively near known/expected > bottlenecks even if there may not be a rationale for doing that > differentiation globally. >=20 > The sense of the room in yesterday's tsvwg meeting (will need to be > confirmed on this list, separate message coming soon) was that the > IETF should work on the diffserv interconnect problem represented > in the ITU-T SG12 liaison and your draft. IMHO, that work is likely > to result in a small number of interconnect traffic classes that may > or may not resemble the treatment aggregates in RFC 5127. There will > be nothing to stop a network from choosing to deploy just those > interconnect classes internally in addition to using them for > interconnection. A network could also internally deploy a subset > of the RFC 4594 (or successor) traffic classes, or even just some > or all of the four treatment aggregates in RFC 5127 (or successor). >=20 > In particular, there is no current or intended requirement that any > network deploy all of the diffserv service classes in RFC 4594 or any > successor. I also want to be clear that I am not assuming that the > interconnect traffic classes will be based on an update to RFC > 5127, as they address different problems - the approach here is > TBD by the WG. >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > > Sent: Friday, November 09, 2012 4:01 AM > > To: Black, David > > Cc: tsvwg@ietf.org > > Subject: Tsvwg meeting: Diffserv - some thoughts > > > > David, > > > > I'm not fully clear about which problem we (should) try to solve on Dif= fServ > > in tsvwg: > > > > - the backbone or SP networks don't seem to be a QoS issue. A few class= es > > probably will be sufficient. > > - tsvwg isn't chartered to solve application problems (like wireless ac= cess, > > rtp packets only all x milliseconds and so on. > > - if a bottleneck is overbooked, DiffServ can distribute capacity, but = not > > create additional one. > > > > Then some thoughts on streaming and teleconferencing > > - streaming is delay tolerant. Where would one locate the large buffer?= On a > > 10 GE interface? On a bottleneck interface? Very close to the > application? > > - streaming does not reduce traffic during congestion (multicast can't)= . > > What's the effect of assigning a deep buffer for it at backbone > interfaces, > > if there's congestion? > > - what's a good argument not to produce both across the same queue/clas= s? > > > > In sum: what does a DS RFC reader learn from a class description in ter= ms > loss tolerance yes/no, > > delay tolerance yes/no and so on? My take: without understanding the pr= esent > or required transport > > properties of an application, a purely application based performance > requirement description can > > be misleading. > > > > If we conclude that many classes are required to deal with bottleneck > behaviour and we expect > > this bottleneck to be present (and DiffServ t kick in), then what do we > need: > > > > - many classes, each of which has to be engineered by non-QoS-experts b= ased > on a configuration > > guidance given by 4594? That would be preconfigured, I guess and ever= y > implementor will > > apply phantasy. If like 10 PHBs are implemented, which gets what shar= e of > the bottleneck > > bandwidth? How do they compete for spare capacity? How is traffic > admitted? > > > > - or do we try to solve an admission control (or traffic engineering) > problem by creating ever > > new class defintions. > > > > Maybe it's worth to think about a problem statement to get a clear > description of the issues, > > we want to deal with. DiffServ created a set of tools, applicable for > routers or networks > > largely. It seems to me, that now the community starts to look at QoS m= ore > from an end to > > end perspective, but tries to solve issues with router mechanisms. That= 's > not what DiffServ > > is designed for. > > > > Regards, > > > > R=FCdiger > > > > > > > > > > > > >=20 From brian.e.carpenter@gmail.com Mon Nov 12 23:58:01 2012 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 2E63A21F88E4 for ; Mon, 12 Nov 2012 23:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.604 X-Spam-Level: X-Spam-Status: No, score=-101.604 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FF0ayJTquul for ; Mon, 12 Nov 2012 23:57:59 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7136121F88EA for ; Mon, 12 Nov 2012 23:57:59 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so3301649wgb.13 for ; Mon, 12 Nov 2012 23:57:58 -0800 (PST) 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=5IoQKxG8cAGElUr3SMEK4gbtsYsIfy0cwF0Bm9XfTrY=; b=ayRPsLrHRmhwcaj2NW1XtUUNRxa9uSWdZO5akdAVgo9rGDE4tqwiwQTmPJoGe3jUpS eNDIqJ7CiuogWDqq/ANPRDIpNRt5qCfzmO4D2o0F25a+EAJyLEP8GEPN15YhyNYrpE0M zNmNu2yn5x9LEGT9r33aMwHHLfJogRkNFgzlSxcC7jpzWw9LgDDgyb7YB5A9bfgJEwx5 aqauIix13/rwZExlyCgY7K6Gw2DAxK3Yua2BQ1tY9FIHjtp7R5PC6tzyF+91chbuKaUJ BiyoOLHV9l63rBum87oK8ZQK6/m0ROtz4ZQ+4V1e6in7FVwsgKIfyaI1tFdp/Yqj+RZk Q1og== Received: by 10.180.94.226 with SMTP id df2mr18704371wib.11.1352793478289; Mon, 12 Nov 2012 23:57:58 -0800 (PST) Received: from [192.168.1.65] (host-2-102-216-97.as13285.net. [2.102.216.97]) by mx.google.com with ESMTPS id hf10sm18206866wib.0.2012.11.12.23.57.56 (version=SSLv3 cipher=OTHER); Mon, 12 Nov 2012 23:57:57 -0800 (PST) Message-ID: <50A1FD89.2060200@gmail.com> Date: Tue, 13 Nov 2012 07:58:01 +0000 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: <8D3D17ACE214DC429325B2B98F3AE7120E1DD45C@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE7120E1DD693@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71284B59D86@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71284B59D86@MX15A.corp.emc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Tsvwg meeting: Diffserv - some thoughts 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, 13 Nov 2012 07:58:01 -0000 On 12/11/2012 18:59, Black, David wrote: >> That may be a streaming versus conferencing issue (different >> environments and audience) and I'm open for discussion. >=20 > Good - even if/when audio and video are in different service > classes in RFC 4594, they don't have to be in different queues > in the implementation, e.g., see RFC 5127. Isn't there a problem when mixing elephants and mice in this way? Although they might have closely related requirements for QoS metrics, video elephants can trample on audio mice when they share a queue. >> What I suggest is to get more clarity about which problem we >> try to solve by DiffServ regarding bottlenecks. Sorry if >> that is clear to all and I'm a bit thick here. >=20 > We're on the same page here. The only initial result of the > discussion of James' draft last week is that we definitely have > a problem with the absence of the distinction between interactive > vs. non-interactive media traffic. =20 Especially given that interactive traffic is often enough hidden in TCP streams these days. There's no easy way to classify this traffic except at the source. Brian > I have the action items to > draft crisp questions to the list about the other things that > James proposes changing so that we can have focused discussions > around whether to change them. >=20 >=20 >=20 > Thanks, > --David >=20 >=20 >> -----Original Message----- >> From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] >> Sent: Monday, November 12, 2012 3:33 AM >> To: Black, David; jmpolk@cisco.com >> Cc: tsvwg@ietf.org >> Subject: RE: Tsvwg meeting: Diffserv - some thoughts >> >> David, James, >> >> got the point related to interconnection and no, I do not just >> look at DiffServ from a Backbone perspective. The company I work >> for runs some million DSL accesses and if any of you bothers, >> you'll find at least one SIP related QoS publication I wrote. >> >> The reason for my last mail was that James goes for treating video >> conference audio different than the pictures. That's probably >> based on customer feedback. What that implies is, there has >> been a packet dropping bottleneck. And at least one option of >> application based class design should assume its presence. >> >> The audio/video experts of my company (on of them Alexander Raake, >> http://en.wikipedia.org/wiki/Alexander_Raake) >> recommend forwarding audio and video frames in the same queue. >> His efforts on objective video quality models show, >> that viewers regard a loss of lip-synch as quality degradation. >> I'll probably see him this week and ask hom for his view. >> >> That may be a streaming versus conferencing issue (different >> environments and audience) and I'm open for discussion. >> >> What I suggest is to get more clarity about which problem we >> try to solve by DiffServ regarding bottlenecks. Sorry if >> that is clear to all and I'm a bit thick here. >> >> Regards, R=C3=BCdiger >> >> >> -----Original Message----- >> From: Black, David [mailto:david.black@emc.com] >> Sent: Friday, November 09, 2012 5:08 PM >> To: Geib, R=C3=BCdiger >> Cc: tsvwg@ietf.org >> Subject: RE: Tsvwg meeting: Diffserv - some thoughts >> >> R=C3=BCdiger, >> >> >> >> While Diffserv was significantly motivated by service provider core >> and backbone networks, the applicability of Diffserv has never been >> limited to that class of networks. For example, see slide 2 in the >> slide deck that James used yesterday: >> >> http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-13.pptx >> >> There are almost certainly opportunities to differentiate treatment >> of interactive media traffic (that needs a low jitter budget) from >> non-interactive media traffic selectively near known/expected >> bottlenecks even if there may not be a rationale for doing that >> differentiation globally. >> >> The sense of the room in yesterday's tsvwg meeting (will need to be >> confirmed on this list, separate message coming soon) was that the >> IETF should work on the diffserv interconnect problem represented >> in the ITU-T SG12 liaison and your draft. IMHO, that work is likely >> to result in a small number of interconnect traffic classes that may >> or may not resemble the treatment aggregates in RFC 5127. There will >> be nothing to stop a network from choosing to deploy just those >> interconnect classes internally in addition to using them for >> interconnection. A network could also internally deploy a subset >> of the RFC 4594 (or successor) traffic classes, or even just some >> or all of the four treatment aggregates in RFC 5127 (or successor). >> >> In particular, there is no current or intended requirement that any >> network deploy all of the diffserv service classes in RFC 4594 or any >> successor. I also want to be clear that I am not assuming that the >> interconnect traffic classes will be based on an update to RFC >> 5127, as they address different problems - the approach here is >> TBD by the WG. >> >> Thanks, >> --David >> >>> -----Original Message----- >>> From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] >>> Sent: Friday, November 09, 2012 4:01 AM >>> To: Black, David >>> Cc: tsvwg@ietf.org >>> Subject: Tsvwg meeting: Diffserv - some thoughts >>> >>> David, >>> >>> I'm not fully clear about which problem we (should) try to solve on D= iffServ >>> in tsvwg: >>> >>> - the backbone or SP networks don't seem to be a QoS issue. A few cla= sses >>> probably will be sufficient. >>> - tsvwg isn't chartered to solve application problems (like wireless = access, >>> rtp packets only all x milliseconds and so on. >>> - if a bottleneck is overbooked, DiffServ can distribute capacity, bu= t not >>> create additional one. >>> >>> Then some thoughts on streaming and teleconferencing >>> - streaming is delay tolerant. Where would one locate the large buffe= r? On a >>> 10 GE interface? On a bottleneck interface? Very close to the >> application? >>> - streaming does not reduce traffic during congestion (multicast can'= t). >>> What's the effect of assigning a deep buffer for it at backbone= >> interfaces, >>> if there's congestion? >>> - what's a good argument not to produce both across the same queue/cl= ass? >>> >>> In sum: what does a DS RFC reader learn from a class description in t= erms >> loss tolerance yes/no, >>> delay tolerance yes/no and so on? My take: without understanding the = present >> or required transport >>> properties of an application, a purely application based performance >> requirement description can >>> be misleading. >>> >>> If we conclude that many classes are required to deal with bottleneck= >> behaviour and we expect >>> this bottleneck to be present (and DiffServ t kick in), then what do = we >> need: >>> - many classes, each of which has to be engineered by non-QoS-experts= based >> on a configuration >>> guidance given by 4594? That would be preconfigured, I guess and ev= ery >> implementor will >>> apply phantasy. If like 10 PHBs are implemented, which gets what sh= are of >> the bottleneck >>> bandwidth? How do they compete for spare capacity? How is traffic >> admitted? >>> - or do we try to solve an admission control (or traffic engineering)= >> problem by creating ever >>> new class defintions. >>> >>> Maybe it's worth to think about a problem statement to get a clear >> description of the issues, >>> we want to deal with. DiffServ created a set of tools, applicable for= >> routers or networks >>> largely. It seems to me, that now the community starts to look at QoS= more >> from an end to >>> end perspective, but tries to solve issues with router mechanisms. Th= at's >> not what DiffServ >>> is designed for. >>> >>> Regards, >>> >>> R=C3=BCdiger >>> >>> >>> >>> >>> >>> >=20 >=20 From david.black@emc.com Tue Nov 13 06:33:48 2012 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 36E0B21F86AD for ; Tue, 13 Nov 2012 06:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2FEuNh7taSh for ; Tue, 13 Nov 2012 06:33:44 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6FB21F86B5 for ; Tue, 13 Nov 2012 06:33:42 -0800 (PST) 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 qADEXcjc018385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Nov 2012 09:33:38 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 13 Nov 2012 09:33:28 -0500 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 qADEUxT7028128; Tue, 13 Nov 2012 09:33:26 -0500 Received: from mx15a.corp.emc.com ([169.254.1.120]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Tue, 13 Nov 2012 09:33:14 -0500 From: "Black, David" To: Brian E Carpenter Date: Tue, 13 Nov 2012 09:33:12 -0500 Thread-Topic: [tsvwg] Tsvwg meeting: Diffserv - some thoughts Thread-Index: Ac3BdKeHfdeLKLvOTbu87unfWm0S8QANwrXw Message-ID: <8D3D17ACE214DC429325B2B98F3AE71284B59E8C@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE7120E1DD45C@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE7120E1DD693@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71284B59D86@MX15A.corp.emc.com> <50A1FD89.2060200@gmail.com> In-Reply-To: <50A1FD89.2060200@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Tsvwg meeting: Diffserv - some thoughts 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, 13 Nov 2012 14:33:48 -0000 PiBJc24ndCB0aGVyZSBhIHByb2JsZW0gd2hlbiBtaXhpbmcgZWxlcGhhbnRzIGFuZCBtaWNlIGlu IHRoaXMgd2F5Pw0KPiBBbHRob3VnaCB0aGV5IG1pZ2h0IGhhdmUgY2xvc2VseSByZWxhdGVkIHJl cXVpcmVtZW50cyBmb3IgUW9TDQo+IG1ldHJpY3MsIHZpZGVvIGVsZXBoYW50cyBjYW4gdHJhbXBs ZSBvbiBhdWRpbyBtaWNlIHdoZW4gdGhleQ0KPiBzaGFyZSBhIHF1ZXVlLg0KDQpTdXJlLCBidXQg SSBiZWxpZXZlIHRoYXQncyBhIG5ldHdvcmsgb3BlcmF0b3IncyBkZWNpc2lvbiBvbiBob3cNCnRv IGRlcGxveSB0aGUgcG90ZW50aWFsbHkgbGltaXRlZCBudW1iZXIgb2YgcXVldWVzIGF2YWlsYWJs ZS4NCg0KVGhhbmtzLA0KLS1EYXZpZA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFp bC5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEzLCAyMDEyIDI6NTggQU0NCj4gVG86 IEJsYWNrLCBEYXZpZA0KPiBDYzogUnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlOyB0c3Z3Z0BpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSZTogW3RzdndnXSBUc3Z3ZyBtZWV0aW5nOiBEaWZmc2VydiAtIHNv bWUgdGhvdWdodHMNCj4gDQo+IE9uIDEyLzExLzIwMTIgMTg6NTksIEJsYWNrLCBEYXZpZCB3cm90 ZToNCj4gPj4gVGhhdCBtYXkgYmUgYSBzdHJlYW1pbmcgdmVyc3VzIGNvbmZlcmVuY2luZyBpc3N1 ZSAoZGlmZmVyZW50DQo+ID4+IGVudmlyb25tZW50cyBhbmQgYXVkaWVuY2UpIGFuZCBJJ20gb3Bl biBmb3IgZGlzY3Vzc2lvbi4NCj4gPg0KPiA+IEdvb2QgLSBldmVuIGlmL3doZW4gYXVkaW8gYW5k IHZpZGVvIGFyZSBpbiBkaWZmZXJlbnQgc2VydmljZQ0KPiA+IGNsYXNzZXMgaW4gUkZDIDQ1OTQs IHRoZXkgZG9uJ3QgaGF2ZSB0byBiZSBpbiBkaWZmZXJlbnQgcXVldWVzDQo+ID4gaW4gdGhlIGlt cGxlbWVudGF0aW9uLCBlLmcuLCBzZWUgUkZDIDUxMjcuDQo+IA0KPiBJc24ndCB0aGVyZSBhIHBy b2JsZW0gd2hlbiBtaXhpbmcgZWxlcGhhbnRzIGFuZCBtaWNlIGluIHRoaXMgd2F5Pw0KPiBBbHRo b3VnaCB0aGV5IG1pZ2h0IGhhdmUgY2xvc2VseSByZWxhdGVkIHJlcXVpcmVtZW50cyBmb3IgUW9T DQo+IG1ldHJpY3MsIHZpZGVvIGVsZXBoYW50cyBjYW4gdHJhbXBsZSBvbiBhdWRpbyBtaWNlIHdo ZW4gdGhleQ0KPiBzaGFyZSBhIHF1ZXVlLg0KPiANCj4gPj4gV2hhdCBJIHN1Z2dlc3QgaXMgdG8g Z2V0IG1vcmUgY2xhcml0eSBhYm91dCB3aGljaCBwcm9ibGVtIHdlDQo+ID4+IHRyeSB0byBzb2x2 ZSBieSBEaWZmU2VydiByZWdhcmRpbmcgYm90dGxlbmVja3MuIFNvcnJ5IGlmDQo+ID4+IHRoYXQg aXMgY2xlYXIgdG8gYWxsIGFuZCBJJ20gYSBiaXQgdGhpY2sgaGVyZS4NCj4gPg0KPiA+IFdlJ3Jl IG9uIHRoZSBzYW1lIHBhZ2UgaGVyZS4gIFRoZSBvbmx5IGluaXRpYWwgcmVzdWx0IG9mIHRoZQ0K PiA+IGRpc2N1c3Npb24gb2YgSmFtZXMnIGRyYWZ0IGxhc3Qgd2VlayBpcyB0aGF0IHdlIGRlZmlu aXRlbHkgaGF2ZQ0KPiA+IGEgcHJvYmxlbSB3aXRoIHRoZSBhYnNlbmNlIG9mIHRoZSBkaXN0aW5j dGlvbiBiZXR3ZWVuIGludGVyYWN0aXZlDQo+ID4gdnMuIG5vbi1pbnRlcmFjdGl2ZSBtZWRpYSB0 cmFmZmljLg0KPiANCj4gRXNwZWNpYWxseSBnaXZlbiB0aGF0IGludGVyYWN0aXZlIHRyYWZmaWMg aXMgb2Z0ZW4gZW5vdWdoIGhpZGRlbg0KPiBpbiBUQ1Agc3RyZWFtcyB0aGVzZSBkYXlzLiBUaGVy ZSdzIG5vIGVhc3kgd2F5IHRvIGNsYXNzaWZ5DQo+IHRoaXMgdHJhZmZpYyBleGNlcHQgYXQgdGhl IHNvdXJjZS4NCj4gDQo+ICAgIEJyaWFuDQo+IA0KPiA+IEkgaGF2ZSB0aGUgYWN0aW9uIGl0ZW1z IHRvDQo+ID4gZHJhZnQgY3Jpc3AgcXVlc3Rpb25zIHRvIHRoZSBsaXN0IGFib3V0IHRoZSBvdGhl ciB0aGluZ3MgdGhhdA0KPiA+IEphbWVzIHByb3Bvc2VzIGNoYW5naW5nIHNvIHRoYXQgd2UgY2Fu IGhhdmUgZm9jdXNlZCBkaXNjdXNzaW9ucw0KPiA+IGFyb3VuZCB3aGV0aGVyIHRvIGNoYW5nZSB0 aGVtLg0KPiA+DQo+ID4NCj4gPg0KPiA+IFRoYW5rcywNCj4gPiAtLURhdmlkDQo+ID4NCj4gPg0K PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBSdWVkaWdlci5HZWli QHRlbGVrb20uZGUgW21haWx0bzpSdWVkaWdlci5HZWliQHRlbGVrb20uZGVdDQo+ID4+IFNlbnQ6 IE1vbmRheSwgTm92ZW1iZXIgMTIsIDIwMTIgMzozMyBBTQ0KPiA+PiBUbzogQmxhY2ssIERhdmlk OyBqbXBvbGtAY2lzY28uY29tDQo+ID4+IENjOiB0c3Z3Z0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0 OiBSRTogVHN2d2cgbWVldGluZzogRGlmZnNlcnYgLSBzb21lIHRob3VnaHRzDQo+ID4+DQo+ID4+ IERhdmlkLCBKYW1lcywNCj4gPj4NCj4gPj4gZ290IHRoZSBwb2ludCByZWxhdGVkIHRvIGludGVy Y29ubmVjdGlvbiBhbmQgbm8sIEkgZG8gbm90IGp1c3QNCj4gPj4gbG9vayBhdCBEaWZmU2VydiBm cm9tIGEgQmFja2JvbmUgcGVyc3BlY3RpdmUuIFRoZSBjb21wYW55IEkgd29yaw0KPiA+PiBmb3Ig cnVucyBzb21lIG1pbGxpb24gRFNMIGFjY2Vzc2VzIGFuZCBpZiBhbnkgb2YgeW91IGJvdGhlcnMs DQo+ID4+IHlvdSdsbCBmaW5kIGF0IGxlYXN0IG9uZSBTSVAgcmVsYXRlZCBRb1MgcHVibGljYXRp b24gSSB3cm90ZS4NCj4gPj4NCj4gPj4gVGhlIHJlYXNvbiBmb3IgbXkgbGFzdCBtYWlsIHdhcyB0 aGF0IEphbWVzIGdvZXMgZm9yIHRyZWF0aW5nIHZpZGVvDQo+ID4+IGNvbmZlcmVuY2UgYXVkaW8g ZGlmZmVyZW50IHRoYW4gdGhlIHBpY3R1cmVzLiBUaGF0J3MgcHJvYmFibHkNCj4gPj4gYmFzZWQg b24gY3VzdG9tZXIgZmVlZGJhY2suIFdoYXQgdGhhdCBpbXBsaWVzIGlzLCB0aGVyZSBoYXMNCj4g Pj4gYmVlbiBhIHBhY2tldCBkcm9wcGluZyBib3R0bGVuZWNrLiBBbmQgYXQgbGVhc3Qgb25lIG9w dGlvbiBvZg0KPiA+PiBhcHBsaWNhdGlvbiBiYXNlZCBjbGFzcyBkZXNpZ24gc2hvdWxkIGFzc3Vt ZSBpdHMgcHJlc2VuY2UuDQo+ID4+DQo+ID4+IFRoZSBhdWRpby92aWRlbyBleHBlcnRzIG9mIG15 IGNvbXBhbnkgKG9uIG9mIHRoZW0gQWxleGFuZGVyIFJhYWtlLA0KPiA+PiBodHRwOi8vZW4ud2lr aXBlZGlhLm9yZy93aWtpL0FsZXhhbmRlcl9SYWFrZSkNCj4gPj4gcmVjb21tZW5kIGZvcndhcmRp bmcgYXVkaW8gYW5kIHZpZGVvIGZyYW1lcyBpbiB0aGUgc2FtZSBxdWV1ZS4NCj4gPj4gSGlzIGVm Zm9ydHMgb24gb2JqZWN0aXZlIHZpZGVvIHF1YWxpdHkgbW9kZWxzIHNob3csDQo+ID4+IHRoYXQg dmlld2VycyByZWdhcmQgYSBsb3NzIG9mIGxpcC1zeW5jaCBhcyBxdWFsaXR5IGRlZ3JhZGF0aW9u Lg0KPiA+PiBJJ2xsIHByb2JhYmx5IHNlZSBoaW0gdGhpcyB3ZWVrIGFuZCBhc2sgaG9tIGZvciBo aXMgdmlldy4NCj4gPj4NCj4gPj4gVGhhdCBtYXkgYmUgYSBzdHJlYW1pbmcgdmVyc3VzIGNvbmZl cmVuY2luZyBpc3N1ZSAoZGlmZmVyZW50DQo+ID4+IGVudmlyb25tZW50cyBhbmQgYXVkaWVuY2Up IGFuZCBJJ20gb3BlbiBmb3IgZGlzY3Vzc2lvbi4NCj4gPj4NCj4gPj4gV2hhdCBJIHN1Z2dlc3Qg aXMgdG8gZ2V0IG1vcmUgY2xhcml0eSBhYm91dCB3aGljaCBwcm9ibGVtIHdlDQo+ID4+IHRyeSB0 byBzb2x2ZSBieSBEaWZmU2VydiByZWdhcmRpbmcgYm90dGxlbmVja3MuIFNvcnJ5IGlmDQo+ID4+ IHRoYXQgaXMgY2xlYXIgdG8gYWxsIGFuZCBJJ20gYSBiaXQgdGhpY2sgaGVyZS4NCj4gPj4NCj4g Pj4gUmVnYXJkcywgUsO8ZGlnZXINCj4gPj4NCj4gPj4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPj4gRnJvbTogQmxhY2ssIERhdmlkIFttYWlsdG86ZGF2aWQuYmxhY2tAZW1j LmNvbV0NCj4gPj4gU2VudDogRnJpZGF5LCBOb3ZlbWJlciAwOSwgMjAxMiA1OjA4IFBNDQo+ID4+ IFRvOiBHZWliLCBSw7xkaWdlcg0KPiA+PiBDYzogdHN2d2dAaWV0Zi5vcmcNCj4gPj4gU3ViamVj dDogUkU6IFRzdndnIG1lZXRpbmc6IERpZmZzZXJ2IC0gc29tZSB0aG91Z2h0cw0KPiA+Pg0KPiA+ PiBSw7xkaWdlciwNCj4gPj4NCj4gPj4gPG5ld2x5LWFjcXVpcmVkIHRzdndnIGNvLWNoYWlyIGhh dCBvZmY+DQo+ID4+DQo+ID4+IFdoaWxlIERpZmZzZXJ2IHdhcyBzaWduaWZpY2FudGx5IG1vdGl2 YXRlZCBieSBzZXJ2aWNlIHByb3ZpZGVyIGNvcmUNCj4gPj4gYW5kIGJhY2tib25lIG5ldHdvcmtz LCB0aGUgYXBwbGljYWJpbGl0eSBvZiBEaWZmc2VydiBoYXMgbmV2ZXIgYmVlbg0KPiA+PiBsaW1p dGVkIHRvIHRoYXQgY2xhc3Mgb2YgbmV0d29ya3MuICBGb3IgZXhhbXBsZSwgc2VlIHNsaWRlIDIg aW4gdGhlDQo+ID4+IHNsaWRlIGRlY2sgdGhhdCBKYW1lcyB1c2VkIHllc3RlcmRheToNCj4gPj4N Cj4gPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84NS9zbGlkZXMvc2xpZGVzLTg1 LXRzdndnLTEzLnBwdHgNCj4gPj4NCj4gPj4gVGhlcmUgYXJlIGFsbW9zdCBjZXJ0YWlubHkgb3Bw b3J0dW5pdGllcyB0byBkaWZmZXJlbnRpYXRlIHRyZWF0bWVudA0KPiA+PiBvZiBpbnRlcmFjdGl2 ZSBtZWRpYSB0cmFmZmljICh0aGF0IG5lZWRzIGEgbG93IGppdHRlciBidWRnZXQpIGZyb20NCj4g Pj4gbm9uLWludGVyYWN0aXZlIG1lZGlhIHRyYWZmaWMgc2VsZWN0aXZlbHkgbmVhciBrbm93bi9l eHBlY3RlZA0KPiA+PiBib3R0bGVuZWNrcyBldmVuIGlmIHRoZXJlIG1heSBub3QgYmUgYSByYXRp b25hbGUgZm9yIGRvaW5nIHRoYXQNCj4gPj4gZGlmZmVyZW50aWF0aW9uIGdsb2JhbGx5Lg0KPiA+ Pg0KPiA+PiBUaGUgc2Vuc2Ugb2YgdGhlIHJvb20gaW4geWVzdGVyZGF5J3MgdHN2d2cgbWVldGlu ZyAod2lsbCBuZWVkIHRvIGJlDQo+ID4+IGNvbmZpcm1lZCBvbiB0aGlzIGxpc3QsIHNlcGFyYXRl IG1lc3NhZ2UgY29taW5nIHNvb24pIHdhcyB0aGF0IHRoZQ0KPiA+PiBJRVRGIHNob3VsZCB3b3Jr IG9uIHRoZSBkaWZmc2VydiBpbnRlcmNvbm5lY3QgcHJvYmxlbSByZXByZXNlbnRlZA0KPiA+PiBp biB0aGUgSVRVLVQgU0cxMiBsaWFpc29uIGFuZCB5b3VyIGRyYWZ0LiAgSU1ITywgdGhhdCB3b3Jr IGlzIGxpa2VseQ0KPiA+PiB0byByZXN1bHQgaW4gYSBzbWFsbCBudW1iZXIgb2YgaW50ZXJjb25u ZWN0IHRyYWZmaWMgY2xhc3NlcyB0aGF0IG1heQ0KPiA+PiBvciBtYXkgbm90IHJlc2VtYmxlIHRo ZSB0cmVhdG1lbnQgYWdncmVnYXRlcyBpbiBSRkMgNTEyNy4gIFRoZXJlIHdpbGwNCj4gPj4gYmUg bm90aGluZyB0byBzdG9wIGEgbmV0d29yayBmcm9tIGNob29zaW5nIHRvIGRlcGxveSBqdXN0IHRo b3NlDQo+ID4+IGludGVyY29ubmVjdCBjbGFzc2VzIGludGVybmFsbHkgaW4gYWRkaXRpb24gdG8g dXNpbmcgdGhlbSBmb3INCj4gPj4gaW50ZXJjb25uZWN0aW9uLiAgQSBuZXR3b3JrIGNvdWxkIGFs c28gaW50ZXJuYWxseSBkZXBsb3kgYSBzdWJzZXQNCj4gPj4gb2YgdGhlIFJGQyA0NTk0IChvciBz dWNjZXNzb3IpIHRyYWZmaWMgY2xhc3Nlcywgb3IgZXZlbiBqdXN0IHNvbWUNCj4gPj4gb3IgYWxs IG9mIHRoZSBmb3VyIHRyZWF0bWVudCBhZ2dyZWdhdGVzIGluIFJGQyA1MTI3IChvciBzdWNjZXNz b3IpLg0KPiA+Pg0KPiA+PiBJbiBwYXJ0aWN1bGFyLCB0aGVyZSBpcyBubyBjdXJyZW50IG9yIGlu dGVuZGVkIHJlcXVpcmVtZW50IHRoYXQgYW55DQo+ID4+IG5ldHdvcmsgZGVwbG95IGFsbCBvZiB0 aGUgZGlmZnNlcnYgc2VydmljZSBjbGFzc2VzIGluIFJGQyA0NTk0IG9yIGFueQ0KPiA+PiBzdWNj ZXNzb3IuICBJIGFsc28gd2FudCB0byBiZSBjbGVhciB0aGF0IEkgYW0gbm90IGFzc3VtaW5nIHRo YXQgdGhlDQo+ID4+IGludGVyY29ubmVjdCB0cmFmZmljIGNsYXNzZXMgd2lsbCBiZSBiYXNlZCBv biBhbiB1cGRhdGUgdG8gUkZDDQo+ID4+IDUxMjcsIGFzIHRoZXkgYWRkcmVzcyBkaWZmZXJlbnQg cHJvYmxlbXMgLSB0aGUgYXBwcm9hY2ggaGVyZSBpcw0KPiA+PiBUQkQgYnkgdGhlIFdHLg0KPiA+ Pg0KPiA+PiBUaGFua3MsDQo+ID4+IC0tRGF2aWQNCj4gPj4NCj4gPj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4+PiBGcm9tOiBSdWVkaWdlci5HZWliQHRlbGVrb20uZGUgW21haWx0 bzpSdWVkaWdlci5HZWliQHRlbGVrb20uZGVdDQo+ID4+PiBTZW50OiBGcmlkYXksIE5vdmVtYmVy IDA5LCAyMDEyIDQ6MDEgQU0NCj4gPj4+IFRvOiBCbGFjaywgRGF2aWQNCj4gPj4+IENjOiB0c3Z3 Z0BpZXRmLm9yZw0KPiA+Pj4gU3ViamVjdDogVHN2d2cgbWVldGluZzogRGlmZnNlcnYgLSBzb21l IHRob3VnaHRzDQo+ID4+Pg0KPiA+Pj4gRGF2aWQsDQo+ID4+Pg0KPiA+Pj4gSSdtIG5vdCBmdWxs eSBjbGVhciBhYm91dCB3aGljaCBwcm9ibGVtIHdlIChzaG91bGQpIHRyeSB0byBzb2x2ZSBvbg0K PiBEaWZmU2Vydg0KPiA+Pj4gaW4gdHN2d2c6DQo+ID4+Pg0KPiA+Pj4gLSB0aGUgYmFja2JvbmUg b3IgU1AgbmV0d29ya3MgZG9uJ3Qgc2VlbSB0byBiZSBhIFFvUyBpc3N1ZS4gQSBmZXcgY2xhc3Nl cw0KPiA+Pj4gICAgICAgcHJvYmFibHkgd2lsbCBiZSBzdWZmaWNpZW50Lg0KPiA+Pj4gLSB0c3Z3 ZyBpc24ndCBjaGFydGVyZWQgdG8gc29sdmUgYXBwbGljYXRpb24gcHJvYmxlbXMgKGxpa2Ugd2ly ZWxlc3MNCj4gYWNjZXNzLA0KPiA+Pj4gICAgICAgcnRwIHBhY2tldHMgb25seSBhbGwgeCBtaWxs aXNlY29uZHMgYW5kIHNvIG9uLg0KPiA+Pj4gLSBpZiBhIGJvdHRsZW5lY2sgaXMgb3ZlcmJvb2tl ZCwgRGlmZlNlcnYgY2FuIGRpc3RyaWJ1dGUgY2FwYWNpdHksIGJ1dCBub3QNCj4gPj4+ICAgICAg IGNyZWF0ZSBhZGRpdGlvbmFsIG9uZS4NCj4gPj4+DQo+ID4+PiBUaGVuIHNvbWUgdGhvdWdodHMg b24gc3RyZWFtaW5nIGFuZCB0ZWxlY29uZmVyZW5jaW5nDQo+ID4+PiAtIHN0cmVhbWluZyBpcyBk ZWxheSB0b2xlcmFudC4gV2hlcmUgd291bGQgb25lIGxvY2F0ZSB0aGUgbGFyZ2UgYnVmZmVyPyBP bg0KPiBhDQo+ID4+PiAgICAgICAxMCBHRSBpbnRlcmZhY2U/IE9uIGEgYm90dGxlbmVjayBpbnRl cmZhY2U/IFZlcnkgY2xvc2UgdG8gdGhlDQo+ID4+IGFwcGxpY2F0aW9uPw0KPiA+Pj4gLSBzdHJl YW1pbmcgZG9lcyBub3QgcmVkdWNlIHRyYWZmaWMgZHVyaW5nIGNvbmdlc3Rpb24gKG11bHRpY2Fz dCBjYW4ndCkuDQo+ID4+PiAgICAgICBXaGF0J3MgdGhlIGVmZmVjdCBvZiBhc3NpZ25pbmcgYSBk ZWVwIGJ1ZmZlciBmb3IgaXQgYXQgYmFja2JvbmUNCj4gPj4gaW50ZXJmYWNlcywNCj4gPj4+ICAg ICAgIGlmIHRoZXJlJ3MgY29uZ2VzdGlvbj8NCj4gPj4+IC0gd2hhdCdzIGEgZ29vZCBhcmd1bWVu dCBub3QgdG8gcHJvZHVjZSBib3RoIGFjcm9zcyB0aGUgc2FtZSBxdWV1ZS9jbGFzcz8NCj4gPj4+ DQo+ID4+PiBJbiBzdW06IHdoYXQgZG9lcyBhIERTIFJGQyByZWFkZXIgbGVhcm4gZnJvbSBhIGNs YXNzIGRlc2NyaXB0aW9uIGluIHRlcm1zDQo+ID4+IGxvc3MgdG9sZXJhbmNlIHllcy9ubywNCj4g Pj4+IGRlbGF5IHRvbGVyYW5jZSB5ZXMvbm8gYW5kIHNvIG9uPyBNeSB0YWtlOiB3aXRob3V0IHVu ZGVyc3RhbmRpbmcgdGhlDQo+IHByZXNlbnQNCj4gPj4gb3IgcmVxdWlyZWQgdHJhbnNwb3J0DQo+ ID4+PiBwcm9wZXJ0aWVzIG9mIGFuIGFwcGxpY2F0aW9uLCBhIHB1cmVseSBhcHBsaWNhdGlvbiBi YXNlZCBwZXJmb3JtYW5jZQ0KPiA+PiByZXF1aXJlbWVudCBkZXNjcmlwdGlvbiBjYW4NCj4gPj4+ IGJlIG1pc2xlYWRpbmcuDQo+ID4+Pg0KPiA+Pj4gSWYgd2UgY29uY2x1ZGUgdGhhdCBtYW55IGNs YXNzZXMgYXJlIHJlcXVpcmVkIHRvIGRlYWwgd2l0aCBib3R0bGVuZWNrDQo+ID4+IGJlaGF2aW91 ciBhbmQgd2UgZXhwZWN0DQo+ID4+PiB0aGlzIGJvdHRsZW5lY2sgdG8gYmUgcHJlc2VudCAoYW5k IERpZmZTZXJ2IHQga2ljayBpbiksIHRoZW4gd2hhdCBkbyB3ZQ0KPiA+PiBuZWVkOg0KPiA+Pj4g LSBtYW55IGNsYXNzZXMsIGVhY2ggb2Ygd2hpY2ggaGFzIHRvIGJlIGVuZ2luZWVyZWQgYnkgbm9u LVFvUy1leHBlcnRzDQo+IGJhc2VkDQo+ID4+IG9uIGEgY29uZmlndXJhdGlvbg0KPiA+Pj4gICBn dWlkYW5jZSBnaXZlbiBieSA0NTk0PyBUaGF0IHdvdWxkIGJlIHByZWNvbmZpZ3VyZWQsIEkgZ3Vl c3MgYW5kIGV2ZXJ5DQo+ID4+IGltcGxlbWVudG9yIHdpbGwNCj4gPj4+ICAgYXBwbHkgcGhhbnRh c3kuIElmIGxpa2UgMTAgUEhCcyBhcmUgaW1wbGVtZW50ZWQsIHdoaWNoIGdldHMgd2hhdCBzaGFy ZQ0KPiBvZg0KPiA+PiB0aGUgYm90dGxlbmVjaw0KPiA+Pj4gICBiYW5kd2lkdGg/IEhvdyBkbyB0 aGV5IGNvbXBldGUgZm9yIHNwYXJlIGNhcGFjaXR5PyBIb3cgaXMgdHJhZmZpYw0KPiA+PiBhZG1p dHRlZD8NCj4gPj4+IC0gb3IgZG8gd2UgdHJ5IHRvIHNvbHZlIGFuIGFkbWlzc2lvbiBjb250cm9s IChvciB0cmFmZmljIGVuZ2luZWVyaW5nKQ0KPiA+PiBwcm9ibGVtIGJ5IGNyZWF0aW5nIGV2ZXIN Cj4gPj4+ICAgbmV3IGNsYXNzIGRlZmludGlvbnMuDQo+ID4+Pg0KPiA+Pj4gTWF5YmUgaXQncyB3 b3J0aCB0byB0aGluayBhYm91dCBhIHByb2JsZW0gc3RhdGVtZW50IHRvIGdldCBhIGNsZWFyDQo+ ID4+IGRlc2NyaXB0aW9uIG9mIHRoZSBpc3N1ZXMsDQo+ID4+PiB3ZSB3YW50IHRvIGRlYWwgd2l0 aC4gRGlmZlNlcnYgY3JlYXRlZCBhIHNldCBvZiB0b29scywgYXBwbGljYWJsZSBmb3INCj4gPj4g cm91dGVycyBvciBuZXR3b3Jrcw0KPiA+Pj4gbGFyZ2VseS4gSXQgc2VlbXMgdG8gbWUsIHRoYXQg bm93IHRoZSBjb21tdW5pdHkgc3RhcnRzIHRvIGxvb2sgYXQgUW9TIG1vcmUNCj4gPj4gZnJvbSBh biBlbmQgdG8NCj4gPj4+IGVuZCBwZXJzcGVjdGl2ZSwgYnV0IHRyaWVzIHRvIHNvbHZlIGlzc3Vl cyB3aXRoIHJvdXRlciBtZWNoYW5pc21zLiBUaGF0J3MNCj4gPj4gbm90IHdoYXQgRGlmZlNlcnYN Cj4gPj4+IGlzIGRlc2lnbmVkIGZvci4NCj4gPj4+DQo+ID4+PiBSZWdhcmRzLA0KPiA+Pj4NCj4g Pj4+IFLDvGRpZ2VyDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ ID4NCj4gPg0KPiANCg0K From Martin.Stiemerling@neclab.eu Wed Nov 14 02:49:37 2012 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 7D58621F854C for ; Wed, 14 Nov 2012 02:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.559 X-Spam-Level: X-Spam-Status: No, score=-103.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwmE7806PMus for ; Wed, 14 Nov 2012 02:49:37 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id F171021F853B for ; Wed, 14 Nov 2012 02:49:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 6163B10255E for ; Wed, 14 Nov 2012 11:49:36 +0100 (CET) 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 vYTE4+SODZQw for ; Wed, 14 Nov 2012 11:49:36 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 49AA610255D for ; Wed, 14 Nov 2012 11:49:31 +0100 (CET) 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; Wed, 14 Nov 2012 11:49:02 +0100 Message-ID: <50A36704.2060404@neclab.eu> Date: Wed, 14 Nov 2012 10:40:20 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] Subject: [tsvwg] New co-chair as replacement for Rolf: David Black 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, 14 Nov 2012 10:49:37 -0000 Hi all, Rolf Winter has to step down as TSVWG co-chair for personal reasons and he will be replaced by David Black. Thank you Rolf for serving as TSVWG co-chair! And welcome David as new co-chair! Best regards, Martin -- IETF Transport Area Director martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From bob.briscoe@bt.com Thu Nov 15 05:07:44 2012 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 6F2B721F8809 for ; Thu, 15 Nov 2012 05:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.994 X-Spam-Level: X-Spam-Status: No, score=-2.994 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hE8da2cVYjtR for ; Thu, 15 Nov 2012 05:07:42 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 20F3121F858E for ; Thu, 15 Nov 2012 05:07:40 -0800 (PST) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 15 Nov 2012 13:07:39 +0000 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 15 Nov 2012 13:07:38 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.309.2; Thu, 15 Nov 2012 13:07:33 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1352984850566; Thu, 15 Nov 2012 13:07:30 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.9.241]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qAFD7RA0009392; Thu, 15 Nov 2012 13:07:27 GMT Message-ID: <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 15 Nov 2012 13:07:31 +0000 To: , From: Bob Briscoe In-Reply-To: References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_662145354==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: tsvwg@ietf.org, philip.eardley@bt.com, anuragb@cisco.com, rsvp-dir@ietfa.amsl.com, PCN IETF list Subject: [tsvwg] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-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: Thu, 15 Nov 2012 13:07:44 -0000 --=====================_662145354==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Georgios, Anurag, Below is the main point of my review, arguing that aggregate reservations are redundant. I'm reviewing as: - a member of the RSVP directorate - one of the early PCN design team - a co-author of draft-lefaucheur-rsvp-ecn-01, on which this draft is based. I would have missed any decision to use aggregate reservations. Pls point me to the relevant discussion (e.g. Subject line / date). I admit I tuned out of much of the later PCN signalling discussion. I found the whole exercise of abstracting PCN away from specific signalling protocols highly tedious; it meant we couldn't sensibly address important issues like message reliability, timeliness etc. Nonetheless, here's why I believe RSVP aggregation is redundant: PCN edge-nodes support the concept of an ingress-egress aggregate in their own internal tables, but they don't need to refer to an aggregate on the wire{Note 1}. PCN-ingress and PCN-egress nodes intrinscially know which e2e reservations belong to which aggregate by grouping together those e2e reservations with the same next hop or previous hop respectively. {Note 1: except in one case described later - but it doesn't require all the other baggage of aggregate reservations} ==Background== Aggregate reservations [RFC3175, RFC4860] are designed to reduce the state required on interior nodes. Interior nodes still require state per aggregate reservation, but only reservation state, not classification and scheduling state [RFC3175, Section 1.4.1 last para]. In contrast, as you correctly point out (in Section 2.1.7), PCN requires absolutely no reservation-related state on interior nodes. ==Disadvantages== Requiring PCN to use aggregate reservations has the following three disadvantages and no advantages: 1) Redundant Processing The PATH message between aggregator and deaggregator in rsvp-pcn-03 (triggered by an E2E PathErr message from deaggregator to aggregator) is redundant, and just doubles the processing required at the PCN-edge-nodes (if this isn't obvious, I spell it out separately for PATH & RESV messages below). 2) Reduced Resilience Not only is an aggregate PATH redundant, it actually reduces resilience. Because an aggregate PATH is pinned to interior routers. Therefore, when routing changes, it is more complex and slower to move to the new route. By not pinning to interior routers, PCN was designed to 'just work' over interior routing changes - with no need for any changes to the RSVP PATHs. (But it would still detect overload after a re-route and terminate or rate-reduce flows if necessary.) 3) Extra Latency A further disadvantage is the extra latency required for the first reservation that sets up an aggregate. This is two ingress-egress round trips minus the round trip time from egress to destination (or one ingress-egress round trip if it is greater). This will rarely add to latency on heavily used ingress-egress aggregates, but it will occur frequently on all the 'long-tail' (lightly used) ingress-egress aggregates. ==PATH== With RFC 3175 or 4860 aggregate paths, the aggregator forwards the e2e PATH messages with IP protocol number RSVP-E2E-IGNORE and the deaggregator changes them back to RSVP before forwarding onward. Also the aggregator sends an aggregate PATH message, which is processed by each interior node and by the deaggregator. On a path across a PCN region, given interior nodes ignore aggregate PATH messages as well, the only PCN nodes that handle aggregate messages are the aggregator and the deaggregator. The aggregator and deaggregator process all the e2e PATH messages anyway, so if we require the aggregator to add up all the e2e PATH messages and form them into an aggregate PATH message, this is just extra redundant work for both PCN-edge-nodes. ==RESV== The deaggregator unicasts e2e RESV messages to the previous RSVP hop, which is the aggregator. Therefore, if we require the deaggregator to add up all the RESV messages and form them into an aggregate RESV message, this is just redundant work for both PCN-edge-nodes, because they both already process all the e2e RESV messages anyway, and no other node uses the aggregate RESV messages. ==PCN object== This raises the question of how the PCN-egress communicates the various marking rates (the PCN object) to the PCN-ingress. There are two possibilities: i) the PCN-egress includes a current PCN object in each e2e RESV that it returns to the PCN-ingress. The PCN-ingress strips the PCN object out before forwarding the RESV back to the previous RSVP hop. ii) the PCN-egress attaches a PCN object to an aggregate reservation, as in pcn-rsvp-03. Either are possible, because a PCN object carries information about marking probabilities, and PCN works on the assumption that the marking probability of an ingress-egress aggregate is the same as the marking probability of the flows within the aggregate. A PCN object can be contained either in an e2e RESV or an aggregate RESV as long as the PCN-ingress can associate an e2e RESV with the correct aggregate (which it can, because it maintains an internal table of mappings between e2e reservations and their aggregates). Which of the two is best is a question of message timing... * For e2e admission decisions, the PCN object is only needed at the time each e2e RESV is sent, so option i) makes sense. * For flow rate reduction or flow termination decisions, the deaggregator needs to regularly send PCN objects to the ingress. The PCN-egress is sending regular e2e RESV refresh messages to the PCN-ingress, so a PCN object can be included in each of these. To ensure that PCN objects are sent often enough, I suggest the PCN-egress also maintains a timer per ingress-egress aggregate which it resets every time it sends a PCN object for that IEA. If the timer expires, the PCN-egress sends a PCN object to the PCN-egress even thought it was not triggered by an e2e RESV refresh. We could require the SESSION object in this message to refer to either of: a) any one of the e2e SESSIONs in the aggregate, b) the aggregate. In case (a), the message would need to somehow tell the ingress not to forward this RESV refresh to the RSVP previous hop. In case (b) in the PCN-ingress table of mappings between e2e SESSIONs and aggregate SESSIONs, it would include an entry for the aggregate that maps to itself. If the result of the look-up is the same as the input, it knows not to forward the RESV refresh further. The wire protocol doesn't need to identify whether the SESSION is an aggregate or not. This is the one case I mentioned at the start {Note 1} where an aggregate is referred to on the wire. In summary, PCN already reduces reservation state and processing to nothing on interior nodes. Adding aggregate reservations to PCN requires more processing and state, it unnecessarily pins routes to interior nodes and adds unnecessary latency. Bob At 18:23 14/11/2012, karagian@cs.utwente.nl wrote: >Hi Bob, > >Regarding the generic aggregated RSVP selection, actually the PCN WG >agreed with this selection! >This was actually the first step that was needed for this work, and >the PCN WG had no main objections on this selection! > >So I do not understand your remark that your comment will have major >implications! > >Please note that the generic aggregated RSVP is selected since the >PCN IEA are associated with flows that are aggregated at the edges. >So a signalling protocol that supports aggregation of flows at the >edges is very suitable for this purpose! The generic aggregated RSVP >is such a signalling protocol! > > >Best regards, >Georgios > > > > >From: Bob Briscoe [mailto:bob.briscoe@bt.com] >Sent: woensdag 14 november 2012 12:57 >To: Anurag Bhargava (anuragb) >Cc: Karagiannis, G. (EWI) >Subject: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 > >Anurag, > >I have my comments half-written up. I will try to finish them by the >end of today. > >They should be orthogonal to the PBAC comment below, so if you >wanted to start altering that area, I don't think it would waste too >much time. > >However, my main comments will concern the use of aggregated >reservations (as I said at the mic), so that could have major implications. > > >Bob > >At 20:14 13/11/2012, Anurag Bhargava (anuragb) wrote: > >Hi Bob, > Thanks for the comments. If U have some text that will be great > els I have also started putting some text on the topic U brought up. > May be we can conference after US thanksgiving week and > collaborate the text and try to move forward. > > Please let us know what might be a good time and I can schedule a > Webex conf. > >Thx >-Anurag > >From: "karagian@cs.utwente.nl " ><karagian@cs.utwente.nl > >Date: Saturday, November 10, 2012 8:10 AM >To: "bob.briscoe@bt.com" ><bob.briscoe@bt.com> >Cc: "carlberg@g11.org.uk" ><carlberg@g11.org.uk>, Anurag Bhargava ><anuragb@cisco.com>, >"tsvwg@ietf.org" ><tsvwg@ietf.org>, >"philip.eardley@bt.com " ><philip.eardley@bt.com > >Subject: RE: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 > >Hi Bob, > > > >Thanks very much for the comments! I think that they are very useful! > > > >It will be very beneficiary for the fast progress of this draft if >you would like to contribute as a co-author to this draft and write >this additional section that describes "that the PCN-ingress can >refer flow admission and >termination decisions to a central decision point (using e.g. COPS), >which will respond to the PCN-ingress as per RFC2753. (Alternatively >the PCN-ingress could itself be the policy decision point.)" > > > >Best regards, > >Georgios > > > >---------- >Van: Bob Briscoe [bob.briscoe@bt.com] >Verzonden: vrijdag 9 november 2012 16:33 >To: Karagiannis, G. (EWI) >Cc: carlberg@g11.org.uk; >anuragb@cisco.com; >tsvwg@ietf.org; EARDLEY, Phil >Onderwerp: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 > >Georgios, > >I shall post my full review of this draft in the next few days (needs >typing up - currently scribbled on a paper copy). This email is >solely in response to your answer about on-path vs off-path policy. > >At 18:55 04/11/2012, >karagian@cs.utwente.nl wrote: > >So in this case an additional signaling protocol will be > >needed to be specified that covers the signaling between the > >PCN-egress-node and the centralized node > >and between PCN-ingress-node and the centralized node. > >In PCN we decdided to only focus on the specification of the > >signaling protocol that completes the > >feedback loop from PCN-egress-node to PCN-ingress-node and to focus > >on the signaling protocol > >used between the edge nodes and the centralized node. > >When I/we originally designed CL-PCN over RSVP (2005), the idea was >that it would fit with the policy-based admission control (PBAC) >architecture of RFC2753. In this architecture, an Intserv node at the >ingress to a domain is the policy enforcement point (PEP), and it >refers to a logically centralised 'policy decision point' (PDP) for >decisions on which flows to block/terminate, typically using COPS. > >To make this doc fit the PBAC framework, all we have to do is: >* Describe the PCN-ingress only as the PCN-ingress and not as the >decision point (find 'decision' throughout doc and fix). >* Add a section saying the PCN-ingress can refer flow admission and >termination decisions to a central decision point (using e.g. COPS), >which will respond to the PCN-ingress as per RFC2753. (Alternatively >the PCN-ingress could itself be the policy decision point.) >* Refer to this new PBAC section from Section 3.11 giving the >admission decision procedure. > >* Some people might think this means COPS will need new protocol >elements to carry PCN marking rates to the policy decision point. But >PCN marking rates are irrelevant to the policy decision: the >PCN-ingress just uses PCN to determine whether it needs to block or >terminate, and it refers to the policy decision point for which flows >to block/terminate. > >* Unfortunately, neither of the two PCN system descriptions [RFC6661, >RFC6662] describe a PBAC-based case. The architecture [RFC5559] >refers to the PBAC framework [RFC2753] but unfortunately doesn't >spell out how it fits. Originally, I referenced PBAC from RFC5559, >but just as the PCN w-g was closing I realised that (some?) others in >the PCN w-g were working under the assumption that the only way to >talk to a centralised policy node was from the egress, possibly >without being aware of the contents of RFC2753. > >I think it's OK to introduce a new architectural arrangement in this >RSVP doc, given RFC2753 is specific to the way RSVP works. > > >Bob > > > >At 12:28 05/11/2012, >karagian@cs.utwente.nl wrote: > >Hi Ken, > > > >Thank you very much! > >We will try to catch Francois and discuss the last (in line) issue with him! > > > >Best regards, > >Georgios > > > >________________________________________ > >Van: ken carlberg [carlberg@g11.org.uk] > >Verzonden: maandag 5 november 2012 13:23 > >To: Karagiannis, G. (EWI) > >Cc: tsvwg@ietf.org; > anuragb@cisco.com > >Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03 > > > >Georgios, > > > > > Georgios: We will try to explain the rationale of why we consider > > that RSVP can only be used for the situation that the > > > decision point is collocated with the PCN-ingress-node. The main > > reason of this is that in the case that the > > > decision point is collocated with the PCN-ingress-node,the > > required signaling protocol used to complete a > > > feedback loop from egress to ingress can be an entirely on-path > > protocol, like what RSVP is. > > > In the situation that the the decision point is a centralized > > node, then the required signaling protocol > > > can be a combination of an on-path and off-path protocol. This is > > because the > > > decision point might not be located on the data path! So in this > > case an additional signaling protocol will be > > > needed to be specified that covers the signaling between the > > PCN-egress-node and the centralized node > > > and between PCN-ingress-node and the centralized node. > > > In PCN we decdided to only focus on the specification of the > > signaling protocol that completes the > > > feedback loop from PCN-egress-node to PCN-ingress-node and to > > focus on the signaling protocol > > > used between the edge nodes and the centralized node. > > > This is also the reason of why PCN WG decided to only focus on > > the situation that the decision point is > > > collocated with the PCN-ingress-node. > > > >Great, this is helpful, and this is the information that needs to be > >in the draft. > > > > >> 6) This comment is just for you to contemplate -- I'm not > > expecting any changes. > > >> I noticed that you have a fair number of SHOULD, and some SHOULD NOTs. > > >> And it seems a lot of this is a carry over from rfc-4860, so in > > a sense you are inheriting an approach that > > >> was agreed to from an earlier effort. But I wonder in the back > > of my mind, what impact occurs if > > >> an implementor doesn't follow the SHOULD? Does the design break > > in supporting PCN? > > >> Again, I want to stress that this isnt a show stopper, but I > > would appreciate it if you gave it some thought. > > > > > > Georgios: Yes, in several cases the design might break in supporting PCN. > > > This is also the reason of using SHOULD instead of MAY. Do you > > want us to explain this in more detail in the draft? > > > >well, actually, I was more curious as to why a number of these cases > >are SHOULD instead of MUST. Again, the SHOULD's in your document > >seem to be a carry-over from rfc-4860 (which set the precedent), so > >its a bit unfair for you to explain what was done in an earlier > >effort. I just wanted to make sure you gave some thought to the > >subject. And if things will break if SHOULD is not followed by an > >implementer/configuration, then maybe you should be more stringent > >and change things to MUST. Perhaps a brief private conversation > >with Francois Le Faucheur will be helpful. > > > >cheers, > > > >-ken > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_662145354==.ALT Content-Type: text/html; charset="us-ascii" Georgios, Anurag,

Below is the main point of my review, arguing that aggregate reservations are redundant. I'm reviewing as:
- a member of the RSVP directorate
- one of the early PCN design team
- a co-author of draft-lefaucheur-rsvp-ecn-01, on which this draft is based.

I would have missed any decision to use aggregate reservations. Pls point me to the relevant discussion (e.g. Subject line / date).

I admit I tuned out of much of the later PCN signalling discussion. I found the whole exercise of abstracting PCN away from specific signalling protocols highly tedious; it meant we couldn't sensibly address important issues like message reliability, timeliness etc.

Nonetheless, here's why I believe RSVP aggregation is redundant:

PCN edge-nodes support the concept of an ingress-egress aggregate in their own internal tables, but they don't need to refer to an aggregate on the wire{Note 1}. PCN-ingress and PCN-egress nodes intrinscially know which e2e reservations belong to which aggregate by grouping together those e2e reservations with the same next hop or previous hop respectively.

{Note 1: except in one case described later - but it doesn't require all the other baggage of aggregate reservations}

==Background==
Aggregate reservations [RFC3175, RFC4860] are designed to reduce the state required on interior nodes. Interior nodes still require state per aggregate reservation, but only reservation state, not classification and scheduling state [RFC3175, Section 1.4.1 last para].

In contrast, as you correctly point out (in Section 2.1.7), PCN requires absolutely no reservation-related state on interior nodes.

==Disadvantages==
Requiring PCN to use aggregate reservations has the following three disadvantages and no advantages:

1) Redundant Processing
The PATH message between aggregator and deaggregator in rsvp-pcn-03 (triggered by an E2E PathErr message from deaggregator to aggregator) is redundant, and just doubles the processing required at the PCN-edge-nodes (if this isn't obvious, I spell it out separately for PATH & RESV messages below).

2) Reduced Resilience
Not only is an aggregate PATH redundant, it actually reduces resilience. Because an aggregate PATH is pinned to interior routers. Therefore, when routing changes, it is more complex and slower to move to the new route. By not pinning to interior routers, PCN was designed to 'just work' over interior routing changes - with no need for any changes to the RSVP PATHs. (But it would still detect overload after a re-route and terminate or rate-reduce flows if necessary.)

3) Extra Latency
A further disadvantage is the extra latency required for the first reservation that sets up an aggregate. This is two ingress-egress round trips minus the round trip time from egress to destination (or one ingress-egress round trip if it is greater). This will rarely add to latency on heavily used ingress-egress aggregates, but it will occur frequently on all the 'long-tail' (lightly used) ingress-egress aggregates.

==PATH==

With RFC 3175 or 4860 aggregate paths, the aggregator forwards the e2e PATH messages with IP protocol number RSVP-E2E-IGNORE and the deaggregator changes them back to RSVP before forwarding onward. Also the aggregator sends an aggregate PATH message, which is processed by each interior node and by the deaggregator.

On a path across a PCN region, given interior nodes ignore aggregate PATH messages as well, the only PCN nodes that handle aggregate messages are the aggregator and the deaggregator. The aggregator and deaggregator process all the e2e PATH messages anyway, so if we require the aggregator to add up all the e2e PATH messages and form them into an aggregate PATH message, this is just extra redundant work for both PCN-edge-nodes.

==RESV==

The deaggregator unicasts e2e RESV messages to the previous RSVP hop, which is the aggregator. Therefore, if we require the deaggregator to add up all the RESV messages and form them into an aggregate RESV message, this is just redundant work for both PCN-edge-nodes, because they both already process all the e2e RESV messages anyway, and no other node uses the aggregate RESV messages.

==PCN object==

This raises the question of how the PCN-egress communicates the various marking rates (the PCN object) to the PCN-ingress. There are two possibilities:
i) the PCN-egress includes a current PCN object in each e2e RESV that it returns to the PCN-ingress. The PCN-ingress strips the PCN object out before forwarding the RESV back to the previous RSVP hop.
ii) the PCN-egress attaches a PCN object to an aggregate reservation, as in pcn-rsvp-03.

Either are possible, because a PCN object carries information about marking probabilities, and PCN works on the assumption that the marking probability of an ingress-egress aggregate is the same as the marking probability of the flows within the aggregate. A PCN object can be contained either in an e2e RESV or an aggregate RESV as long as the PCN-ingress can associate an e2e RESV with the correct aggregate (which it can, because it maintains an internal table of mappings between e2e reservations and their aggregates).

Which of the two is best is a question of message timing...

* For e2e admission decisions, the PCN object is only needed at the time each e2e RESV is sent, so option i) makes sense.

* For flow rate reduction or flow termination decisions, the deaggregator needs to regularly send PCN objects to the ingress.

The PCN-egress is sending regular e2e RESV refresh messages to the PCN-ingress, so a PCN object can be included in each of these. To ensure that PCN objects are sent often enough, I suggest the PCN-egress also maintains a timer per ingress-egress aggregate which it resets every time it sends a PCN object for that IEA. If the timer expires, the PCN-egress sends a PCN object to the PCN-egress even thought it was not triggered by an e2e RESV refresh. We could require the SESSION object in this message to refer to either of:
a) any one of the e2e SESSIONs in the aggregate,
b) the aggregate.

In case (a), the message would need to somehow tell the ingress not to forward this RESV refresh to the RSVP previous hop.

In case (b) in the PCN-ingress table of mappings between e2e SESSIONs and aggregate SESSIONs, it would include an entry for the aggregate that maps to itself. If the result of the look-up is the same as the input, it knows not to forward the RESV refresh further.

The wire protocol doesn't need to identify whether the SESSION is an aggregate or not. This is the one case I mentioned at the start {Note 1} where an aggregate is referred to on the wire.



In summary, PCN already reduces reservation state and processing to nothing on interior nodes. Adding aggregate reservations to PCN requires more processing and state, it unnecessarily pins routes to interior nodes and adds unnecessary latency.


Bob

At 18:23 14/11/2012, karagian@cs.utwente.nl wrote:
Hi Bob,
 
Regarding the generic aggregated RSVP selection, actually the PCN WG agreed with this selection!
This was actually the first step that was needed for this work, and the PCN WG had no main objections on this selection!
 
So I do not understand your remark that your comment will have major implications!
 
Please note that the generic aggregated RSVP is selected since the PCN IEA are associated with flows that are aggregated at the edges. So a signalling protocol that supports aggregation of flows at the edges is very suitable for this purpose! The generic aggregated RSVP is such a signalling protocol!
 
 
Best regards,
Georgios
 
 
 
 
From: Bob Briscoe [ mailto:bob.briscoe@bt.com]
Sent: woensdag 14 november 2012 12:57
To: Anurag Bhargava (anuragb)
Cc: Karagiannis, G. (EWI)
Subject: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03
 
Anurag,

I have my comments half-written up. I will try to finish them by the end of today.

They should be orthogonal to the PBAC comment below, so if you wanted to start altering that area, I don't think it would waste too much time.

However, my main comments will concern the use of aggregated reservations (as I said at the mic), so that could have major implications.


Bob

At 20:14 13/11/2012, Anurag Bhargava (anuragb) wrote:

Hi Bob,
 Thanks for the comments. If U have some text that will be great els I have also started putting some text on the topic U brought up.
 May be we can conference after US thanksgiving week and collaborate the text and try to move forward.

 Please let us know what might be a good time and I can schedule a Webex conf.

Thx
-Anurag

From: "karagian@cs.utwente.nl " <karagian@cs.utwente.nl >
Date: Saturday, November 10, 2012 8:10 AM
To: "bob.briscoe@bt.com" <bob.briscoe@bt.com>
Cc: "carlberg@g11.org.uk" <carlberg@g11.org.uk>, Anurag Bhargava <anuragb@cisco.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "philip.eardley@bt.com " <philip.eardley@bt.com >
Subject: RE: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03

Hi Bob,

 

Thanks very much for the comments! I think that they are very useful!

 

It will be very beneficiary for the fast progress of this draft if you would like to contribute as a co-author to this draft and write this additional section that describes "that the PCN-ingress can refer flow admission and
termination decisions to a central decision point (using e.g. COPS), which will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingress could itself be the policy decision point.)"

 

Best regards,

Georgios

 
Van: Bob Briscoe [bob.briscoe@bt.com]
Verzonden: vrijdag 9 november 2012 16:33
To: Karagiannis, G. (EWI)
Cc: carlberg@g11.org.uk; anuragb@cisco.com; tsvwg@ietf.org; EARDLEY, Phil
Onderwerp: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03

Georgios,

I shall post my full review of this draft in the next few days (needs
typing up - currently scribbled on a paper copy). This email is
solely in response to your answer about on-path vs off-path policy.

At 18:55 04/11/2012, karagian@cs.utwente.nl wrote:
>So in this case an additional signaling protocol will be
>needed to be specified that covers the signaling between the
>PCN-egress-node and the centralized node
>and between PCN-ingress-node and the centralized node.
>In PCN we decdided to only focus on the specification of the
>signaling protocol that completes the
>feedback loop from PCN-egress-node to PCN-ingress-node and to focus
>on the signaling protocol
>used between the edge nodes and the centralized node.

When I/we originally designed CL-PCN over RSVP (2005), the idea was
that it would fit with the policy-based admission control (PBAC)
architecture of RFC2753. In this architecture, an Intserv node at the
ingress to a domain is the policy enforcement point (PEP), and it
refers to a logically centralised 'policy decision point' (PDP) for
decisions on which flows to block/terminate, typically using COPS.

To make this doc fit the PBAC framework, all we have to do is:
* Describe the PCN-ingress only as the PCN-ingress and not as the
decision point (find 'decision' throughout doc and fix).
* Add a section saying the PCN-ingress can refer flow admission and
termination decisions to a central decision point (using e.g. COPS),
which will respond to the PCN-ingress as per RFC2753. (Alternatively
the PCN-ingress could itself be the policy decision point.)
* Refer to this new PBAC section from Section 3.11 giving the
admission decision procedure.

* Some people might think this means COPS will need new protocol
elements to carry PCN marking rates to the policy decision point. But
PCN marking rates are irrelevant to the policy decision: the
PCN-ingress just uses PCN to determine whether it needs to block or
terminate, and it refers to the policy decision point for which flows
to block/terminate.

* Unfortunately, neither of the two PCN system descriptions [RFC6661,
RFC6662] describe a PBAC-based case. The architecture [RFC5559]
refers to the PBAC framework [RFC2753] but unfortunately doesn't
spell out how it fits. Originally, I referenced PBAC from RFC5559,
but just as the PCN w-g was closing I realised that (some?) others in
the PCN w-g were working under the assumption that the only way to
talk to a centralised policy node was from the egress, possibly
without being aware of the contents of RFC2753.

I think it's OK to introduce a new architectural arrangement in this
RSVP doc, given RFC2753 is specific to the way RSVP works.


Bob



At 12:28 05/11/2012, karagian@cs.utwente.nl wrote:
>Hi Ken,
>
>Thank you very much!
>We will try to catch Francois and discuss the last (in line) issue with him!
>
>Best regards,
>Georgios
>
>________________________________________
>Van: ken carlberg [carlberg@g11.org.uk]
>Verzonden: maandag 5 november 2012 13:23
>To: Karagiannis, G. (EWI)
>Cc: tsvwg@ietf.org; anuragb@cisco.com
>Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03
>
>Georgios,
>
> > Georgios: We will try to explain the rationale of why we consider
> that RSVP can only be used for the situation that the
> > decision point is collocated with the PCN-ingress-node. The main
> reason of this is that in the case that the
> > decision point is collocated with the PCN-ingress-node,the
> required signaling protocol used to complete a
> > feedback loop from egress to ingress can be an entirely on-path
> protocol, like what RSVP is.
> > In the situation that the the decision point is a centralized
> node, then the required signaling protocol
> > can be a combination of an on-path and off-path protocol. This is
> because the
> > decision point might not be located on the data path! So in this
> case an additional signaling protocol will be
> > needed to be specified that covers the signaling between the
> PCN-egress-node and the centralized node
> > and between PCN-ingress-node and the centralized node.
> > In PCN we decdided to only focus on the specification of the
> signaling protocol that completes the
> > feedback loop from PCN-egress-node to PCN-ingress-node and to
> focus on the signaling protocol
> > used between the edge nodes and the centralized node.
> > This is also the reason of why PCN WG decided to only focus on
> the situation that the decision point is
> > collocated with the PCN-ingress-node.
>
>Great, this is helpful, and this is the information that needs to be
>in the draft.
>
> >> 6) This comment is just for you to contemplate -- I'm not
> expecting any changes.
> >> I noticed that you have a fair number of SHOULD, and some SHOULD NOTs.
> >> And it seems a lot of this is a carry over from rfc-4860, so in
> a sense you are inheriting an approach that
> >> was agreed to from an earlier effort.  But I wonder in the back
> of my mind, what impact occurs if
> >> an implementor doesn't follow the SHOULD?  Does the design break
> in supporting PCN?
> >> Again, I want to stress that this isnt a show stopper, but I
> would appreciate it if you gave it some thought.
> >
> > Georgios: Yes, in several cases the design might break in supporting PCN.
> > This is also the reason of using SHOULD instead of MAY. Do you
> want us to explain this in more detail in the draft?
>
>well, actually, I was more curious as to why a number of these cases
>are SHOULD instead of MUST.  Again, the SHOULD's in your document
>seem to be a carry-over from rfc-4860 (which set the precedent), so
>its a bit unfair for you to explain what was done in an earlier
>effort.  I just wanted to make sure you gave some thought to the
>subject.  And if things will break if SHOULD is not followed by an
>implementer/configuration, then maybe you should be more stringent
>and change things to MUST.  Perhaps a brief private conversation
>with Francois Le Faucheur will be helpful.
>
>cheers,
>
>-ken

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design --=====================_662145354==.ALT-- From bob.briscoe@bt.com Thu Nov 15 13:02:23 2012 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 C0DE721F89FA for ; Thu, 15 Nov 2012 13:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.296 X-Spam-Level: X-Spam-Status: No, score=-3.296 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvYHZ8EgQ9xP for ; Thu, 15 Nov 2012 13:02:18 -0800 (PST) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 29F1721F867F for ; Thu, 15 Nov 2012 13:02:18 -0800 (PST) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 15 Nov 2012 21:02:13 +0000 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 15 Nov 2012 21:02:15 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.309.2; Thu, 15 Nov 2012 21:02:14 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1353013332993; Thu, 15 Nov 2012 21:02:12 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.9.241]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qAFL2BWE010641; Thu, 15 Nov 2012 21:02:11 GMT Message-ID: <201211152102.qAFL2BWE010641@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 15 Nov 2012 21:02:14 +0000 To: Tom Taylor From: Bob Briscoe In-Reply-To: <50A51B8C.4010806@gmail.com> References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> <50A51B8C.4010806@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: PCN IETF list , anuragb@cisco.com, tsvwg@ietf.org, rsvp-dir@ietfa.amsl.com Subject: Re: [tsvwg] [PCN] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-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: Thu, 15 Nov 2012 21:02:23 -0000 Tom, The RSVP message I'm proposing doesn't say "Never mind the SESSION in this message, I'm related to every flow with the same first hop". It says "These are the marking probabilities for the SESSION in this message". Then the PCN-ingress (not the message) infers that all other flows that share the same aggregate will share the same marking probability, because PCN marking on interior nodes is random and unbiased. It's a subtle distinction, but it preserves the semantics of RSVP messages, without the three disadvantages of setting up an RSVP aggregate that I mentioned. You will have seen from the rest of the message that I have not rejected the concept of aggregation, I am merely saying that the PCN-ingress and PCN-egress can hold the concept internally. Bob At 16:42 15/11/2012, Tom Taylor wrote: >I'm not sure the semantics of the PCN information -- particularly as >it relates to flow termination -- are correct without some sort of >concept of aggregation. Or can you really define an RSVP object that >has semantics "Never mind the SESSION in this message, I'm related >to every flow with the same first hop"? > >On 15/11/2012 8:07 AM, Bob Briscoe wrote: >>Georgios, Anurag, >> >>Below is the main point of my review, arguing that aggregate >>reservations are redundant. I'm reviewing as: >>- a member of the RSVP directorate >>- one of the early PCN design team >>- a co-author of draft-lefaucheur-rsvp-ecn-01, on which this draft is >>based. >> >>I would have missed any decision to use aggregate reservations. Pls >>point me to the relevant discussion (e.g. Subject line / date). >... ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Thu Nov 15 13:35:22 2012 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 144DC21F8477 for ; Thu, 15 Nov 2012 13:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygvIOm2g-Wyd for ; Thu, 15 Nov 2012 13:35:20 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 2EECE21F869B for ; Thu, 15 Nov 2012 13:35:20 -0800 (PST) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 15 Nov 2012 21:35:18 +0000 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 15 Nov 2012 21:35:17 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.309.2; Thu, 15 Nov 2012 21:35:12 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1353015311759; Thu, 15 Nov 2012 21:35:11 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.9.241]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qAFLZ95f010718; Thu, 15 Nov 2012 21:35:09 GMT Message-ID: <201211152135.qAFLZ95f010718@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 15 Nov 2012 21:34:39 +0000 To: , "Anurag Bhargava (anuragb)" From: Bob Briscoe In-Reply-To: References: <20121011194603.11308.61516.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: pcn@ietf.org, tsvwg@ietf.org, rsvp-dir@ietfa.amsl.com Subject: Re: [tsvwg] [PCN] FW: New Version Notification - draft-ietf-tsvwg-rsvp-pcn-03.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, 15 Nov 2012 21:35:22 -0000 Georgios & Anurag, Thank you for this draft. Below is my review, as: - a member of the RSVP directorate - one of the PCN design team - a co-author of draft-lefaucheur-rsvp-ecn, on which this draft is based. I have already sent my main technical concerns in two separate emails, summarised below (but I suggest we use the separate threads to discuss): 1. It would be easy to allow for an off-path policy-decision point (PDP), as per RFC2753 (policy-based admission control (PBAC) framework) 2. PCN already reduces reservation state and processing to nothing on interior nodes. Adding aggregate reservations to PCN adds 3 disadvantages and no advantages: - it requires more processing and state in interior nodes and boundary-nodes - it unnecessarily pins routes to interior nodes and - it adds unnecessary latency. This email reviews comprehensibility and raises a large number of lesser technical concerns (26 to be precise), as well as editorial nits (many of which may be irrelevant if I'm right about the major technical concerns). ==General style== I didn't find the style useful at all. Sections 1, 2 & 3 defer everything meaningful into pointers to other RFCs. This makes it incomprehensible, even if you know all the references intimately. Lixia's suggestion that you refer to the specific sections of other RFCs won't be enough. An RFC should be understandable without re-reading its references (readers should have read them, but they shouldn't be expected to remember every detail). I have to say we are moving very slowly, and backwards. When Francois Le Faucheur first wrote the ancestor to this draft (7 years ago!), I could understand it immediately, and in half the pages it covered nearly everything in this draft and covered the gaps I have listed below. [In the interests of full disclosure: I became a co-author of draft-lefaucheur-tsvwg-rsvp-ecn-00, nonetheless Francois's pre-00 draft was more comprehensible and complete than this one, even before the co-authors did the first reviews.] This draft says very little itself, but ends up much longer. For example Section 3 tediously repeats content-free text like: " In this document it is considered that for <Title> the same methods can be used as the ones described in <reference>". Not only section 3; sections 1 & 2 also rely wholly on references, making them just as incomprehensible. I also agree with the other reviewers' suggestions to focus the introduction initially on what this draft adds, and move the background material after that. In summary: avoid phrases like "the same methods as" or "standard RSVP aggregation [...] procedures are used". Instead just say directly how it works. ==Normative & Technical Points== ==Gaps== * How an aggregate reservation is created vs. how one is used if it is already present * How next hop addresses are discovered (a PCN domain is only one RSVP hop unlike with RSVP aggregation, so although the process is similar, this needs to be described explicitly) * How PCN interior nodes ignore RSVP messages: - by configuration? - or by the PCN-ingress switching aggregate PATH messages to IP protocol number RSVP-E2E-IGNORE (which isn't strictly the right name but would have the right effect)? * Error conditions, for instance when messages don't contain the expected objects, e.g. [draft-lefaucheur-tsvwg-rsvp-ecn-01, page 6 bullet 1]. * How per-node state is maintained and the interaction with RSVP soft state refresh messages is not discussed. PCN-related state is unlike other RSVP state, in that it continually varies (it is controlled by a varying signal). Therefore it needs to be clear that the fields of the PCN object reflect the current value when sent, not their original value, which is what an RSVP implementer would normally expect. ==Specific sections== 1. Introduction " This document, and according to [RFC4860] MAY also be used end-to-end directly by end-systems attached to a Diffserv network. " No. See RFC5559 for PCN applicability - there is insufficient aggregation for PCN to work effectively e2e. The PCN applicability statement in RFC5559 should be stated here instead: PCN is only applicable to links with aggregation levels where the bit-rate of the largest flow is tens of times smaller than the smallest available link rate in the PCN region. OLD: In this document it is considered that the PCN-nodes MUST be able to support the functionality specified in [RFC5670], [RFC5559], [RFC6660], [RFC6661], [RFC6662]. NEW: To comply with this specification, PCN-nodes MUST be able to support the functionality specified in [RFC5670], [RFC5559] [RFC6660], and either [RFC6661] or [RFC6662]. Section 2.1 first para: " In addition, in this document it is considered that the PCN-boundary nodes are able to distinguish and process (1) RSVP SESSIONS for generic aggregated sessions and their messages according to [RFC4860], (2) e2e RSVP sessions and messages according to [RFC2205]. " Say how (by the addresses that the RSVP messages are addressed to). " Furthermore, it is considered that the PCN-interior-nodes are not able to distinguish neither RSVP generic aggregated sessions and their associated messages [RFC4860], nor e2e RSVP sessions and their associated messages [RFC2205]. " Say how (see two possibilities in 'Gaps' above). This is also not explained in Sections 2.1.7., 3.2 & 3.7, which are all meant to be about this. Section 2.1 bottom of p11: "The RSVP SESSION object for generic aggregate reservations is based on the RSVP SESSION object specified in [RFC4860] augmented with the following information: o) the IPv4 DestAddress, IPv6 DestAddress SHOULD be set to the IPv4 or IPv6 destination addresses, respectively, of the Deaggregator (PCN-egress-node) " Say how - see 'Gaps' above - the whole process of RFC4860 (e2e PATH, e2e PathErr, aggregate PATH) finds the right address, but this needs to be described because in PCN the RSVP hop is across multiple IP nodes (the whole PCN-domain), unlike with RSVP aggregation. Section 2.1.2. " The PCN-traffic (e.g., e2e microflows) belonging to an ingress- egress-aggregate can be classified only at the PCN-boundary-nodes using the combination of (1) PCN-BA (i.e., combination of the DSCP and ECN fields), (2) IP addresses of the specific pair of PCN- boundary-nodes used by a ingress-egress-aggregate. [...] Moreover, the PCN-traffic (e.g., e2e microflows) belonging to a RSVP generic aggregated reservation can be classified only at the PCN-boundary-nodes (i.e., Aggregator and Deaggregator) by using the RSVP SESSION object for RSVP generic aggregated reservations, see [RFC4860]. " Are you assuming a tunnel? You haven't said so? Otherwise the traffic doesn't contain the PCN-boundary-node addresses. Section 2.1.8. Inter-domain Routes PCN charter scope precludes inter-domain considerations. I personally would happy to have discussion of inter-domain matters in here, but it will not be complete, because we would need to discuss security & integrity of PCN objects, but the PCN charter precluded that. Section 2.1.10. Multi-level Aggregation " PCN does not consider multi-level aggregations within the PCN domain. " You have referenced generic aggregate reservations throughout [RFC4680], rather than just aggregate reservations [RFC3175]. I understand the difference is that RFC4860 supports e.g. multiple levels of precedence. So why say we don't consider multi-level aggregation? Section 3.1 " o) The e2e RSVP reservation session associated with an e2e Path message that arrives at the external interface of the PCN- ingress-node is mapped/matched onto an existing RSVP generic aggregation reservation state. " You haven't said how the existing aggregate is created in the first place (see 'Gaps' above). Section 3.1 (twice) " A new error code "PCN-domain rejects e2e reservation" MUST be augmented to the RSVP error codes to inform the sender that a PCN domains rejects the e2e reservation request. " Disagree. The regular error code "01: Admission Control failure" should be used, so that end-system implementations understand that the call has been blocked. It should also use the regular "Sub-code = 2: Requested bandwidth unavailable". If the PCN-ingress uses a different code, it will imply to other RSVP nodes including end-systems that admission control did not fail. If it uses the 01 error code but a different sub-code it will imply that AC failed, but not because of insufficient bandwidth. PCN is one (of many) mechanisms to determine whether a reservation should be blocked. For other nodes, it is not relevant to describe the mechanism (PCN) that was used to determine that there was insufficient bandwidth. Section 3.1 " o) If for the same ingress-egress-aggregated and the same RSVP generic aggregated reservation then (1) the PCN-admission- state and/or (2) the state for the RSVP generic aggregated reservation are/is "block", the flow SHOULD NOT be admitted [...] The way of how the PCN-admission-state is maintained is specified in [RFC6661] and [RFC6662]. The way of how the RSVP generic aggregated reservation state is maintained is specified in [RFC4860]. " As discussed in my email arguing against aggregate reservations, the e2e RESV message can carry an up-to-date PCN object for the PCN-ingress to decide whether to admit the flow signalled by the same message, given the PCN-ingress already handles e2e RESV messages. There is no need to rely on admission state determined earlier, given the PCN-egress already sends an e2e RESV message to the PCN-ingress at admission time. Section 3.2 and 3.7 (and 2.1.7). Neither section says how interior nodes are arranged to ignore RSVP messages (see 'Gaps' earlier which suggests two possible approaches). Section 3.8 (last sentence) " The address of the PCN-ingress- node is the one specified in the same ingress-egress-aggregate." I cannot work out how Section 3.11 Separation of the policy enforcement role of the PCN-ingress from a policy decision role (that may be off-path) will need to be added to the first bullet of this section (see other email). Section 3.11 " However, based on a local policy, the Aggregator could use other procedures of terminating microflows. " Please delete. Policy determines /which/ flows are terminated, not /how/ the termination procedure works. Section 3.12 I don't understand the purpose of this section - section 3.11 seems to have already said everything that section 3.12 says. Section 3.13 Say why an aggregate reservation would need to be removed: - no e2e reservations left in the aggregate? - such severe pre-congestion that every flow in the aggregated has to be terminated (!!!???) Section 4. Protocol Elements " The protocol elements in this document are using the protocol Elements defined in [RFC4860], augmented with the following rules: " This doc uses a number of protocol elements from the base RSVP spec, not just the extras defined in RFC4860. BTW, protocol elements are generally called classes in RSVP documents (and instances of them are called objects). Also the grammar and capitalisation in this sentence is pretty poor. Section 4. Protocol Elements The first two bullets are inappropriate here and more appropriate to section 3. Section 4.1 PCN Object I don't see why the PCN object needs to contain the IP addresses of the PCN-ingress and PCN-egress. These will be in the SESSION object earlier in the list of RSVP objects, and RFC2205 says that the SESSION object defines the session for the other objects that follow. This also means we don't need different PCN objects for IPv4 & IPv6. Section 4.1 PCN Object s/rate/fraction/ I don't think you mean rate, which implies with respect to time. I think you mean the fraction of bytes in packets with each marking relative to the total bytes in PCN marked packets. Section 4.1 PCN Object I suggest that the PCN object always reports the fractions of all three non-zero values of the PCN (aka ECN) field, even for single marking (SM) mode that doesn't use one of the codepoints. Then PCN-egress implementations and the PCN object on the wire can be the same for both SM & CL modes (I think), and only the ingress has to be different. Section 4.1 PCN Object (and IANA Considerations) IANA need to be told the high order 2 bits of the Class-Num, to exploit the Unknown Class rules of [RFC2205, section 3.10]. I suggest the Class-Num is 10bbbbbb, so that any node outside a PCN domain that receives a PCN object and doesn't understand it will strip it off and forward the remainder of the RSVP message. Ideally we would want the RSVP message (with or without the PCN object) to be forwarded and an error message raised, but that option is not available; RSVP only allows an error message to be raised when it discards a whole message. Section 4.1 PCN Object The section defines a PCN CL Flow IDs object. It's not clear whether it is meant to be a different object from the PCN object, or an extension to it. I think it would be clearer to make it a separate RSVP object, although in theory a PCN-ingress could work out that a PCN CL Flow IDs object is included, by a calculation from the object length (because the base PCN object is always a fixed length). I don't see the point of the LENGTH field (for the number of flow ID objects), given RSVP gives the length of an object in octets, from which the number of flow ID objects can be derived (divide by 16 for IPv4 or divide by 40 for IPv6). Also RSVP objects have to align on 4 octet boundaries. ==Editorial Nits== Globally: s/In this document it is considered that.../ /To comply with this specification.../ Abstract: s/specifies the extensions to/ /specifies extensions to/ 1. Intro s/collocated/ /colocated/ s/extensions to the Generic Aggregated RSVP [RFC4860] for the support of/ /extensions to Generic Aggregated RSVP [RFC4860] for support of/ OLD Furthermore, this document and according to [RFC4860], in absence of e2e RSVP flows, a variety of policies (not defined in this document) can be used at the Aggregator to set the DSCP of packets passing into the aggregation region and how they are mapped onto generic aggregate reservations. These policies are not described in this document but are a matter of local configuration. NEW In a similar way to [RFC4860], the Aggregator can detect flows based on policy (not defined in this document) rather than using e2e RSVP flow signalling. Then it can map them onto aggregate reservations and set the DSCP of the packets of these flows as they pass into the aggregation region. Section 1.1. Terminology " Ingress-egress-aggregate (IEA): [...] combination of (1) fields), (2) IP addresses of the " Some text appears to be missing here. Section 1.1. Terminology OLD: t-recvFail An ingress-egress-aggregate timer that is used at The Decision point (in this document at the PCN- ingress-node) which when expires raises an alarm to management, and activates the PCN-ingress-node to block the admission of new PCN-flows. This timer expires when it value is equal to T-fail and is reset when a report, i.e., RSVP aggregated RESV message, is received for a RSVP generic aggregated reservation (which is matched to one ingress-egress-aggregate). NEW: t-recvFail A timer per ingress-egress-aggregate that the PCN-ingress-node sets every time it receives an RSVP RESV message for that ingress-egress-aggregate. When its value reaches T-fail it is assumed that the PCN-ingress has lost contact with the PCN-egress. Therefore the PCN-ingress blocks admission of new PCN-flows into that aggregate and raises a management alarm. REASONING: The order in which the clauses were written made it hard to understand, there was nothing to say what it measured, and it wasn't clear what scope was implied by "it blocks PCN-flows". Section 1.1 Terminology Underscores (e.g t_meas) are often used in the terminology section, whereas hyphens (e.g. t-meas) are used in the body text. Section 2.1 Overview There is no Section 2.2, so all the sub-sections of 2.1.X could be promoted. Section 2.1.1 s/used, SHOULD/used SHOULD/ Section 2.1.2. OLD: The PCN-traffic is marked using PCN-marking and is classified using The PCN-BA (i.e., combination of the DSCP and ECN fields). NEW: The PCN-ingress marks a PCN-BA useing PCN-marking (i.e., combination of the DSCP and ECN fields), which interior nodes use to classify PCN-traffic. REASONING: Avoid passive verbs - ambiguous. Section 2.1.3 s/for the determination of/to determine the address of/ Section 2.1.4 " o) PCN-ingress-node MUST use one or more policies to estimate whether an e2e RSVP reservation session associated with an e2e Path message that arrives at the external interface of the PCN-ingress- node can be mapped onto an existing RSVP generic aggregation reservation state. " This is a straightforward mapping function, it shouldn't involve policy. Also mappings are deterministic - the word estimate is wrong. Section 3.1 " o) If the timer t-recvFail expires [...] o) If the timer t-recvFail does NOT expire [...] " Switch the order of these two bullets, to describe the normal (successful) behaviour first. Section 3.1 s/ingress-egress-aggregated/ /ingress-egress-aggregate/ s/then (1)/ /(1) [However, I suggest earlier that the technical sense should be substantially changed, possibly making these editorial changes irrelevant.] Section 3.8. OLD: The PCN object is specified in this document and is used for the report of the data measured by the PCN-egress-node, for a particular ingress-egress-aggregate, see [RFC6661], and [RFC6662]. NEW: The PCN-egress-node reports the marking probabilities it measures for a particular ingress-egress-aggregate in a PCN object, as specified in Section 4 (see also [RFC6661], and [RFC6662]). REASONING: Poor sentence order. Section 3.11. s/associated to one ingress-egress-aggregate/ /associated with one ingress-egress-aggregate/ Section 3.15 Repeats Section 2.1.9. Unnecessary. Section 4. s/by an PCN-egress node/ /by a PCN-egress node/ Regards Bob At 19:55 11/10/2012, karagian@cs.utwente.nl wrote: >Hi all, > >Please note that draft-ietf-tsvwg-rsvp-pcn-03.txt has just been submitted! >All comments received during the tsvwg meeting in Vancouver and >during the tsvwg and pcn mailing lists have been worked out! > >If you have any other comments please send them to the tsvwg mailing list! > >Best regards, >Georgios > > >________________________________________ >Van: internet-drafts@ietf.org [internet-drafts@ietf.org] >Verzonden: donderdag 11 oktober 2012 21:46 >Aan: tsvwg-chairs@tools.ietf.org; >draft-ietf-tsvwg-rsvp-pcn@tools.ietf.org; martin.stiemerling@neclab.eu >Onderwerp: New Version Notification - draft-ietf-tsvwg-rsvp-pcn-03.txt > >A new version (-03) has been submitted for draft-ietf-tsvwg-rsvp-pcn: >http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-pcn-03.txt > > >The IETF datatracker page for this Internet-Draft is: >https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn/ > >Diff from previous version: >http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rsvp-pcn-03 > >IETF Secretariat. >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn ________________________________________________________________ Bob Briscoe, BT Innovate & Design From karagian@cs.utwente.nl Fri Nov 16 05:02:37 2012 Return-Path: <karagian@cs.utwente.nl> 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 E187121F8623; Fri, 16 Nov 2012 05:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysBKDMVkVQDS; Fri, 16 Nov 2012 05:02:32 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id D8FA221F84BA; Fri, 16 Nov 2012 05:02:31 -0800 (PST) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 16 Nov 2012 14:02:25 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.65]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0318.004; Fri, 16 Nov 2012 14:02:24 +0100 From: <karagian@cs.utwente.nl> To: <bob.briscoe@bt.com> Thread-Topic: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 Thread-Index: AQHNwzIz0DiUx9R5AUqjyGs4URlrFZfsbQPrgAAB2T4= Date: Fri, 16 Nov 2012 13:02:24 +0000 Message-ID: <38323AE1-362C-4DBF-87A0-2D468586CC53@mimectl> References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <E728D0E3C41E644A96A7CCA61863BED4081DE009@xmb-aln-x12.cisco.com> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> <FF1A9612A94D5C4A81ED7DE1039AB80F2ED8FEDF@EXMBX04.ad.utwente.nl>, <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> In-Reply-To: <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.56.40.134] Content-Type: multipart/alternative; boundary="_000_38323AE1362C4DBF87A02D468586CC53mimectl_" MIME-Version: 1.0 Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, slblake@petri-meat.com, philip.eardley@bt.com, anuragb@cisco.com, sob@harvard.edu, rsvp-dir@ietfa.amsl.com, pcn@ietf.org, jmpolk@cisco.com Subject: Re: [tsvwg] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 16 Nov 2012 13:02:37 -0000 --_000_38323AE1362C4DBF87A02D468586CC53mimectl_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Bob, =1B$B!!=1B(B Thanks for your comments! Regarding your statement: What I meant in my previous email is that our ind= ividual draft that was used as a working basis for this WG draft was alrea= dy using the generic aggregation RSVP (RFC 4860) as the existing signaling = protocol, see: http://tools.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt Moreover, during IETF 81, this individual draft has been presneted, where a= lso the rationale of using (RFC 4860) was also the following slides see pre= sentation slides (slide 5): http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf =1B$B!!=1B(B In particular in slide 4 mentions: "All PCN charter items are fulfilled, except: Submit Encoding and Transport of PCN from Domain Egress to Ingress to the I= ESG for consideration as a Proposed Standard RFC Pairs of PCN edge nodes use ingress-egress-aggregates (IEA): Need a signaling protocol to transport PCN information from PCN-egress-node= to PCN-ingress-node and to maintain ingress-egress-aggregate between each = pair of PCN edge nodes" Furthermore Slide 5 mentions: =1B$B!!=1B(B "IETF QoS signaling protocols to solve problem: Next Steps in Signaling Protocol (NSIS) subset (RFC 5971, RFC 5974, RFC 597= 9) Aggregation of RSVP for IPv4 and IPv6 Reservations (RFC3175) Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations (RFC486= 0) All can be used, but for time being selected RFC 4860 due: possible deployment interest supports RFC 3175 and additional features such as: support of multiple IEAs from same pair of PCN edge nodes support of bandwidth reduction for individual flows (RFC 4495)" =1B$B!!=1B(B Before IETF 81 and during IETF 81 this point has been discussed. The outcome of these discussions is that short after IETF 81, the individua= l draft (draft-karagiannis-pcn-tsvwg-rsvp-pcn-01) become (after small modifications) the draft-ietf-tsvwg-rsvp-pcn-00, which = also was using RFC 4860 as the base signaling protocol. =1B$B!!=1B(B It will be very helpful if the PCN WG chairs (Scott and/or Steve) and the t= svwg WG chairs (Gorry and/or James) could confirm the above statement! =1B$B!!=1B(B So both the PCN WG and tsvwg WG agreed that this specifictaion should use a= s basis the generic RSVP aggregation protocol! =1B$B!!=1B(B =1B$B!!=1B(B =1B$B!!=1B(B In a subsequent email and on a later moment I will also answer to your furt= her remarks! =1B$B!!=1B(B Best regards, Georgios ________________________________ Van: Bob Briscoe [bob.briscoe@bt.com] Verzonden: donderdag 15 november 2012 14:07 To: Karagiannis, G. (EWI); anuragb@cisco.com Cc: carlberg@g11.org.uk; anuragb@cisco.com; tsvwg@ietf.org; philip.eardley@= bt.com; PCN IETF list; rsvp-dir@ietfa.amsl.com Onderwerp: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 Georgios, Anurag, Below is the main point of my review, arguing that aggregate reservations a= re redundant. I'm reviewing as: - a member of the RSVP directorate - one of the early PCN design team - a co-author of draft-lefaucheur-rsvp-ecn-01, on which this draft is based= . I would have missed any decision to use aggregate reservations. Pls point m= e to the relevant discussion (e.g. Subject line / date). I admit I tuned out of much of the later PCN signalling discussion. I found= the whole exercise of abstracting PCN away from specific signalling protoc= ols highly tedious; it meant we couldn't sensibly address important issues = like message reliability, timeliness etc. Nonetheless, here's why I believe RSVP aggregation is redundant: PCN edge-nodes support the concept of an ingress-egress aggregate in their = own internal tables, but they don't need to refer to an aggregate on the wi= re{Note 1}. PCN-ingress and PCN-egress nodes intrinscially know which e2e r= eservations belong to which aggregate by grouping together those e2e reserv= ations with the same next hop or previous hop respectively. {Note 1: except in one case described later - but it doesn't require all th= e other baggage of aggregate reservations} =3D=3DBackground=3D=3D Aggregate reservations [RFC3175, RFC4860] are designed to reduce the state = required on interior nodes. Interior nodes still require state per aggregat= e reservation, but only reservation state, not classification and schedulin= g state [RFC3175, Section 1.4.1 last para]. In contrast, as you correctly point out (in Section 2.1.7), PCN requires ab= solutely no reservation-related state on interior nodes. =3D=3DDisadvantages=3D=3D Requiring PCN to use aggregate reservations has the following three disadva= ntages and no advantages: 1) Redundant Processing The PATH message between aggregator and deaggregator in rsvp-pcn-03 (trigge= red by an E2E PathErr message from deaggregator to aggregator) is redundant= , and just doubles the processing required at the PCN-edge-nodes (if this i= sn't obvious, I spell it out separately for PATH & RESV messages below). 2) Reduced Resilience Not only is an aggregate PATH redundant, it actually reduces resilience. Be= cause an aggregate PATH is pinned to interior routers. Therefore, when rout= ing changes, it is more complex and slower to move to the new route. By not= pinning to interior routers, PCN was designed to 'just work' over interior= routing changes - with no need for any changes to the RSVP PATHs. (But it = would still detect overload after a re-route and terminate or rate-reduce f= lows if necessary.) 3) Extra Latency A further disadvantage is the extra latency required for the first reservat= ion that sets up an aggregate. This is two ingress-egress round trips minus= the round trip time from egress to destination (or one ingress-egress roun= d trip if it is greater). This will rarely add to latency on heavily used i= ngress-egress aggregates, but it will occur frequently on all the 'long-tai= l' (lightly used) ingress-egress aggregates. =3D=3DPATH=3D=3D With RFC 3175 or 4860 aggregate paths, the aggregator forwards the e2e PATH= messages with IP protocol number RSVP-E2E-IGNORE and the deaggregator chan= ges them back to RSVP before forwarding onward. Also the aggregator sends a= n aggregate PATH message, which is processed by each interior node and by t= he deaggregator. On a path across a PCN region, given interior nodes ignore aggregate PATH m= essages as well, the only PCN nodes that handle aggregate messages are the = aggregator and the deaggregator. The aggregator and deaggregator process al= l the e2e PATH messages anyway, so if we require the aggregator to add up a= ll the e2e PATH messages and form them into an aggregate PATH message, this= is just extra redundant work for both PCN-edge-nodes. =3D=3DRESV=3D=3D The deaggregator unicasts e2e RESV messages to the previous RSVP hop, which= is the aggregator. Therefore, if we require the deaggregator to add up all= the RESV messages and form them into an aggregate RESV message, this is ju= st redundant work for both PCN-edge-nodes, because they both already proces= s all the e2e RESV messages anyway, and no other node uses the aggregate RE= SV messages. =3D=3DPCN object=3D=3D This raises the question of how the PCN-egress communicates the various mar= king rates (the PCN object) to the PCN-ingress. There are two possibilities= : i) the PCN-egress includes a current PCN object in each e2e RESV that it re= turns to the PCN-ingress. The PCN-ingress strips the PCN object out before = forwarding the RESV back to the previous RSVP hop. ii) the PCN-egress attaches a PCN object to an aggregate reservation, as in= pcn-rsvp-03. Either are possible, because a PCN object carries information about marking= probabilities, and PCN works on the assumption that the marking probabilit= y of an ingress-egress aggregate is the same as the marking probability of = the flows within the aggregate. A PCN object can be contained either in an = e2e RESV or an aggregate RESV as long as the PCN-ingress can associate an e= 2e RESV with the correct aggregate (which it can, because it maintains an i= nternal table of mappings between e2e reservations and their aggregates). Which of the two is best is a question of message timing... * For e2e admission decisions, the PCN object is only needed at the time ea= ch e2e RESV is sent, so option i) makes sense. * For flow rate reduction or flow termination decisions, the deaggregator n= eeds to regularly send PCN objects to the ingress. The PCN-egress is sending regular e2e RESV refresh messages to the PCN-ingr= ess, so a PCN object can be included in each of these. To ensure that PCN o= bjects are sent often enough, I suggest the PCN-egress also maintains a tim= er per ingress-egress aggregate which it resets every time it sends a PCN o= bject for that IEA. If the timer expires, the PCN-egress sends a PCN object= to the PCN-egress even thought it was not triggered by an e2e RESV refresh= . We could require the SESSION object in this message to refer to either of= : a) any one of the e2e SESSIONs in the aggregate, b) the aggregate. In case (a), the message would need to somehow tell the ingress not to forw= ard this RESV refresh to the RSVP previous hop. In case (b) in the PCN-ingress table of mappings between e2e SESSIONs and a= ggregate SESSIONs, it would include an entry for the aggregate that maps to= itself. If the result of the look-up is the same as the input, it knows no= t to forward the RESV refresh further. The wire protocol doesn't need to identify whether the SESSION is an aggreg= ate or not. This is the one case I mentioned at the start {Note 1} where an= aggregate is referred to on the wire. In summary, PCN already reduces reservation state and processing to nothing= on interior nodes. Adding aggregate reservations to PCN requires more proc= essing and state, it unnecessarily pins routes to interior nodes and adds u= nnecessary latency. Bob At 18:23 14/11/2012, karagian@cs.utwente.nl wrote: Hi Bob, Regarding the generic aggregated RSVP selection, actually the PCN WG agreed= with this selection! This was actually the first step that was needed for this work, and the PCN= WG had no main objections on this selection! So I do not understand your remark that your comment will have major implic= ations! Please note that the generic aggregated RSVP is selected since the PCN IEA = are associated with flows that are aggregated at the edges. So a signalling= protocol that supports aggregation of flows at the edges is very suitable = for this purpose! The generic aggregated RSVP is such a signalling protocol= ! Best regards, Georgios From: Bob Briscoe [mailto:bob.briscoe@bt.com] Sent: woensdag 14 november 2012 12:57 To: Anurag Bhargava (anuragb) Cc: Karagiannis, G. (EWI) Subject: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 Anurag, I have my comments half-written up. I will try to finish them by the end of= today. They should be orthogonal to the PBAC comment below, so if you wanted to st= art altering that area, I don't think it would waste too much time. However, my main comments will concern the use of aggregated reservations (= as I said at the mic), so that could have major implications. Bob At 20:14 13/11/2012, Anurag Bhargava (anuragb) wrote: Hi Bob, Thanks for the comments. If U have some text that will be great els I have= also started putting some text on the topic U brought up. May be we can conference after US thanksgiving week and collaborate the te= xt and try to move forward. Please let us know what might be a good time and I can schedule a Webex co= nf. Thx -Anurag From: "karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl> " <karagian@cs= .utwente.nl<mailto:karagian@cs.utwente.nl> > Date: Saturday, November 10, 2012 8:10 AM To: "bob.briscoe@bt.com<mailto:bob.briscoe@bt.com>" <bob.briscoe@bt.com<mai= lto:bob.briscoe@bt.com>> Cc: "carlberg@g11.org.uk<mailto:carlberg@g11.org.uk>" <carlberg@g11.org.uk<= mailto:carlberg@g11.org.uk>>, Anurag Bhargava <anuragb@cisco.com<mailto:anu= ragb@cisco.com>>, "tsvwg@ietf.org<mailto:tsvwg@ietf.org>" <tsvwg@ietf.org<m= ailto:tsvwg@ietf.org>>, "philip.eardley@bt.com<mailto:philip.eardley@bt.com= > " <philip.eardley@bt.com<mailto:philip.eardley@bt.com> > Subject: RE: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 Hi Bob, Thanks very much for the comments! I think that they are very useful! It will be very beneficiary for the fast progress of this draft if you woul= d like to contribute as a co-author to this draft and write this additional= section that describes "that the PCN-ingress can refer flow admission and termination decisions to a central decision point (using e.g. COPS), which = will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingr= ess could itself be the policy decision point.)" Best regards, Georgios ________________________________ Van: Bob Briscoe [bob.briscoe@bt.com<mailto:bob.briscoe@bt.com>] Verzonden: vrijdag 9 november 2012 16:33 To: Karagiannis, G. (EWI) Cc: carlberg@g11.org.uk<mailto:carlberg@g11.org.uk>; anuragb@cisco.com<mail= to:anuragb@cisco.com>; tsvwg@ietf.org<mailto:tsvwg@ietf.org>; EARDLEY, Phil Onderwerp: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 Georgios, I shall post my full review of this draft in the next few days (needs typing up - currently scribbled on a paper copy). This email is solely in response to your answer about on-path vs off-path policy. At 18:55 04/11/2012, karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl> = wrote: >So in this case an additional signaling protocol will be >needed to be specified that covers the signaling between the >PCN-egress-node and the centralized node >and between PCN-ingress-node and the centralized node. >In PCN we decdided to only focus on the specification of the >signaling protocol that completes the >feedback loop from PCN-egress-node to PCN-ingress-node and to focus >on the signaling protocol >used between the edge nodes and the centralized node. When I/we originally designed CL-PCN over RSVP (2005), the idea was that it would fit with the policy-based admission control (PBAC) architecture of RFC2753. In this architecture, an Intserv node at the ingress to a domain is the policy enforcement point (PEP), and it refers to a logically centralised 'policy decision point' (PDP) for decisions on which flows to block/terminate, typically using COPS. To make this doc fit the PBAC framework, all we have to do is: * Describe the PCN-ingress only as the PCN-ingress and not as the decision point (find 'decision' throughout doc and fix). * Add a section saying the PCN-ingress can refer flow admission and termination decisions to a central decision point (using e.g. COPS), which will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingress could itself be the policy decision point.) * Refer to this new PBAC section from Section 3.11 giving the admission decision procedure. * Some people might think this means COPS will need new protocol elements to carry PCN marking rates to the policy decision point. But PCN marking rates are irrelevant to the policy decision: the PCN-ingress just uses PCN to determine whether it needs to block or terminate, and it refers to the policy decision point for which flows to block/terminate. * Unfortunately, neither of the two PCN system descriptions [RFC6661, RFC6662] describe a PBAC-based case. The architecture [RFC5559] refers to the PBAC framework [RFC2753] but unfortunately doesn't spell out how it fits. Originally, I referenced PBAC from RFC5559, but just as the PCN w-g was closing I realised that (some?) others in the PCN w-g were working under the assumption that the only way to talk to a centralised policy node was from the egress, possibly without being aware of the contents of RFC2753. I think it's OK to introduce a new architectural arrangement in this RSVP doc, given RFC2753 is specific to the way RSVP works. Bob At 12:28 05/11/2012, karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl> = wrote: >Hi Ken, > >Thank you very much! >We will try to catch Francois and discuss the last (in line) issue with hi= m! > >Best regards, >Georgios > >________________________________________ >Van: ken carlberg [carlberg@g11.org.uk<mailto:carlberg@g11.org.uk>] >Verzonden: maandag 5 november 2012 13:23 >To: Karagiannis, G. (EWI) >Cc: tsvwg@ietf.org<mailto:tsvwg@ietf.org>; anuragb@cisco.com<mailto:anurag= b@cisco.com> >Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03 > >Georgios, > > > Georgios: We will try to explain the rationale of why we consider > that RSVP can only be used for the situation that the > > decision point is collocated with the PCN-ingress-node. The main > reason of this is that in the case that the > > decision point is collocated with the PCN-ingress-node,the > required signaling protocol used to complete a > > feedback loop from egress to ingress can be an entirely on-path > protocol, like what RSVP is. > > In the situation that the the decision point is a centralized > node, then the required signaling protocol > > can be a combination of an on-path and off-path protocol. This is > because the > > decision point might not be located on the data path! So in this > case an additional signaling protocol will be > > needed to be specified that covers the signaling between the > PCN-egress-node and the centralized node > > and between PCN-ingress-node and the centralized node. > > In PCN we decdided to only focus on the specification of the > signaling protocol that completes the > > feedback loop from PCN-egress-node to PCN-ingress-node and to > focus on the signaling protocol > > used between the edge nodes and the centralized node. > > This is also the reason of why PCN WG decided to only focus on > the situation that the decision point is > > collocated with the PCN-ingress-node. > >Great, this is helpful, and this is the information that needs to be >in the draft. > > >> 6) This comment is just for you to contemplate -- I'm not > expecting any changes. > >> I noticed that you have a fair number of SHOULD, and some SHOULD NOTs. > >> And it seems a lot of this is a carry over from rfc-4860, so in > a sense you are inheriting an approach that > >> was agreed to from an earlier effort. But I wonder in the back > of my mind, what impact occurs if > >> an implementor doesn't follow the SHOULD? Does the design break > in supporting PCN? > >> Again, I want to stress that this isnt a show stopper, but I > would appreciate it if you gave it some thought. > > > > Georgios: Yes, in several cases the design might break in supporting PC= N. > > This is also the reason of using SHOULD instead of MAY. Do you > want us to explain this in more detail in the draft? > >well, actually, I was more curious as to why a number of these cases >are SHOULD instead of MUST. Again, the SHOULD's in your document >seem to be a carry-over from rfc-4860 (which set the precedent), so >its a bit unfair for you to explain what was done in an earlier >effort. I just wanted to make sure you gave some thought to the >subject. And if things will break if SHOULD is not followed by an >implementer/configuration, then maybe you should be more stringent >and change things to MUST. Perhaps a brief private conversation >with Francois Le Faucheur will be helpful. > >cheers, > >-ken ________________________________________________________________ Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design --_000_38323AE1362C4DBF87A02D468586CC53mimectl_ Content-Type: text/html; charset="iso-2022-jp" Content-ID: <8468B758E5B50E46AF967FF02AB03A5A@exchange.utwente.nl> Content-Transfer-Encoding: quoted-printable <html dir=3D"ltr"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-2022-= jp"> <style id=3D"owaParaStyle">P { MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px } </style> </head> <body ocsi=3D"0" fPStyle=3D"1"> <div style=3D"FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: #000000; FONT-SIZ= E: 10pt"> <span lang=3D"N"> <p>Hi Bob,</p> <p>=1B$B!!=1B(B</p> <p>Thanks for your comments!</p> <p>Regarding your statement: What I meant in my previous email is that our = individual draft that was used as a working basis for this WG draft  w= as already using the generic aggregation RSVP (RFC 4860) as the existing si= gnaling protocol, see:</p> <p> </p> <p><a href=3D"http://tools.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn= -01.txt" target=3D"_blank">http://tools.ietf.org/id/draft-karagiannis-pcn-t= svwg-rsvp-pcn-01.txt</a></p> <p> </p> <p>Moreover, during IETF 81, this individual draft has been presneted, wher= e also the rationale of using (RFC 4860) was also the following slides see = presentation slides (slide 5):</p> <p> </p> <p>http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf</p> <p>=1B$B!!=1B(B</p> <p>In particular in slide 4 mentions:</p> <p>"All PCN charter items are fulfilled, except:</p> <p>Submit Encoding and Transport of PCN from Domain Egress to Ingress to th= e IESG for consideration as a Proposed Standard RFC</p> <p>Pairs of PCN edge nodes use ingress-egress-aggregates (IEA):</p> <p>Need a signaling protocol to transport PCN information from PCN-egress-n= ode to PCN-ingress-node and to maintain ingress-egress-aggregate between ea= ch pair of PCN edge nodes"</p> <p>Furthermore Slide 5 mentions:</p> <p>=1B$B!!=1B(B</p> <p>"IETF QoS signaling protocols to solve problem:</p> <p>Next Steps in Signaling Protocol (NSIS) subset (RFC 5971, RFC 5974, RFC = 5979)</p> <p>Aggregation of RSVP for IPv4 and IPv6 Reservations (RFC3175)</p> <p>Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations (RFC= 4860)</p> <p>All can be used, but for time being selected RFC 4860 due:</p> <p>possible deployment interest</p> <p>supports RFC 3175 and additional features such as: </p> <p>support of multiple IEAs from same pair of PCN edge nodes </p> <p>support of bandwidth reduction for individual flows (RFC 4495)"</p> <p>=1B$B!!=1B(B</p> <p>Before IETF 81 and during IETF 81 this point has been discussed.</p> <p>The outcome of these discussions is that short after IETF 81, the indivi= dual draft (draft-karagiannis-pcn-tsvwg-rsvp-pcn-01) </p> <p>become (after small modifications) the draft-ietf-tsvwg-rsvp-pcn-00, whi= ch also was using RFC 4860 as the base signaling protocol.</p> <p>=1B$B!!=1B(B</p> <p>It will be very helpful if the PCN WG chairs (Scott and/or Steve) and th= e tsvwg WG chairs (Gorry and/or James) could confirm the above statement!</= p> <p>=1B$B!!=1B(B</p> <p>So both the PCN WG and tsvwg WG agreed that this specifictaion should us= e as basis the generic RSVP aggregation protocol!</p> <p>=1B$B!!=1B(B</p> <p>=1B$B!!=1B(B</p> <p>=1B$B!!=1B(B</p> <p>In a subsequent email and on a later moment I will also answer to your f= urther remarks!</p> <p>=1B$B!!=1B(B</p> <p>Best regards,</p> <p>Georgios</p> </span> <hr tabindex=3D"-1"> <div style=3D"DIRECTION: ltr" id=3D"divRpF127369"><font color=3D"#000000" s= ize=3D"2" face=3D"Tahoma"><b>Van:</b> Bob Briscoe [bob.briscoe@bt.com]<br> <b>Verzonden:</b> donderdag 15 november 2012 14:07<br> <b>To:</b> Karagiannis, G. (EWI); anuragb@cisco.com<br> <b>Cc:</b> carlberg@g11.org.uk; anuragb@cisco.com; tsvwg@ietf.org; philip.e= ardley@bt.com; PCN IETF list; rsvp-dir@ietfa.amsl.com<br> <b>Onderwerp:</b> Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-p= cn-03<br> </font><br> </div> <div></div> <div>Georgios, Anurag,<br> <br> Below is the main point of my review, arguing that aggregate reservations a= re redundant. I'm reviewing as:<br> - a member of the RSVP directorate<br> - one of the early PCN design team<br> - a co-author of draft-lefaucheur-rsvp-ecn-01, on which this draft is based= .<br> <br> I would have missed any decision to use aggregate reservations. Pls point m= e to the relevant discussion (e.g. Subject line / date).<br> <br> I admit I tuned out of much of the later PCN signalling discussion. I found= the whole exercise of abstracting PCN away from specific signalling protoc= ols highly tedious; it meant we couldn't sensibly address important issues = like message reliability, timeliness etc. <br> <br> Nonetheless, here's why I believe RSVP aggregation is redundant:<br> <br> PCN edge-nodes support the concept of an ingress-egress aggregate in their = own internal tables, but they don't need to refer to an aggregate on the wi= re{Note 1}. PCN-ingress and PCN-egress nodes intrinscially know which e2e r= eservations belong to which aggregate by grouping together those e2e reservations with the same next hop or prev= ious hop respectively.<br> <br> {Note 1: except in one case described later - but it doesn't require all th= e other baggage of aggregate reservations}<br> <br> =3D=3DBackground=3D=3D<br> Aggregate reservations [RFC3175, RFC4860] are designed to reduce the state = required on interior nodes. Interior nodes still require state per aggregat= e reservation, but only reservation state, not classification and schedulin= g state [RFC3175, Section 1.4.1 last para].<br> <br> In contrast, as you correctly point out (in Section 2.1.7), PCN requires ab= solutely no reservation-related state on interior nodes.<br> <br> =3D=3DDisadvantages=3D=3D<br> Requiring PCN to use aggregate reservations has the following three disadva= ntages and no advantages:<br> <br> 1) Redundant Processing<br> The PATH message between aggregator and deaggregator in rsvp-pcn-03 (trigge= red by an E2E PathErr message from deaggregator to aggregator) is redundant= , and just doubles the processing required at the PCN-edge-nodes (if this i= sn't obvious, I spell it out separately for PATH & RESV messages below). <br> <br> 2) Reduced Resilience<br> Not only is an aggregate PATH redundant, it actually reduces resilience. Be= cause an aggregate PATH is pinned to interior routers. Therefore, when rout= ing changes, it is more complex and slower to move to the new route. By not= pinning to interior routers, PCN was designed to 'just work' over interior routing changes - with no need f= or any changes to the RSVP PATHs. (But it would still detect overload after= a re-route and terminate or rate-reduce flows if necessary.)<br> <br> 3) Extra Latency<br> A further disadvantage is the extra latency required for the first reservat= ion that sets up an aggregate. This is two ingress-egress round trips minus= the round trip time from egress to destination (or one ingress-egress roun= d trip if it is greater). This will rarely add to latency on heavily used ingress-egress aggregates, but it wi= ll occur frequently on all the 'long-tail' (lightly used) ingress-egress ag= gregates.<br> <br> =3D=3DPATH=3D=3D<br> <br> With RFC 3175 or 4860 aggregate paths, the aggregator forwards the e2e PATH= messages with IP protocol number RSVP-E2E-IGNORE and the deaggregator chan= ges them back to RSVP before forwarding onward. Also the aggregator sends a= n aggregate PATH message, which is processed by each interior node and by the deaggregator.<br> <br> On a path across a PCN region, given interior nodes ignore aggregate PATH m= essages as well, the only PCN nodes that handle aggregate messages are the = aggregator and the deaggregator. The aggregator and deaggregator process al= l the e2e PATH messages anyway, so if we require the aggregator to add up all the e2e PATH messages and fo= rm them into an aggregate PATH message, this is just extra redundant work f= or both PCN-edge-nodes.<br> <br> =3D=3DRESV=3D=3D<br> <br> The deaggregator unicasts e2e RESV messages to the previous RSVP hop, which= is the aggregator. Therefore, if we require the deaggregator to add up all= the RESV messages and form them into an aggregate RESV message, this is ju= st redundant work for both PCN-edge-nodes, because they both already process all the e2e RESV messages anyway, and no= other node uses the aggregate RESV messages.<br> <br> =3D=3DPCN object=3D=3D<br> <br> This raises the question of how the PCN-egress communicates the various mar= king rates (the PCN object) to the PCN-ingress. There are two possibilities= :<br> i) the PCN-egress includes a current PCN object in each e2e RESV that it re= turns to the PCN-ingress. The PCN-ingress strips the PCN object out before = forwarding the RESV back to the previous RSVP hop.<br> ii) the PCN-egress attaches a PCN object to an aggregate reservation, as in= pcn-rsvp-03.<br> <br> Either are possible, because a PCN object carries information about marking= probabilities, and PCN works on the assumption that the marking probabilit= y of an ingress-egress aggregate is the same as the marking probability of = the flows within the aggregate. A PCN object can be contained either in an e2e RESV or an aggregate RESV a= s long as the PCN-ingress can associate an e2e RESV with the correct aggreg= ate (which it can, because it maintains an internal table of mappings betwe= en e2e reservations and their aggregates).<br> <br> Which of the two is best is a question of message timing...<br> <br> * For e2e admission decisions, the PCN object is only needed at the time ea= ch e2e RESV is sent, so option i) makes sense.<br> <br> * For flow rate reduction or flow termination decisions, the deaggregator n= eeds to regularly send PCN objects to the ingress. <br> <br> The PCN-egress is sending regular e2e RESV refresh messages to the PCN-ingr= ess, so a PCN object can be included in each of these. To ensure that PCN o= bjects are sent often enough, I suggest the PCN-egress also maintains a tim= er per ingress-egress aggregate which it resets every time it sends a PCN object for that IEA. If the time= r expires, the PCN-egress sends a PCN object to the PCN-egress even thought= it was not triggered by an e2e RESV refresh. We could require the SESSION = object in this message to refer to either of:<br> a) any one of the e2e SESSIONs in the aggregate, <br> b) the aggregate.<br> <br> In case (a), the message would need to somehow tell the ingress not to forw= ard this RESV refresh to the RSVP previous hop.<br> <br> In case (b) in the PCN-ingress table of mappings between e2e SESSIONs and a= ggregate SESSIONs, it would include an entry for the aggregate that maps to= itself. If the result of the look-up is the same as the input, it knows no= t to forward the RESV refresh further. <br> <br> The wire protocol doesn't need to identify whether the SESSION is an aggreg= ate or not. This is the one case I mentioned at the start {Note 1} where an= aggregate is referred to on the wire.<br> <br> <br> <br> In summary, PCN already reduces reservation state and processing to nothing= on interior nodes. Adding aggregate reservations to PCN requires more proc= essing and state, it unnecessarily pins routes to interior nodes and adds u= nnecessary latency.<br> <br> <br> Bob<br> <br> At 18:23 14/11/2012, karagian@cs.utwente.nl wrote:<br> <blockquote class=3D"cite" type=3D"cite">Hi Bob,<br>  <br> Regarding the generic aggregated RSVP selection, actually the PCN WG agreed= with this selection!<br> This was actually the first step that was needed for this work, and the PCN= WG had no main objections on this selection!<br>  <br> So I do not understand your remark that your comment will have major implic= ations!<br>  <br> Please note that the generic aggregated RSVP is selected since the PCN IEA = are associated with flows that are aggregated at the edges. So a signalling= protocol that supports aggregation of flows at the edges is very suitable = for this purpose! The generic aggregated RSVP is such a signalling protocol!<br>  <br>  <br> Best regards,<br> Georgios<br>  <br>  <br>  <br>  <br> <b>From:</b> Bob Briscoe [<a href=3D"mailto:bob.briscoe@bt.com" target=3D"_= blank">mailto:bob.briscoe@bt.com</a>] <br> <b>Sent:</b> woensdag 14 november 2012 12:57<br> <b>To:</b> Anurag Bhargava (anuragb)<br> <b>Cc:</b> Karagiannis, G. (EWI)<br> <b>Subject:</b> Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br>  <br> Anurag,<br> <br> I have my comments half-written up. I will try to finish them by the end of= today.<br> <br> They should be orthogonal to the PBAC comment below, so if you wanted to st= art altering that area, I don't think it would waste too much time. <br> <br> However, my main comments will concern the use of aggregated reservations (= as I said at the mic), so that could have major implications.<br> <br> <br> Bob<br> <br> At 20:14 13/11/2012, Anurag Bhargava (anuragb) wrote:<br> <br> Hi Bob,<br>  Thanks for the comments. If U have some text that will be great els I= have also started putting some text on the topic U brought up.<br>  May be we can conference after US thanksgiving week and collaborate t= he text and try to move forward.<br> <br>  Please let us know what might be a good time and I can schedule a Web= ex conf.<br> <br> Thx<br> -Anurag<br> <br> From: "<a href=3D"mailto:karagian@cs.utwente.nl" target=3D"_blank">kar= agian@cs.utwente.nl</a> " <<a href=3D"mailto:karagian@cs.utwente.nl= " target=3D"_blank">karagian@cs.utwente.nl</a> ><br> Date: Saturday, November 10, 2012 8:10 AM<br> To: "<a href=3D"mailto:bob.briscoe@bt.com" target=3D"_blank">bob.brisc= oe@bt.com</a>" <<a href=3D"mailto:bob.briscoe@bt.com" target=3D"_bl= ank">bob.briscoe@bt.com</a>><br> Cc: "<a href=3D"mailto:carlberg@g11.org.uk" target=3D"_blank">carlberg= @g11.org.uk</a>" <<a href=3D"mailto:carlberg@g11.org.uk" target=3D"= _blank">carlberg@g11.org.uk</a>>, Anurag Bhargava <<a href=3D"mailto:= anuragb@cisco.com" target=3D"_blank">anuragb@cisco.com</a>>, "<a hr= ef=3D"mailto:tsvwg@ietf.org" target=3D"_blank">tsvwg@ietf.org</a>" <<a href=3D"mailto:tsvwg@ietf.org" target=3D"_blank">tsvwg@ietf.org</a>= >, "<a href=3D"mailto:philip.eardley@bt.com" target=3D"_blank">phil= ip.eardley@bt.com</a> " <<a href=3D"mailto:philip.eardley@bt.com" t= arget=3D"_blank">philip.eardley@bt.com</a> ><br> Subject: RE: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br> <br> Hi Bob,<br> <br>  <br> <br> Thanks very much for the comments! I think that they are very useful! <br> <br>  <br> <br> It will be very beneficiary for the fast progress of this draft if you woul= d like to contribute as a co-author to this draft and write this additional= section that describes "that the PCN-ingress can refer flow admission= and <br> termination decisions to a central decision point (using e.g. COPS), which = will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingr= ess could itself be the policy decision point.)"<br> <br>  <br> <br> Best regards,<br> <br> Georgios<br> <br>  <br> <hr> <div align=3D"center"></div> <b>Van:</b> Bob Briscoe [<a href=3D"mailto:bob.briscoe@bt.com" target=3D"_b= lank">bob.briscoe@bt.com</a>]<br> <b>Verzonden:</b> vrijdag 9 november 2012 16:33<br> <b>To:</b> Karagiannis, G. (EWI)<br> <b>Cc:</b> <a href=3D"mailto:carlberg@g11.org.uk" target=3D"_blank">carlber= g@g11.org.uk</a>; <a href=3D"mailto:anuragb@cisco.com" target=3D"_blank">anuragb@cisco.com</a= >; <a href=3D"mailto:tsvwg@ietf.org" target=3D"_blank"> tsvwg@ietf.org</a>; EARDLEY, Phil<br> <b>Onderwerp:</b> Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br> <br> Georgios,<br> <br> I shall post my full review of this draft in the next few days (needs <br> typing up - currently scribbled on a paper copy). This email is <br> solely in response to your answer about on-path vs off-path policy.<br> <br> At 18:55 04/11/2012, <a href=3D"mailto:karagian@cs.utwente.nl" target=3D"_b= lank">karagian@cs.utwente.nl</a> wrote:<br> >So in this case an additional signaling protocol will be<br> >needed to be specified that covers the signaling between the <br> >PCN-egress-node and the centralized node<br> >and between PCN-ingress-node and the centralized node.<br> >In PCN we decdided to only focus on the specification of the <br> >signaling protocol that completes the<br> >feedback loop from PCN-egress-node to PCN-ingress-node and to focus <br= > >on the signaling protocol<br> >used between the edge nodes and the centralized node.<br> <br> When I/we originally designed CL-PCN over RSVP (2005), the idea was <br> that it would fit with the policy-based admission control (PBAC) <br> architecture of RFC2753. In this architecture, an Intserv node at the <br> ingress to a domain is the policy enforcement point (PEP), and it <br> refers to a logically centralised 'policy decision point' (PDP) for <br> decisions on which flows to block/terminate, typically using COPS.<br> <br> To make this doc fit the PBAC framework, all we have to do is:<br> * Describe the PCN-ingress only as the PCN-ingress and not as the <br> decision point (find 'decision' throughout doc and fix).<br> * Add a section saying the PCN-ingress can refer flow admission and <br> termination decisions to a central decision point (using e.g. COPS), <br> which will respond to the PCN-ingress as per RFC2753. (Alternatively <br> the PCN-ingress could itself be the policy decision point.)<br> * Refer to this new PBAC section from Section 3.11 giving the <br> admission decision procedure.<br> <br> * Some people might think this means COPS will need new protocol <br> elements to carry PCN marking rates to the policy decision point. But <br> PCN marking rates are irrelevant to the policy decision: the <br> PCN-ingress just uses PCN to determine whether it needs to block or <br> terminate, and it refers to the policy decision point for which flows <br> to block/terminate.<br> <br> * Unfortunately, neither of the two PCN system descriptions [RFC6661, <br> RFC6662] describe a PBAC-based case. The architecture [RFC5559] <br> refers to the PBAC framework [RFC2753] but unfortunately doesn't <br> spell out how it fits. Originally, I referenced PBAC from RFC5559, <br> but just as the PCN w-g was closing I realised that (some?) others in <br> the PCN w-g were working under the assumption that the only way to <br> talk to a centralised policy node was from the egress, possibly <br> without being aware of the contents of RFC2753.<br> <br> I think it's OK to introduce a new architectural arrangement in this <br> RSVP doc, given RFC2753 is specific to the way RSVP works.<br> <br> <br> Bob<br> <br> <br> <br> At 12:28 05/11/2012, <a href=3D"mailto:karagian@cs.utwente.nl" target=3D"_b= lank">karagian@cs.utwente.nl</a> wrote:<br> >Hi Ken,<br> ><br> >Thank you very much!<br> >We will try to catch Francois and discuss the last (in line) issue with= him!<br> ><br> >Best regards,<br> >Georgios<br> ><br> >________________________________________<br> >Van: ken carlberg [<a href=3D"mailto:carlberg@g11.org.uk" target=3D"_bl= ank">carlberg@g11.org.uk</a>]<br> >Verzonden: maandag 5 november 2012 13:23<br> >To: Karagiannis, G. (EWI)<br> >Cc: <a href=3D"mailto:tsvwg@ietf.org" target=3D"_blank">tsvwg@ietf.org<= /a>; <a href=3D"mailto:anuragb@cisco.com" target=3D"_blank"> anuragb@cisco.com</a><br> >Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03<br> ><br> >Georgios,<br> ><br> > > Georgios: We will try to explain the rationale of why we consider= <br> > that RSVP can only be used for the situation that the<br> > > decision point is collocated with the PCN-ingress-node. The main = <br> > reason of this is that in the case that the<br> > > decision point is collocated with the PCN-ingress-node,the <br> > required signaling protocol used to complete a<br> > > feedback loop from egress to ingress can be an entirely on-path <= br> > protocol, like what RSVP is.<br> > > In the situation that the the decision point is a centralized <br= > > node, then the required signaling protocol<br> > > can be a combination of an on-path and off-path protocol. This is= <br> > because the<br> > > decision point might not be located on the data path! So in this = <br> > case an additional signaling protocol will be<br> > > needed to be specified that covers the signaling between the <br> > PCN-egress-node and the centralized node<br> > > and between PCN-ingress-node and the centralized node.<br> > > In PCN we decdided to only focus on the specification of the <br> > signaling protocol that completes the<br> > > feedback loop from PCN-egress-node to PCN-ingress-node and to <br= > > focus on the signaling protocol<br> > > used between the edge nodes and the centralized node.<br> > > This is also the reason of why PCN WG decided to only focus on <b= r> > the situation that the decision point is<br> > > collocated with the PCN-ingress-node.<br> ><br> >Great, this is helpful, and this is the information that needs to be <b= r> >in the draft.<br> ><br> > >> 6) This comment is just for you to contemplate -- I'm not <br= > > expecting any changes.<br> > >> I noticed that you have a fair number of SHOULD, and some SHO= ULD NOTs.<br> > >> And it seems a lot of this is a carry over from rfc-4860, so = in <br> > a sense you are inheriting an approach that<br> > >> was agreed to from an earlier effort.  But I wonder in t= he back <br> > of my mind, what impact occurs if<br> > >> an implementor doesn't follow the SHOULD?  Does the desi= gn break <br> > in supporting PCN?<br> > >> Again, I want to stress that this isnt a show stopper, but I = <br> > would appreciate it if you gave it some thought.<br> > ><br> > > Georgios: Yes, in several cases the design might break in support= ing PCN.<br> > > This is also the reason of using SHOULD instead of MAY. Do you <b= r> > want us to explain this in more detail in the draft?<br> ><br> >well, actually, I was more curious as to why a number of these cases <b= r> >are SHOULD instead of MUST.  Again, the SHOULD's in your document = <br> >seem to be a carry-over from rfc-4860 (which set the precedent), so <br= > >its a bit unfair for you to explain what was done in an earlier <br> >effort.  I just wanted to make sure you gave some thought to the <= br> >subject.  And if things will break if SHOULD is not followed by an= <br> >implementer/configuration, then maybe you should be more stringent <br> >and change things to MUST.  Perhaps a brief private conversation <= br> >with Francois Le Faucheur will be helpful.<br> ><br> >cheers,<br> ><br> >-ken<br> <br> ________________________________________________________________<br> Bob Briscoe,          &nb= sp;            =          BT Innovate & Design <= br> <br> ________________________________________________________________<br> Bob Briscoe,          &nb= sp;            =          BT Innovate & Design</= blockquote> <p>________________________________________________________________<br> Bob Briscoe,          &nb= sp;            =          BT Innovate & Design <= /p> </div> </div> </body> </html> --_000_38323AE1362C4DBF87A02D468586CC53mimectl_-- From bob.briscoe@bt.com Fri Nov 16 12:03:22 2012 Return-Path: <bob.briscoe@bt.com> 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 32D9A21F8A67 for <tsvwg@ietfa.amsl.com>; Fri, 16 Nov 2012 12:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQ-E55PikkqL for <tsvwg@ietfa.amsl.com>; Fri, 16 Nov 2012 12:03:21 -0800 (PST) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6C021F84CE for <tsvwg@ietf.org>; Fri, 16 Nov 2012 12:03:21 -0800 (PST) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 16 Nov 2012 20:03:15 +0000 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 16 Nov 2012 20:03:17 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.309.2; Fri, 16 Nov 2012 20:03:16 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1353096194692; Fri, 16 Nov 2012 20:03:14 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qAGK3C3s014269; Fri, 16 Nov 2012 20:03:12 GMT Message-ID: <201211162003.qAGK3C3s014269@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 16 Nov 2012 20:03:11 +0000 To: Tom Taylor <tom.taylor.stds@gmail.com> From: Bob Briscoe <bob.briscoe@bt.com> In-Reply-To: <50A56804.3090208@gmail.com> References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <E728D0E3C41E644A96A7CCA61863BED4081DE009@xmb-aln-x12.cisco.com> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> <FF1A9612A94D5C4A81ED7DE1039AB80F2ED8FEDF@EXMBX04.ad.utwente.nl> <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> <50A51B8C.4010806@gmail.com> <201211152102.qAFL2BWE010641@bagheera.jungle.bt.co.uk> <50A56804.3090208@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: PCN IETF list <pcn@ietf.org>, anuragb@cisco.com, tsvwg@ietf.org, rsvp-dir@ietfa.amsl.com Subject: Re: [tsvwg] [PCN] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 16 Nov 2012 20:03:22 -0000 Tom, The edge behaviour RFCs attempted to abstract over any signalling protcol, but I think they ended up being biased towards the ITU way of doing things, rather than an abstraction that encompassed both RACF and RSVP, which was probably too ambitious. Is you piggy-backing draft effectively what I am describing - piggy-backing on e2e signalling? I don't believe we need any more abstract drafts if that's what you mean - we need to focus on RSVP specifically now. We could perhaps re-boot from Francois's original draft. Bob At 22:09 15/11/2012, Tom Taylor wrote: >OK, I guess I see your point. I was too focussed on the calculations >that are done at the Decision Point. > >It makes me wonder if I should revive that piggy-backing edge >behaviour draft I once started. > >On 15/11/2012 4:02 PM, Bob Briscoe wrote: >>Tom, >> >>The RSVP message I'm proposing doesn't say "Never mind the SESSION in >>this message, I'm related to every flow with the same first hop". It >>says "These are the marking probabilities for the SESSION in this >>message". Then the PCN-ingress (not the message) infers that all other >>flows that share the same aggregate will share the same marking >>probability, because PCN marking on interior nodes is random and unbiased. >> >>It's a subtle distinction, but it preserves the semantics of RSVP >>messages, without the three disadvantages of setting up an RSVP >>aggregate that I mentioned. >> >>You will have seen from the rest of the message that I have not rejected >>the concept of aggregation, I am merely saying that the PCN-ingress and >>PCN-egress can hold the concept internally. >> >> >>Bob >> >>At 16:42 15/11/2012, Tom Taylor wrote: >>>I'm not sure the semantics of the PCN information -- particularly as >>>it relates to flow termination -- are correct without some sort of >>>concept of aggregation. Or can you really define an RSVP object that >>>has semantics "Never mind the SESSION in this message, I'm related to >>>every flow with the same first hop"? >... ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Fri Nov 16 12:14:50 2012 Return-Path: <bob.briscoe@bt.com> 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 0A19121F86DB for <tsvwg@ietfa.amsl.com>; Fri, 16 Nov 2012 12:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yp5E0G1KU-mP for <tsvwg@ietfa.amsl.com>; Fri, 16 Nov 2012 12:14:47 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4B521F85DF for <tsvwg@ietf.org>; Fri, 16 Nov 2012 12:14:46 -0800 (PST) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 16 Nov 2012 20:14:44 +0000 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 16 Nov 2012 20:14:41 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.309.2; Fri, 16 Nov 2012 20:14:39 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1353096877994; Fri, 16 Nov 2012 20:14:37 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qAGKEYxK014300; Fri, 16 Nov 2012 20:14:34 GMT Message-ID: <201211162014.qAGKEYxK014300@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 16 Nov 2012 20:14:33 +0000 To: <karagian@cs.utwente.nl> From: Bob Briscoe <bob.briscoe@bt.com> In-Reply-To: <38323AE1-362C-4DBF-87A0-2D468586CC53@mimectl> References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <E728D0E3C41E644A96A7CCA61863BED4081DE009@xmb-aln-x12.cisco.com> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> <FF1A9612A94D5C4A81ED7DE1039AB80F2ED8FEDF@EXMBX04.ad.utwente.nl> <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> <38323AE1-362C-4DBF-87A0-2D468586CC53@mimectl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_774171199==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, slblake@petri-meat.com, philip.eardley@bt.com, anuragb@cisco.com, sob@harvard.edu, rsvp-dir@ietfa.amsl.com, pcn@ietf.org, jmpolk@cisco.com Subject: Re: [tsvwg] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 16 Nov 2012 20:14:50 -0000 --=====================_774171199==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Georgios, Yes, I apologise for not reviewing earlier. I appreciate you followed the procedure. My problem was that a quick read of tsvwg-rsvp-pcn wasn't enough to understand it. So I stayed quiet even though I wasn't so happy about the direction, because I didn't have enough understanding to feel I could argue. Only in the last week or so, I collected together all the references and re-read them and their references, and made a concerted effort to understand what your draft was proposing. I have to say, it was quite a struggle (over a few days and the write-up took 2 days). However, I admit that it would have been preferable for everyone if I had made this effort earlier. Bob At 13:02 16/11/2012, karagian@cs.utwente.nl wrote: >Hi Bob, > >$B!!(B > >Thanks for your comments! > >Regarding your statement: What I meant in my previous email is that >our individual draft that was used as a working basis for this WG >draft was already using the generic aggregation RSVP (RFC 4860) as >the existing signaling protocol, see: > > > ><http://tools.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt>http://tools.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt > > > >Moreover, during IETF 81, this individual draft has been presneted, >where also the rationale of using (RFC 4860) was also the following >slides see presentation slides (slide 5): > > > >http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf > >$B!!(B > >In particular in slide 4 mentions: > >"All PCN charter items are fulfilled, except: > >Submit Encoding and Transport of PCN from Domain Egress to Ingress >to the IESG for consideration as a Proposed Standard RFC > >Pairs of PCN edge nodes use ingress-egress-aggregates (IEA): > >Need a signaling protocol to transport PCN information from >PCN-egress-node to PCN-ingress-node and to maintain >ingress-egress-aggregate between each pair of PCN edge nodes" > >Furthermore Slide 5 mentions: > >$B!!(B > >"IETF QoS signaling protocols to solve problem: > >Next Steps in Signaling Protocol (NSIS) subset (RFC 5971, RFC 5974, RFC 5979) > >Aggregation of RSVP for IPv4 and IPv6 Reservations (RFC3175) > >Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations (RFC4860) > >All can be used, but for time being selected RFC 4860 due: > >possible deployment interest > >supports RFC 3175 and additional features such as: > >support of multiple IEAs from same pair of PCN edge nodes > >support of bandwidth reduction for individual flows (RFC 4495)" > >$B!!(B > >Before IETF 81 and during IETF 81 this point has been discussed. > >The outcome of these discussions is that short after IETF 81, the >individual draft (draft-karagiannis-pcn-tsvwg-rsvp-pcn-01) > >become (after small modifications) the draft-ietf-tsvwg-rsvp-pcn-00, >which also was using RFC 4860 as the base signaling protocol. > >$B!!(B > >It will be very helpful if the PCN WG chairs (Scott and/or Steve) >and the tsvwg WG chairs (Gorry and/or James) could confirm the above statement! > >$B!!(B > >So both the PCN WG and tsvwg WG agreed that this specifictaion >should use as basis the generic RSVP aggregation protocol! > >$B!!(B > >$B!!(B > >$B!!(B > >In a subsequent email and on a later moment I will also answer to >your further remarks! > >$B!!(B > >Best regards, > >Georgios > >---------- >Van: Bob Briscoe [bob.briscoe@bt.com] >Verzonden: donderdag 15 november 2012 14:07 >To: Karagiannis, G. (EWI); anuragb@cisco.com >Cc: carlberg@g11.org.uk; anuragb@cisco.com; tsvwg@ietf.org; >philip.eardley@bt.com; PCN IETF list; rsvp-dir@ietfa.amsl.com >Onderwerp: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 > >Georgios, Anurag, > >Below is the main point of my review, arguing that aggregate >reservations are redundant. I'm reviewing as: >- a member of the RSVP directorate >- one of the early PCN design team >- a co-author of draft-lefaucheur-rsvp-ecn-01, on which this draft is based. > >I would have missed any decision to use aggregate reservations. Pls >point me to the relevant discussion (e.g. Subject line / date). > >I admit I tuned out of much of the later PCN signalling discussion. >I found the whole exercise of abstracting PCN away from specific >signalling protocols highly tedious; it meant we couldn't sensibly >address important issues like message reliability, timeliness etc. > >Nonetheless, here's why I believe RSVP aggregation is redundant: > >PCN edge-nodes support the concept of an ingress-egress aggregate in >their own internal tables, but they don't need to refer to an >aggregate on the wire{Note 1}. PCN-ingress and PCN-egress nodes >intrinscially know which e2e reservations belong to which aggregate >by grouping together those e2e reservations with the same next hop >or previous hop respectively. > >{Note 1: except in one case described later - but it doesn't require >all the other baggage of aggregate reservations} > >==Background== >Aggregate reservations [RFC3175, RFC4860] are designed to reduce the >state required on interior nodes. Interior nodes still require state >per aggregate reservation, but only reservation state, not >classification and scheduling state [RFC3175, Section 1.4.1 last para]. > >In contrast, as you correctly point out (in Section 2.1.7), PCN >requires absolutely no reservation-related state on interior nodes. > >==Disadvantages== >Requiring PCN to use aggregate reservations has the following three >disadvantages and no advantages: > >1) Redundant Processing >The PATH message between aggregator and deaggregator in rsvp-pcn-03 >(triggered by an E2E PathErr message from deaggregator to >aggregator) is redundant, and just doubles the processing required >at the PCN-edge-nodes (if this isn't obvious, I spell it out >separately for PATH & RESV messages below). > >2) Reduced Resilience >Not only is an aggregate PATH redundant, it actually reduces >resilience. Because an aggregate PATH is pinned to interior routers. >Therefore, when routing changes, it is more complex and slower to >move to the new route. By not pinning to interior routers, PCN was >designed to 'just work' over interior routing changes - with no need >for any changes to the RSVP PATHs. (But it would still detect >overload after a re-route and terminate or rate-reduce flows if necessary.) > >3) Extra Latency >A further disadvantage is the extra latency required for the first >reservation that sets up an aggregate. This is two ingress-egress >round trips minus the round trip time from egress to destination (or >one ingress-egress round trip if it is greater). This will rarely >add to latency on heavily used ingress-egress aggregates, but it >will occur frequently on all the 'long-tail' (lightly used) >ingress-egress aggregates. > >==PATH== > >With RFC 3175 or 4860 aggregate paths, the aggregator forwards the >e2e PATH messages with IP protocol number RSVP-E2E-IGNORE and the >deaggregator changes them back to RSVP before forwarding onward. >Also the aggregator sends an aggregate PATH message, which is >processed by each interior node and by the deaggregator. > >On a path across a PCN region, given interior nodes ignore aggregate >PATH messages as well, the only PCN nodes that handle aggregate >messages are the aggregator and the deaggregator. The aggregator and >deaggregator process all the e2e PATH messages anyway, so if we >require the aggregator to add up all the e2e PATH messages and form >them into an aggregate PATH message, this is just extra redundant >work for both PCN-edge-nodes. > >==RESV== > >The deaggregator unicasts e2e RESV messages to the previous RSVP >hop, which is the aggregator. Therefore, if we require the >deaggregator to add up all the RESV messages and form them into an >aggregate RESV message, this is just redundant work for both >PCN-edge-nodes, because they both already process all the e2e RESV >messages anyway, and no other node uses the aggregate RESV messages. > >==PCN object== > >This raises the question of how the PCN-egress communicates the >various marking rates (the PCN object) to the PCN-ingress. There are >two possibilities: >i) the PCN-egress includes a current PCN object in each e2e RESV >that it returns to the PCN-ingress. The PCN-ingress strips the PCN >object out before forwarding the RESV back to the previous RSVP hop. >ii) the PCN-egress attaches a PCN object to an aggregate >reservation, as in pcn-rsvp-03. > >Either are possible, because a PCN object carries information about >marking probabilities, and PCN works on the assumption that the >marking probability of an ingress-egress aggregate is the same as >the marking probability of the flows within the aggregate. A PCN >object can be contained either in an e2e RESV or an aggregate RESV >as long as the PCN-ingress can associate an e2e RESV with the >correct aggregate (which it can, because it maintains an internal >table of mappings between e2e reservations and their aggregates). > >Which of the two is best is a question of message timing... > >* For e2e admission decisions, the PCN object is only needed at the >time each e2e RESV is sent, so option i) makes sense. > >* For flow rate reduction or flow termination decisions, the >deaggregator needs to regularly send PCN objects to the ingress. > >The PCN-egress is sending regular e2e RESV refresh messages to the >PCN-ingress, so a PCN object can be included in each of these. To >ensure that PCN objects are sent often enough, I suggest the >PCN-egress also maintains a timer per ingress-egress aggregate which >it resets every time it sends a PCN object for that IEA. If the >timer expires, the PCN-egress sends a PCN object to the PCN-egress >even thought it was not triggered by an e2e RESV refresh. We could >require the SESSION object in this message to refer to either of: >a) any one of the e2e SESSIONs in the aggregate, >b) the aggregate. > >In case (a), the message would need to somehow tell the ingress not >to forward this RESV refresh to the RSVP previous hop. > >In case (b) in the PCN-ingress table of mappings between e2e >SESSIONs and aggregate SESSIONs, it would include an entry for the >aggregate that maps to itself. If the result of the look-up is the >same as the input, it knows not to forward the RESV refresh further. > >The wire protocol doesn't need to identify whether the SESSION is an >aggregate or not. This is the one case I mentioned at the start >{Note 1} where an aggregate is referred to on the wire. > > > >In summary, PCN already reduces reservation state and processing to >nothing on interior nodes. Adding aggregate reservations to PCN >requires more processing and state, it unnecessarily pins routes to >interior nodes and adds unnecessary latency. > > >Bob > >At 18:23 14/11/2012, karagian@cs.utwente.nl wrote: >>Hi Bob, >> >>Regarding the generic aggregated RSVP selection, actually the PCN >>WG agreed with this selection! >>This was actually the first step that was needed for this work, and >>the PCN WG had no main objections on this selection! >> >>So I do not understand your remark that your comment will have >>major implications! >> >>Please note that the generic aggregated RSVP is selected since the >>PCN IEA are associated with flows that are aggregated at the edges. >>So a signalling protocol that supports aggregation of flows at the >>edges is very suitable for this purpose! The generic aggregated >>RSVP is such a signalling protocol! >> >> >>Best regards, >>Georgios >> >> >> >> >>From: Bob Briscoe [<mailto:bob.briscoe@bt.com>mailto:bob.briscoe@bt.com] >>Sent: woensdag 14 november 2012 12:57 >>To: Anurag Bhargava (anuragb) >>Cc: Karagiannis, G. (EWI) >>Subject: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 >> >>Anurag, >> >>I have my comments half-written up. I will try to finish them by >>the end of today. >> >>They should be orthogonal to the PBAC comment below, so if you >>wanted to start altering that area, I don't think it would waste >>too much time. >> >>However, my main comments will concern the use of aggregated >>reservations (as I said at the mic), so that could have major implications. >> >> >>Bob >> >>At 20:14 13/11/2012, Anurag Bhargava (anuragb) wrote: >> >>Hi Bob, >> Thanks for the comments. If U have some text that will be great >> els I have also started putting some text on the topic U brought up. >> May be we can conference after US thanksgiving week and >> collaborate the text and try to move forward. >> >> Please let us know what might be a good time and I can schedule a >> Webex conf. >> >>Thx >>-Anurag >> >>From: "<mailto:karagian@cs.utwente.nl>karagian@cs.utwente.nl " >><<mailto:karagian@cs.utwente.nl>karagian@cs.utwente.nl > >>Date: Saturday, November 10, 2012 8:10 AM >>To: "<mailto:bob.briscoe@bt.com>bob.briscoe@bt.com" >><<mailto:bob.briscoe@bt.com>bob.briscoe@bt.com> >>Cc: "<mailto:carlberg@g11.org.uk>carlberg@g11.org.uk" >><<mailto:carlberg@g11.org.uk>carlberg@g11.org.uk>, Anurag Bhargava >><<mailto:anuragb@cisco.com>anuragb@cisco.com>, >>"<mailto:tsvwg@ietf.org>tsvwg@ietf.org" >><<mailto:tsvwg@ietf.org>tsvwg@ietf.org>, >>"<mailto:philip.eardley@bt.com>philip.eardley@bt.com " >><<mailto:philip.eardley@bt.com>philip.eardley@bt.com > >>Subject: RE: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 >> >>Hi Bob, >> >> >> >>Thanks very much for the comments! I think that they are very useful! >> >> >> >>It will be very beneficiary for the fast progress of this draft if >>you would like to contribute as a co-author to this draft and write >>this additional section that describes "that the PCN-ingress can >>refer flow admission and >>termination decisions to a central decision point (using e.g. >>COPS), which will respond to the PCN-ingress as per RFC2753. >>(Alternatively the PCN-ingress could itself be the policy decision point.)" >> >> >> >>Best regards, >> >>Georgios >> >> >> >>---------- >>Van: Bob Briscoe [<mailto:bob.briscoe@bt.com>bob.briscoe@bt.com] >>Verzonden: vrijdag 9 november 2012 16:33 >>To: Karagiannis, G. (EWI) >>Cc: <mailto:carlberg@g11.org.uk>carlberg@g11.org.uk; >><mailto:anuragb@cisco.com>anuragb@cisco.com; >><mailto:tsvwg@ietf.org>tsvwg@ietf.org; EARDLEY, Phil >>Onderwerp: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 >> >>Georgios, >> >>I shall post my full review of this draft in the next few days (needs >>typing up - currently scribbled on a paper copy). This email is >>solely in response to your answer about on-path vs off-path policy. >> >>At 18:55 04/11/2012, >><mailto:karagian@cs.utwente.nl>karagian@cs.utwente.nl wrote: >> >So in this case an additional signaling protocol will be >> >needed to be specified that covers the signaling between the >> >PCN-egress-node and the centralized node >> >and between PCN-ingress-node and the centralized node. >> >In PCN we decdided to only focus on the specification of the >> >signaling protocol that completes the >> >feedback loop from PCN-egress-node to PCN-ingress-node and to focus >> >on the signaling protocol >> >used between the edge nodes and the centralized node. >> >>When I/we originally designed CL-PCN over RSVP (2005), the idea was >>that it would fit with the policy-based admission control (PBAC) >>architecture of RFC2753. In this architecture, an Intserv node at the >>ingress to a domain is the policy enforcement point (PEP), and it >>refers to a logically centralised 'policy decision point' (PDP) for >>decisions on which flows to block/terminate, typically using COPS. >> >>To make this doc fit the PBAC framework, all we have to do is: >>* Describe the PCN-ingress only as the PCN-ingress and not as the >>decision point (find 'decision' throughout doc and fix). >>* Add a section saying the PCN-ingress can refer flow admission and >>termination decisions to a central decision point (using e.g. COPS), >>which will respond to the PCN-ingress as per RFC2753. (Alternatively >>the PCN-ingress could itself be the policy decision point.) >>* Refer to this new PBAC section from Section 3.11 giving the >>admission decision procedure. >> >>* Some people might think this means COPS will need new protocol >>elements to carry PCN marking rates to the policy decision point. But >>PCN marking rates are irrelevant to the policy decision: the >>PCN-ingress just uses PCN to determine whether it needs to block or >>terminate, and it refers to the policy decision point for which flows >>to block/terminate. >> >>* Unfortunately, neither of the two PCN system descriptions [RFC6661, >>RFC6662] describe a PBAC-based case. The architecture [RFC5559] >>refers to the PBAC framework [RFC2753] but unfortunately doesn't >>spell out how it fits. Originally, I referenced PBAC from RFC5559, >>but just as the PCN w-g was closing I realised that (some?) others in >>the PCN w-g were working under the assumption that the only way to >>talk to a centralised policy node was from the egress, possibly >>without being aware of the contents of RFC2753. >> >>I think it's OK to introduce a new architectural arrangement in this >>RSVP doc, given RFC2753 is specific to the way RSVP works. >> >> >>Bob >> >> >> >>At 12:28 05/11/2012, >><mailto:karagian@cs.utwente.nl>karagian@cs.utwente.nl wrote: >> >Hi Ken, >> > >> >Thank you very much! >> >We will try to catch Francois and discuss the last (in line) >> issue with him! >> > >> >Best regards, >> >Georgios >> > >> >________________________________________ >> >Van: ken carlberg [<mailto:carlberg@g11.org.uk>carlberg@g11.org.uk] >> >Verzonden: maandag 5 november 2012 13:23 >> >To: Karagiannis, G. (EWI) >> >Cc: <mailto:tsvwg@ietf.org>tsvwg@ietf.org; >> <mailto:anuragb@cisco.com>anuragb@cisco.com >> >Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03 >> > >> >Georgios, >> > >> > > Georgios: We will try to explain the rationale of why we consider >> > that RSVP can only be used for the situation that the >> > > decision point is collocated with the PCN-ingress-node. The main >> > reason of this is that in the case that the >> > > decision point is collocated with the PCN-ingress-node,the >> > required signaling protocol used to complete a >> > > feedback loop from egress to ingress can be an entirely on-path >> > protocol, like what RSVP is. >> > > In the situation that the the decision point is a centralized >> > node, then the required signaling protocol >> > > can be a combination of an on-path and off-path protocol. This is >> > because the >> > > decision point might not be located on the data path! So in this >> > case an additional signaling protocol will be >> > > needed to be specified that covers the signaling between the >> > PCN-egress-node and the centralized node >> > > and between PCN-ingress-node and the centralized node. >> > > In PCN we decdided to only focus on the specification of the >> > signaling protocol that completes the >> > > feedback loop from PCN-egress-node to PCN-ingress-node and to >> > focus on the signaling protocol >> > > used between the edge nodes and the centralized node. >> > > This is also the reason of why PCN WG decided to only focus on >> > the situation that the decision point is >> > > collocated with the PCN-ingress-node. >> > >> >Great, this is helpful, and this is the information that needs to be >> >in the draft. >> > >> > >> 6) This comment is just for you to contemplate -- I'm not >> > expecting any changes. >> > >> I noticed that you have a fair number of SHOULD, and some SHOULD NOTs. >> > >> And it seems a lot of this is a carry over from rfc-4860, so in >> > a sense you are inheriting an approach that >> > >> was agreed to from an earlier effort. But I wonder in the back >> > of my mind, what impact occurs if >> > >> an implementor doesn't follow the SHOULD? Does the design break >> > in supporting PCN? >> > >> Again, I want to stress that this isnt a show stopper, but I >> > would appreciate it if you gave it some thought. >> > > >> > > Georgios: Yes, in several cases the design might break in >> supporting PCN. >> > > This is also the reason of using SHOULD instead of MAY. Do you >> > want us to explain this in more detail in the draft? >> > >> >well, actually, I was more curious as to why a number of these cases >> >are SHOULD instead of MUST. Again, the SHOULD's in your document >> >seem to be a carry-over from rfc-4860 (which set the precedent), so >> >its a bit unfair for you to explain what was done in an earlier >> >effort. I just wanted to make sure you gave some thought to the >> >subject. And if things will break if SHOULD is not followed by an >> >implementer/configuration, then maybe you should be more stringent >> >and change things to MUST. Perhaps a brief private conversation >> >with Francois Le Faucheur will be helpful. >> > >> >cheers, >> > >> >-ken >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_774171199==.ALT Content-Type: text/html; charset="us-ascii" <html> <body> Georgios,<br><br> Yes, I apologise for not reviewing earlier. I appreciate you followed the procedure.<br><br> My problem was that a quick read of tsvwg-rsvp-pcn wasn't enough to understand it. So I stayed quiet even though I wasn't so happy about the direction, because I didn't have enough understanding to feel I could argue.<br><br> Only in the last week or so, I collected together all the references and re-read them and their references, and made a concerted effort to understand what your draft was proposing. I have to say, it was quite a struggle (over a few days and the write-up took 2 days). <br><br> However, I admit that it would have been preferable for everyone if I had made this effort earlier.<br><br> <br> Bob<br><br> At 13:02 16/11/2012, karagian@cs.utwente.nl wrote:<br><br> <blockquote type=cite class=cite cite="">Hi Bob,<br><br> $B!!(B<br><br> Thanks for your comments!<br><br> Regarding your statement: What I meant in my previous email is that our individual draft that was used as a working basis for this WG draft  was already using the generic aggregation RSVP (RFC 4860) as the existing signaling protocol, see:<br><br>  <br><br> <a href="http://tools.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt"> http://tools.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt</a> <br><br>  <br><br> Moreover, during IETF 81, this individual draft has been presneted, where also the rationale of using (RFC 4860) was also the following slides see presentation slides (slide 5):<br><br>  <br><br> <a href="http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf" eudora="autourl"> http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf</a><br><br> $B!!(B<br><br> In particular in slide 4 mentions:<br><br> "All PCN charter items are fulfilled, except:<br><br> Submit Encoding and Transport of PCN from Domain Egress to Ingress to the IESG for consideration as a Proposed Standard RFC<br><br> Pairs of PCN edge nodes use ingress-egress-aggregates (IEA):<br><br> Need a signaling protocol to transport PCN information from PCN-egress-node to PCN-ingress-node and to maintain ingress-egress-aggregate between each pair of PCN edge nodes"<br><br> Furthermore Slide 5 mentions:<br><br> $B!!(B<br><br> "IETF QoS signaling protocols to solve problem:<br><br> Next Steps in Signaling Protocol (NSIS) subset (RFC 5971, RFC 5974, RFC 5979)<br><br> Aggregation of RSVP for IPv4 and IPv6 Reservations (RFC3175)<br><br> Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations (RFC4860)<br><br> All can be used, but for time being selected RFC 4860 due:<br><br> possible deployment interest<br><br> supports RFC 3175 and additional features such as: <br><br> support of multiple IEAs from same pair of PCN edge nodes <br><br> support of bandwidth reduction for individual flows (RFC 4495)"<br><br> $B!!(B<br><br> Before IETF 81 and during IETF 81 this point has been discussed.<br><br> The outcome of these discussions is that short after IETF 81, the individual draft (draft-karagiannis-pcn-tsvwg-rsvp-pcn-01) <br><br> become (after small modifications) the draft-ietf-tsvwg-rsvp-pcn-00, which also was using RFC 4860 as the base signaling protocol.<br><br> $B!!(B<br><br> It will be very helpful if the PCN WG chairs (Scott and/or Steve) and the tsvwg WG chairs (Gorry and/or James) could confirm the above statement!<br><br> $B!!(B<br><br> So both the PCN WG and tsvwg WG agreed that this specifictaion should use as basis the generic RSVP aggregation protocol!<br><br> $B!!(B<br><br> $B!!(B<br><br> $B!!(B<br><br> In a subsequent email and on a later moment I will also answer to your further remarks!<br><br> $B!!(B<br><br> Best regards,<br><br> Georgios<br> <hr> <font face="Tahoma" size=2><b>Van:</b> Bob Briscoe [bob.briscoe@bt.com]<br> <b>Verzonden:</b> donderdag 15 november 2012 14:07<br> <b>To:</b> Karagiannis, G. (EWI); anuragb@cisco.com<br> <b>Cc:</b> carlberg@g11.org.uk; anuragb@cisco.com; tsvwg@ietf.org; philip.eardley@bt.com; PCN IETF list; rsvp-dir@ietfa.amsl.com<br> <b>Onderwerp:</b> Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03<br> </font><br> Georgios, Anurag,<br><br> Below is the main point of my review, arguing that aggregate reservations are redundant. I'm reviewing as:<br> - a member of the RSVP directorate<br> - one of the early PCN design team<br> - a co-author of draft-lefaucheur-rsvp-ecn-01, on which this draft is based.<br><br> I would have missed any decision to use aggregate reservations. Pls point me to the relevant discussion (e.g. Subject line / date).<br><br> I admit I tuned out of much of the later PCN signalling discussion. I found the whole exercise of abstracting PCN away from specific signalling protocols highly tedious; it meant we couldn't sensibly address important issues like message reliability, timeliness etc. <br><br> Nonetheless, here's why I believe RSVP aggregation is redundant:<br><br> PCN edge-nodes support the concept of an ingress-egress aggregate in their own internal tables, but they don't need to refer to an aggregate on the wire{Note 1}. PCN-ingress and PCN-egress nodes intrinscially know which e2e reservations belong to which aggregate by grouping together those e2e reservations with the same next hop or previous hop respectively.<br><br> {Note 1: except in one case described later - but it doesn't require all the other baggage of aggregate reservations}<br><br> ==Background==<br> Aggregate reservations [RFC3175, RFC4860] are designed to reduce the state required on interior nodes. Interior nodes still require state per aggregate reservation, but only reservation state, not classification and scheduling state [RFC3175, Section 1.4.1 last para].<br><br> In contrast, as you correctly point out (in Section 2.1.7), PCN requires absolutely no reservation-related state on interior nodes.<br><br> ==Disadvantages==<br> Requiring PCN to use aggregate reservations has the following three disadvantages and no advantages:<br><br> 1) Redundant Processing<br> The PATH message between aggregator and deaggregator in rsvp-pcn-03 (triggered by an E2E PathErr message from deaggregator to aggregator) is redundant, and just doubles the processing required at the PCN-edge-nodes (if this isn't obvious, I spell it out separately for PATH & RESV messages below). <br><br> 2) Reduced Resilience<br> Not only is an aggregate PATH redundant, it actually reduces resilience. Because an aggregate PATH is pinned to interior routers. Therefore, when routing changes, it is more complex and slower to move to the new route. By not pinning to interior routers, PCN was designed to 'just work' over interior routing changes - with no need for any changes to the RSVP PATHs. (But it would still detect overload after a re-route and terminate or rate-reduce flows if necessary.)<br><br> 3) Extra Latency<br> A further disadvantage is the extra latency required for the first reservation that sets up an aggregate. This is two ingress-egress round trips minus the round trip time from egress to destination (or one ingress-egress round trip if it is greater). This will rarely add to latency on heavily used ingress-egress aggregates, but it will occur frequently on all the 'long-tail' (lightly used) ingress-egress aggregates.<br><br> ==PATH==<br><br> With RFC 3175 or 4860 aggregate paths, the aggregator forwards the e2e PATH messages with IP protocol number RSVP-E2E-IGNORE and the deaggregator changes them back to RSVP before forwarding onward. Also the aggregator sends an aggregate PATH message, which is processed by each interior node and by the deaggregator.<br><br> On a path across a PCN region, given interior nodes ignore aggregate PATH messages as well, the only PCN nodes that handle aggregate messages are the aggregator and the deaggregator. The aggregator and deaggregator process all the e2e PATH messages anyway, so if we require the aggregator to add up all the e2e PATH messages and form them into an aggregate PATH message, this is just extra redundant work for both PCN-edge-nodes.<br><br> ==RESV==<br><br> The deaggregator unicasts e2e RESV messages to the previous RSVP hop, which is the aggregator. Therefore, if we require the deaggregator to add up all the RESV messages and form them into an aggregate RESV message, this is just redundant work for both PCN-edge-nodes, because they both already process all the e2e RESV messages anyway, and no other node uses the aggregate RESV messages.<br><br> ==PCN object==<br><br> This raises the question of how the PCN-egress communicates the various marking rates (the PCN object) to the PCN-ingress. There are two possibilities:<br> i) the PCN-egress includes a current PCN object in each e2e RESV that it returns to the PCN-ingress. The PCN-ingress strips the PCN object out before forwarding the RESV back to the previous RSVP hop.<br> ii) the PCN-egress attaches a PCN object to an aggregate reservation, as in pcn-rsvp-03.<br><br> Either are possible, because a PCN object carries information about marking probabilities, and PCN works on the assumption that the marking probability of an ingress-egress aggregate is the same as the marking probability of the flows within the aggregate. A PCN object can be contained either in an e2e RESV or an aggregate RESV as long as the PCN-ingress can associate an e2e RESV with the correct aggregate (which it can, because it maintains an internal table of mappings between e2e reservations and their aggregates).<br><br> Which of the two is best is a question of message timing...<br><br> * For e2e admission decisions, the PCN object is only needed at the time each e2e RESV is sent, so option i) makes sense.<br><br> * For flow rate reduction or flow termination decisions, the deaggregator needs to regularly send PCN objects to the ingress. <br><br> The PCN-egress is sending regular e2e RESV refresh messages to the PCN-ingress, so a PCN object can be included in each of these. To ensure that PCN objects are sent often enough, I suggest the PCN-egress also maintains a timer per ingress-egress aggregate which it resets every time it sends a PCN object for that IEA. If the timer expires, the PCN-egress sends a PCN object to the PCN-egress even thought it was not triggered by an e2e RESV refresh. We could require the SESSION object in this message to refer to either of:<br> a) any one of the e2e SESSIONs in the aggregate, <br> b) the aggregate.<br><br> In case (a), the message would need to somehow tell the ingress not to forward this RESV refresh to the RSVP previous hop.<br><br> In case (b) in the PCN-ingress table of mappings between e2e SESSIONs and aggregate SESSIONs, it would include an entry for the aggregate that maps to itself. If the result of the look-up is the same as the input, it knows not to forward the RESV refresh further. <br><br> The wire protocol doesn't need to identify whether the SESSION is an aggregate or not. This is the one case I mentioned at the start {Note 1} where an aggregate is referred to on the wire.<br><br> <br><br> In summary, PCN already reduces reservation state and processing to nothing on interior nodes. Adding aggregate reservations to PCN requires more processing and state, it unnecessarily pins routes to interior nodes and adds unnecessary latency.<br><br> <br> Bob<br><br> At 18:23 14/11/2012, karagian@cs.utwente.nl wrote:<br> <blockquote type=cite class=cite cite="">Hi Bob,<br>  <br> Regarding the generic aggregated RSVP selection, actually the PCN WG agreed with this selection!<br> This was actually the first step that was needed for this work, and the PCN WG had no main objections on this selection!<br>  <br> So I do not understand your remark that your comment will have major implications!<br>  <br> Please note that the generic aggregated RSVP is selected since the PCN IEA are associated with flows that are aggregated at the edges. So a signalling protocol that supports aggregation of flows at the edges is very suitable for this purpose! The generic aggregated RSVP is such a signalling protocol!<br>  <br>  <br> Best regards,<br> Georgios<br>  <br>  <br>  <br>  <br> <b>From:</b> Bob Briscoe [<a href="mailto:bob.briscoe@bt.com">mailto:bob.briscoe@bt.com</a>] <br> <b>Sent:</b> woensdag 14 november 2012 12:57<br> <b>To:</b> Anurag Bhargava (anuragb)<br> <b>Cc:</b> Karagiannis, G. (EWI)<br> <b>Subject:</b> Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br>  <br> Anurag,<br><br> I have my comments half-written up. I will try to finish them by the end of today.<br><br> They should be orthogonal to the PBAC comment below, so if you wanted to start altering that area, I don't think it would waste too much time. <br><br> However, my main comments will concern the use of aggregated reservations (as I said at the mic), so that could have major implications.<br><br> <br> Bob<br><br> At 20:14 13/11/2012, Anurag Bhargava (anuragb) wrote:<br><br> Hi Bob,<br>  Thanks for the comments. If U have some text that will be great els I have also started putting some text on the topic U brought up.<br>  May be we can conference after US thanksgiving week and collaborate the text and try to move forward.<br><br>  Please let us know what might be a good time and I can schedule a Webex conf.<br><br> Thx<br> -Anurag<br><br> From: "<a href="mailto:karagian@cs.utwente.nl">karagian@cs.utwente.nl</a> " <<a href="mailto:karagian@cs.utwente.nl">karagian@cs.utwente.nl</a> ><br> Date: Saturday, November 10, 2012 8:10 AM<br> To: "<a href="mailto:bob.briscoe@bt.com">bob.briscoe@bt.com</a>" <<a href="mailto:bob.briscoe@bt.com">bob.briscoe@bt.com</a>><br> Cc: "<a href="mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>" <<a href="mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>>, Anurag Bhargava <<a href="mailto:anuragb@cisco.com">anuragb@cisco.com</a>>, "<a href="mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>" <<a href="mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>>, "<a href="mailto:philip.eardley@bt.com">philip.eardley@bt.com</a> " <<a href="mailto:philip.eardley@bt.com">philip.eardley@bt.com</a> ><br> Subject: RE: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br><br> Hi Bob,<br><br>  <br><br> Thanks very much for the comments! I think that they are very useful! <br><br>  <br><br> It will be very beneficiary for the fast progress of this draft if you would like to contribute as a co-author to this draft and write this additional section that describes "that the PCN-ingress can refer flow admission and <br> termination decisions to a central decision point (using e.g. COPS), which will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingress could itself be the policy decision point.)"<br><br>  <br><br> Best regards,<br><br> Georgios<br><br>  <br> <hr> <b>Van:</b> Bob Briscoe [<a href="mailto:bob.briscoe@bt.com">bob.briscoe@bt.com</a>]<br> <b>Verzonden:</b> vrijdag 9 november 2012 16:33<br> <b>To:</b> Karagiannis, G. (EWI)<br> <b>Cc:</b> <a href="mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>; <a href="mailto:anuragb@cisco.com">anuragb@cisco.com</a>; <a href="mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>; EARDLEY, Phil<br> <b>Onderwerp:</b> Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br><br> Georgios,<br><br> I shall post my full review of this draft in the next few days (needs <br> typing up - currently scribbled on a paper copy). This email is <br> solely in response to your answer about on-path vs off-path policy.<br><br> At 18:55 04/11/2012, <a href="mailto:karagian@cs.utwente.nl">karagian@cs.utwente.nl</a> wrote:<br> >So in this case an additional signaling protocol will be<br> >needed to be specified that covers the signaling between the <br> >PCN-egress-node and the centralized node<br> >and between PCN-ingress-node and the centralized node.<br> >In PCN we decdided to only focus on the specification of the <br> >signaling protocol that completes the<br> >feedback loop from PCN-egress-node to PCN-ingress-node and to focus <br> >on the signaling protocol<br> >used between the edge nodes and the centralized node.<br><br> When I/we originally designed CL-PCN over RSVP (2005), the idea was <br> that it would fit with the policy-based admission control (PBAC) <br> architecture of RFC2753. In this architecture, an Intserv node at the <br> ingress to a domain is the policy enforcement point (PEP), and it <br> refers to a logically centralised 'policy decision point' (PDP) for <br> decisions on which flows to block/terminate, typically using COPS.<br><br> To make this doc fit the PBAC framework, all we have to do is:<br> * Describe the PCN-ingress only as the PCN-ingress and not as the <br> decision point (find 'decision' throughout doc and fix).<br> * Add a section saying the PCN-ingress can refer flow admission and <br> termination decisions to a central decision point (using e.g. COPS), <br> which will respond to the PCN-ingress as per RFC2753. (Alternatively <br> the PCN-ingress could itself be the policy decision point.)<br> * Refer to this new PBAC section from Section 3.11 giving the <br> admission decision procedure.<br><br> * Some people might think this means COPS will need new protocol <br> elements to carry PCN marking rates to the policy decision point. But <br> PCN marking rates are irrelevant to the policy decision: the <br> PCN-ingress just uses PCN to determine whether it needs to block or <br> terminate, and it refers to the policy decision point for which flows <br> to block/terminate.<br><br> * Unfortunately, neither of the two PCN system descriptions [RFC6661, <br> RFC6662] describe a PBAC-based case. The architecture [RFC5559] <br> refers to the PBAC framework [RFC2753] but unfortunately doesn't <br> spell out how it fits. Originally, I referenced PBAC from RFC5559, <br> but just as the PCN w-g was closing I realised that (some?) others in <br> the PCN w-g were working under the assumption that the only way to <br> talk to a centralised policy node was from the egress, possibly <br> without being aware of the contents of RFC2753.<br><br> I think it's OK to introduce a new architectural arrangement in this <br> RSVP doc, given RFC2753 is specific to the way RSVP works.<br><br> <br> Bob<br><br> <br><br> At 12:28 05/11/2012, <a href="mailto:karagian@cs.utwente.nl">karagian@cs.utwente.nl</a> wrote:<br> >Hi Ken,<br> ><br> >Thank you very much!<br> >We will try to catch Francois and discuss the last (in line) issue with him!<br> ><br> >Best regards,<br> >Georgios<br> ><br> >________________________________________<br> >Van: ken carlberg [<a href="mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>]<br> >Verzonden: maandag 5 november 2012 13:23<br> >To: Karagiannis, G. (EWI)<br> >Cc: <a href="mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>; <a href="mailto:anuragb@cisco.com">anuragb@cisco.com</a><br> >Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03<br> ><br> >Georgios,<br> ><br> > > Georgios: We will try to explain the rationale of why we consider <br> > that RSVP can only be used for the situation that the<br> > > decision point is collocated with the PCN-ingress-node. The main <br> > reason of this is that in the case that the<br> > > decision point is collocated with the PCN-ingress-node,the <br> > required signaling protocol used to complete a<br> > > feedback loop from egress to ingress can be an entirely on-path <br> > protocol, like what RSVP is.<br> > > In the situation that the the decision point is a centralized <br> > node, then the required signaling protocol<br> > > can be a combination of an on-path and off-path protocol. This is <br> > because the<br> > > decision point might not be located on the data path! So in this <br> > case an additional signaling protocol will be<br> > > needed to be specified that covers the signaling between the <br> > PCN-egress-node and the centralized node<br> > > and between PCN-ingress-node and the centralized node.<br> > > In PCN we decdided to only focus on the specification of the <br> > signaling protocol that completes the<br> > > feedback loop from PCN-egress-node to PCN-ingress-node and to <br> > focus on the signaling protocol<br> > > used between the edge nodes and the centralized node.<br> > > This is also the reason of why PCN WG decided to only focus on <br> > the situation that the decision point is<br> > > collocated with the PCN-ingress-node.<br> ><br> >Great, this is helpful, and this is the information that needs to be <br> >in the draft.<br> ><br> > >> 6) This comment is just for you to contemplate -- I'm not <br> > expecting any changes.<br> > >> I noticed that you have a fair number of SHOULD, and some SHOULD NOTs.<br> > >> And it seems a lot of this is a carry over from rfc-4860, so in <br> > a sense you are inheriting an approach that<br> > >> was agreed to from an earlier effort.  But I wonder in the back <br> > of my mind, what impact occurs if<br> > >> an implementor doesn't follow the SHOULD?  Does the design break <br> > in supporting PCN?<br> > >> Again, I want to stress that this isnt a show stopper, but I <br> > would appreciate it if you gave it some thought.<br> > ><br> > > Georgios: Yes, in several cases the design might break in supporting PCN.<br> > > This is also the reason of using SHOULD instead of MAY. Do you <br> > want us to explain this in more detail in the draft?<br> ><br> >well, actually, I was more curious as to why a number of these cases <br> >are SHOULD instead of MUST.  Again, the SHOULD's in your document <br> >seem to be a carry-over from rfc-4860 (which set the precedent), so <br> >its a bit unfair for you to explain what was done in an earlier <br> >effort.  I just wanted to make sure you gave some thought to the <br> >subject.  And if things will break if SHOULD is not followed by an <br> >implementer/configuration, then maybe you should be more stringent <br> >and change things to MUST.  Perhaps a brief private conversation <br> >with Francois Le Faucheur will be helpful.<br> ><br> >cheers,<br> ><br> >-ken<br><br> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design <br><br> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design</blockquote><br> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design </blockquote> <x-sigsep><p></x-sigsep> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design</body> </html> --=====================_774171199==.ALT-- From karagian@cs.utwente.nl Sat Nov 17 02:26:15 2012 Return-Path: <karagian@cs.utwente.nl> 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 2495B21F865E; Sat, 17 Nov 2012 02:26:15 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzTEBxAxcnya; Sat, 17 Nov 2012 02:26:14 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id C3B7F21F8658; Sat, 17 Nov 2012 02:26:12 -0800 (PST) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sat, 17 Nov 2012 11:26:11 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.65]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0318.004; Sat, 17 Nov 2012 11:26:11 +0100 From: <karagian@cs.utwente.nl> To: <bob.briscoe@bt.com>, <tom.taylor.stds@gmail.com> Thread-Topic: [PCN] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 Thread-Index: AQHNxDVtBpScmZOYg0i5rF7MM3or2Zft0D9EgAADRdg= Date: Sat, 17 Nov 2012 10:26:10 +0000 Message-ID: <3AC1435F-846D-44CB-8F60-1E43C572AA0B@mimectl> References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <E728D0E3C41E644A96A7CCA61863BED4081DE009@xmb-aln-x12.cisco.com> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> <FF1A9612A94D5C4A81ED7DE1039AB80F2ED8FEDF@EXMBX04.ad.utwente.nl> <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> <50A51B8C.4010806@gmail.com> <201211152102.qAFL2BWE010641@bagheera.jungle.bt.co.uk> <50A56804.3090208@gmail.com>, <201211162003.qAGK3C3s014269@bagheera.jungle.bt.co.uk> In-Reply-To: <201211162003.qAGK3C3s014269@bagheera.jungle.bt.co.uk> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.91.134.3] Content-Type: multipart/alternative; boundary="_000_3AC1435F846D44CB8F601E43C572AA0Bmimectl_" MIME-Version: 1.0 Cc: pcn@ietf.org, anuragb@cisco.com, tsvwg@ietf.org, rsvp-dir@ietfa.amsl.com Subject: Re: [tsvwg] [PCN] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 17 Nov 2012 10:26:15 -0000 --_000_3AC1435F846D44CB8F601E43C572AA0Bmimectl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bob, Hi Tom, The solution that you are proposing, i.e., use of the e2e RSVP (RFC2205), i= s in my opinion architecturally and conceptually wrong! The reason is the following! In PCN we need a signaling protocol that is able to: (1) to carry informati= on from PCN-egress-edge to PCN-ingress-edge and (2) the carried information= needs to be related to an aggregated state, i.e., the ingress-egress-aggre= gate state. The e2e RSVP (RFC2205) can only support requirement (1), but is not able to= support (2), since the e2e RSVP carries information that is associated wit= h a per flow state maintained at the edges. Aggregated RSVP (RFC3175) and Generic Aggregated RSVP (RFC4860) can support= both requirements, since one of the features that are supported by both is= to carry objects that are associated to an aggregated state maintained at = the edges. In the context of PCN, the aggregated state is the ingress egres= s aggregate state. Best regards, Georgios ________________________________ Van: Bob Briscoe [bob.briscoe@bt.com] Verzonden: vrijdag 16 november 2012 21:03 To: Tom Taylor Cc: Karagiannis, G. (EWI); anuragb@cisco.com; tsvwg@ietf.org; rsvp-dir@ietf= a.amsl.com; PCN IETF list Onderwerp: Re: [PCN] Redundant aggregate reservations: draft-ietf-tsvwg-rsv= p-pcn-03 Tom, The edge behaviour RFCs attempted to abstract over any signalling protcol, but I think they ended up being biased towards the ITU way of doing things, rather than an abstraction that encompassed both RACF and RSVP, which was probably too ambitious. Is you piggy-backing draft effectively what I am describing - piggy-backing on e2e signalling? I don't believe we need any more abstract drafts if that's what you mean - we need to focus on RSVP specifically now. We could perhaps re-boot from Francois's original draft. Bob At 22:09 15/11/2012, Tom Taylor wrote: >OK, I guess I see your point. I was too focussed on the calculations >that are done at the Decision Point. > >It makes me wonder if I should revive that piggy-backing edge >behaviour draft I once started. > >On 15/11/2012 4:02 PM, Bob Briscoe wrote: >>Tom, >> >>The RSVP message I'm proposing doesn't say "Never mind the SESSION in >>this message, I'm related to every flow with the same first hop". It >>says "These are the marking probabilities for the SESSION in this >>message". Then the PCN-ingress (not the message) infers that all other >>flows that share the same aggregate will share the same marking >>probability, because PCN marking on interior nodes is random and unbiased= . >> >>It's a subtle distinction, but it preserves the semantics of RSVP >>messages, without the three disadvantages of setting up an RSVP >>aggregate that I mentioned. >> >>You will have seen from the rest of the message that I have not rejected >>the concept of aggregation, I am merely saying that the PCN-ingress and >>PCN-egress can hold the concept internally. >> >> >>Bob >> >>At 16:42 15/11/2012, Tom Taylor wrote: >>>I'm not sure the semantics of the PCN information -- particularly as >>>it relates to flow termination -- are correct without some sort of >>>concept of aggregation. Or can you really define an RSVP object that >>>has semantics "Never mind the SESSION in this message, I'm related to >>>every flow with the same first hop"? >... ________________________________________________________________ Bob Briscoe, BT Innovate & Design --_000_3AC1435F846D44CB8F601E43C572AA0Bmimectl_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <6EE3108BA1005A439DF1361D59CFCB5D@exchange.utwente.nl> Content-Transfer-Encoding: quoted-printable <html dir=3D"ltr"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style>.EmailQuote { BORDER-LEFT: #800000 2px solid; PADDING-LEFT: 4pt; MARGIN-LEFT: 1pt } </style><style id=3D"owaParaStyle">P { MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px } </style> </head> <body ocsi=3D"0" fPStyle=3D"1"> <div style=3D"FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: #000000; FONT-SIZ= E: 10pt"> <p>Hi Bob, Hi Tom,</p> <p> </p> <p>The solution that you are proposing, i.e., use of the e2e RSVP (RFC2205)= , is in my opinion architecturally and conceptually wrong!</p> <p>The reason is the following!</p> <p> </p> <p>In PCN we need a signaling protocol that is able to: (1) to carry i= nformation from PCN-egress-edge to PCN-ingress-edge and (2) the carried inf= ormation needs to be related to an aggregated state, i.e., the ingress-egre= ss-aggregate state.</p> <p> </p> <p>The e2e RSVP (RFC2205) can only support requirement (1), but is not able= to support (2), since the e2e RSVP carries information that is associated = with a per flow state maintained at the edges.</p> <p> </p> <p>Aggregated RSVP (RFC3175) and Generic Aggregated RSVP (RFC4860) can supp= ort both requirements, since one of the features that are supported by both= is to carry objects that are associated to an aggregated state maintained = at the edges. In the context of PCN, the aggregated state is the ingress egress aggregate state.</p> <p> </p> <p>Best regards,</p> <p>Georgios</p> <p> </p> <div> <hr tabindex=3D"-1"> <div id=3D"x_divRplyFwdMsg"><font color=3D"#000000" size=3D"2" face=3D"Taho= ma"><b>Van:</b> Bob Briscoe [bob.briscoe@bt.com]<br> <b>Verzonden:</b> vrijdag 16 november 2012 21:03<br> <b>To:</b> Tom Taylor<br> <b>Cc:</b> Karagiannis, G. (EWI); anuragb@cisco.com; tsvwg@ietf.org; rsvp-d= ir@ietfa.amsl.com; PCN IETF list<br> <b>Onderwerp:</b> Re: [PCN] Redundant aggregate reservations: draft-ietf-ts= vwg-rsvp-pcn-03<br> </font><br> </div> <div></div> </div> <font size=3D"2"><span style=3D"FONT-SIZE: 10pt"> <div class=3D"PlainText">Tom,<br> <br> The edge behaviour RFCs attempted to abstract over any signalling <br> protcol, but I think they ended up being biased towards the ITU way <br> of doing things, rather than an abstraction that encompassed both <br> RACF and RSVP, which was probably too ambitious.<br> <br> Is you piggy-backing draft effectively what I am describing - <br> piggy-backing on e2e signalling?<br> <br> I don't believe we need any more abstract drafts if that's what you <br> mean - we need to focus on RSVP specifically now. We could perhaps <br> re-boot from Francois's original draft.<br> <br> <br> <br> Bob<br> <br> At 22:09 15/11/2012, Tom Taylor wrote:<br> >OK, I guess I see your point. I was too focussed on the calculations <b= r> >that are done at the Decision Point.<br> ><br> >It makes me wonder if I should revive that piggy-backing edge <br> >behaviour draft I once started.<br> ><br> >On 15/11/2012 4:02 PM, Bob Briscoe wrote:<br> >>Tom,<br> >><br> >>The RSVP message I'm proposing doesn't say "Never mind the SES= SION in<br> >>this message, I'm related to every flow with the same first hop&quo= t;. It<br> >>says "These are the marking probabilities for the SESSION in t= his<br> >>message". Then the PCN-ingress (not the message) infers that a= ll other<br> >>flows that share the same aggregate will share the same marking<br> >>probability, because PCN marking on interior nodes is random and un= biased.<br> >><br> >>It's a subtle distinction, but it preserves the semantics of RSVP<b= r> >>messages, without the three disadvantages of setting up an RSVP<br> >>aggregate that I mentioned.<br> >><br> >>You will have seen from the rest of the message that I have not rej= ected<br> >>the concept of aggregation, I am merely saying that the PCN-ingress= and<br> >>PCN-egress can hold the concept internally.<br> >><br> >><br> >>Bob<br> >><br> >>At 16:42 15/11/2012, Tom Taylor wrote:<br> >>>I'm not sure the semantics of the PCN information -- particular= ly as<br> >>>it relates to flow termination -- are correct without some sort= of<br> >>>concept of aggregation. Or can you really define an RSVP object= that<br> >>>has semantics "Never mind the SESSION in this message, I'm= related to<br> >>>every flow with the same first hop"?<br> >...<br> <br> ________________________________________________________________<br> Bob Briscoe,          &nb= sp;            =          BT Innovate & Design <= br> <br> </div> </span></font></div> </body> </html> --_000_3AC1435F846D44CB8F601E43C572AA0Bmimectl_-- From karagian@cs.utwente.nl Sat Nov 17 02:29:06 2012 Return-Path: <karagian@cs.utwente.nl> 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 E320021F865E; Sat, 17 Nov 2012 02:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LiD8898hvrSF; Sat, 17 Nov 2012 02:29:04 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 16DC721F86F1; Sat, 17 Nov 2012 02:29:03 -0800 (PST) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sat, 17 Nov 2012 11:29:02 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.65]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0318.004; Sat, 17 Nov 2012 11:29:02 +0100 From: <karagian@cs.utwente.nl> To: <bob.briscoe@bt.com> Thread-Topic: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 Thread-Index: AQHNxDcFfpf298aJCEynXyNL8nPO8pft04r6gAAAwzw= Date: Sat, 17 Nov 2012 10:29:01 +0000 Message-ID: <1E38B46D-C270-4D6E-B97A-619C00259FEC@mimectl> References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <E728D0E3C41E644A96A7CCA61863BED4081DE009@xmb-aln-x12.cisco.com> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> <FF1A9612A94D5C4A81ED7DE1039AB80F2ED8FEDF@EXMBX04.ad.utwente.nl> <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> <38323AE1-362C-4DBF-87A0-2D468586CC53@mimectl>, <201211162014.qAGKEYxK014300@bagheera.jungle.bt.co.uk> In-Reply-To: <201211162014.qAGKEYxK014300@bagheera.jungle.bt.co.uk> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.91.134.3] Content-Type: multipart/alternative; boundary="_000_1E38B46DC2704D6EB97A619C00259FECmimectl_" MIME-Version: 1.0 Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, slblake@petri-meat.com, philip.eardley@bt.com, anuragb@cisco.com, sob@harvard.edu, rsvp-dir@ietfa.amsl.com, pcn@ietf.org, jmpolk@cisco.com Subject: Re: [tsvwg] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 17 Nov 2012 10:29:07 -0000 --_000_1E38B46DC2704D6EB97A619C00259FECmimectl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bob, So, what you actually proposing is to discard a specification that has been= accepted by both PCN and tsvwg WGs to be considered as a WG specification = and to use a specification that you are proposing and that is conceptually = and architecturally wrong. The solution that you are proposing, i.e., use of the e2e RSVP (RFC2205), i= s in my opinion architecturally and conceptually wrong! The reason is the following! In PCN we need a signaling protocol that is able to: (1) to carry informati= on from PCN-egress-edge to PCN-ingress-edge and (2) the carried information= needs to be related to an aggregated state, i.e., the ingress-egress-aggre= gate state. The e2e RSVP (RFC2205) can only support requirement (1), but is not able to= support (2), since the e2e RSVP carries information that is associated wit= h a per flow state maintained at the edges. Aggregated RSVP (RFC3175) and Generic Aggregated RSVP (RFC4860) can support= both requirements, since one of the features that are supported by both is= to carry objects that are associated to an aggregated state maintained at = the edges. In the context of PCN, the aggregated state is the ingress egres= s aggregate state. Best regards, Georgios ________________________________ Van: Bob Briscoe [bob.briscoe@bt.com] Verzonden: vrijdag 16 november 2012 21:14 To: Karagiannis, G. (EWI) Cc: carlberg@g11.org.uk; tsvwg@ietf.org; philip.eardley@bt.com; pcn@ietf.or= g; rsvp-dir@ietfa.amsl.com; sob@harvard.edu; slblake@petri-meat.com; gorry@= erg.abdn.ac.uk; jmpolk@cisco.com; anuragb@cisco.com Onderwerp: RE: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-= 03 Georgios, Yes, I apologise for not reviewing earlier. I appreciate you followed the p= rocedure. My problem was that a quick read of tsvwg-rsvp-pcn wasn't enough to underst= and it. So I stayed quiet even though I wasn't so happy about the direction= , because I didn't have enough understanding to feel I could argue. Only in the last week or so, I collected together all the references and re= -read them and their references, and made a concerted effort to understand = what your draft was proposing. I have to say, it was quite a struggle (over= a few days and the write-up took 2 days). However, I admit that it would have been preferable for everyone if I had m= ade this effort earlier. Bob At 13:02 16/11/2012, karagian@cs.utwente.nl wrote: Hi Bob, $B!!(B Thanks for your comments! Regarding your statement: What I meant in my previous email is that our ind= ividual draft that was used as a working basis for this WG draft was alrea= dy using the generic aggregation RSVP (RFC 4860) as the existing signaling = protocol, see: http://tools.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt Moreover, during IETF 81, this individual draft has been presneted, where a= lso the rationale of using (RFC 4860) was also the following slides see pre= sentation slides (slide 5): http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf $B!!(B In particular in slide 4 mentions: "All PCN charter items are fulfilled, except: Submit Encoding and Transport of PCN from Domain Egress to Ingress to the I= ESG for consideration as a Proposed Standard RFC Pairs of PCN edge nodes use ingress-egress-aggregates (IEA): Need a signaling protocol to transport PCN information from PCN-egress-node= to PCN-ingress-node and to maintain ingress-egress-aggregate between each = pair of PCN edge nodes" Furthermore Slide 5 mentions: $B!!(B "IETF QoS signaling protocols to solve problem: Next Steps in Signaling Protocol (NSIS) subset (RFC 5971, RFC 5974, RFC 597= 9) Aggregation of RSVP for IPv4 and IPv6 Reservations (RFC3175) Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations (RFC486= 0) All can be used, but for time being selected RFC 4860 due: possible deployment interest supports RFC 3175 and additional features such as: support of multiple IEAs from same pair of PCN edge nodes support of bandwidth reduction for individual flows (RFC 4495)" $B!!(B Before IETF 81 and during IETF 81 this point has been discussed. The outcome of these discussions is that short after IETF 81, the individua= l draft (draft-karagiannis-pcn-tsvwg-rsvp-pcn-01) become (after small modifications) the draft-ietf-tsvwg-rsvp-pcn-00, which = also was using RFC 4860 as the base signaling protocol. $B!!(B It will be very helpful if the PCN WG chairs (Scott and/or Steve) and the t= svwg WG chairs (Gorry and/or James) could confirm the above statement! $B!!(B So both the PCN WG and tsvwg WG agreed that this specifictaion should use a= s basis the generic RSVP aggregation protocol! $B!!(B $B!!(B $B!!(B In a subsequent email and on a later moment I will also answer to your furt= her remarks! $B!!(B Best regards, Georgios ________________________________ Van: Bob Briscoe [bob.briscoe@bt.com] Verzonden: donderdag 15 november 2012 14:07 To: Karagiannis, G. (EWI); anuragb@cisco.com Cc: carlberg@g11.org.uk; anuragb@cisco.com; tsvwg@ietf.org; philip.eardley@= bt.com; PCN IETF list; rsvp-dir@ietfa.amsl.com Onderwerp: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 Georgios, Anurag, Below is the main point of my review, arguing that aggregate reservations a= re redundant. I'm reviewing as: - a member of the RSVP directorate - one of the early PCN design team - a co-author of draft-lefaucheur-rsvp-ecn-01, on which this draft is based= . I would have missed any decision to use aggregate reservations. Pls point m= e to the relevant discussion (e.g. Subject line / date). I admit I tuned out of much of the later PCN signalling discussion. I found= the whole exercise of abstracting PCN away from specific signalling protoc= ols highly tedious; it meant we couldn't sensibly address important issues = like message reliability, timeliness etc. Nonetheless, here's why I believe RSVP aggregation is redundant: PCN edge-nodes support the concept of an ingress-egress aggregate in their = own internal tables, but they don't need to refer to an aggregate on the wi= re{Note 1}. PCN-ingress and PCN-egress nodes intrinscially know which e2e r= eservations belong to which aggregate by grouping together those e2e reserv= ations with the same next hop or previous hop respectively. {Note 1: except in one case described later - but it doesn't require all th= e other baggage of aggregate reservations} =3D=3DBackground=3D=3D Aggregate reservations [RFC3175, RFC4860] are designed to reduce the state = required on interior nodes. Interior nodes still require state per aggregat= e reservation, but only reservation state, not classification and schedulin= g state [RFC3175, Section 1.4.1 last para]. In contrast, as you correctly point out (in Section 2.1.7), PCN requires ab= solutely no reservation-related state on interior nodes. =3D=3DDisadvantages=3D=3D Requiring PCN to use aggregate reservations has the following three disadva= ntages and no advantages: 1) Redundant Processing The PATH message between aggregator and deaggregator in rsvp-pcn-03 (trigge= red by an E2E PathErr message from deaggregator to aggregator) is redundant= , and just doubles the processing required at the PCN-edge-nodes (if this i= sn't obvious, I spell it out separately for PATH & RESV messages below). 2) Reduced Resilience Not only is an aggregate PATH redundant, it actually reduces resilience. Be= cause an aggregate PATH is pinned to interior routers. Therefore, when rout= ing changes, it is more complex and slower to move to the new route. By not= pinning to interior routers, PCN was designed to 'just work' over interior= routing changes - with no need for any changes to the RSVP PATHs. (But it = would still detect overload after a re-route and terminate or rate-reduce f= lows if necessary.) 3) Extra Latency A further disadvantage is the extra latency required for the first reservat= ion that sets up an aggregate. This is two ingress-egress round trips minus= the round trip time from egress to destination (or one ingress-egress roun= d trip if it is greater). This will rarely add to latency on heavily used i= ngress-egress aggregates, but it will occur frequently on all the 'long-tai= l' (lightly used) ingress-egress aggregates. =3D=3DPATH=3D=3D With RFC 3175 or 4860 aggregate paths, the aggregator forwards the e2e PATH= messages with IP protocol number RSVP-E2E-IGNORE and the deaggregator chan= ges them back to RSVP before forwarding onward. Also the aggregator sends a= n aggregate PATH message, which is processed by each interior node and by t= he deaggregator. On a path across a PCN region, given interior nodes ignore aggregate PATH m= essages as well, the only PCN nodes that handle aggregate messages are the = aggregator and the deaggregator. The aggregator and deaggregator process al= l the e2e PATH messages anyway, so if we require the aggregator to add up a= ll the e2e PATH messages and form them into an aggregate PATH message, this= is just extra redundant work for both PCN-edge-nodes. =3D=3DRESV=3D=3D The deaggregator unicasts e2e RESV messages to the previous RSVP hop, which= is the aggregator. Therefore, if we require the deaggregator to add up all= the RESV messages and form them into an aggregate RESV message, this is ju= st redundant work for both PCN-edge-nodes, because they both already proces= s all the e2e RESV messages anyway, and no other node uses the aggregate RE= SV messages. =3D=3DPCN object=3D=3D This raises the question of how the PCN-egress communicates the various mar= king rates (the PCN object) to the PCN-ingress. There are two possibilities= : i) the PCN-egress includes a current PCN object in each e2e RESV that it re= turns to the PCN-ingress. The PCN-ingress strips the PCN object out before = forwarding the RESV back to the previous RSVP hop. ii) the PCN-egress attaches a PCN object to an aggregate reservation, as in= pcn-rsvp-03. Either are possible, because a PCN object carries information about marking= probabilities, and PCN works on the assumption that the marking probabilit= y of an ingress-egress aggregate is the same as the marking probability of = the flows within the aggregate. A PCN object can be contained either in an = e2e RESV or an aggregate RESV as long as the PCN-ingress can associate an e= 2e RESV with the correct aggregate (which it can, because it maintains an i= nternal table of mappings between e2e reservations and their aggregates). Which of the two is best is a question of message timing... * For e2e admission decisions, the PCN object is only needed at the time ea= ch e2e RESV is sent, so option i) makes sense. * For flow rate reduction or flow termination decisions, the deaggregator n= eeds to regularly send PCN objects to the ingress. The PCN-egress is sending regular e2e RESV refresh messages to the PCN-ingr= ess, so a PCN object can be included in each of these. To ensure that PCN o= bjects are sent often enough, I suggest the PCN-egress also maintains a tim= er per ingress-egress aggregate which it resets every time it sends a PCN o= bject for that IEA. If the timer expires, the PCN-egress sends a PCN object= to the PCN-egress even thought it was not triggered by an e2e RESV refresh= . We could require the SESSION object in this message to refer to either of= : a) any one of the e2e SESSIONs in the aggregate, b) the aggregate. In case (a), the message would need to somehow tell the ingress not to forw= ard this RESV refresh to the RSVP previous hop. In case (b) in the PCN-ingress table of mappings between e2e SESSIONs and a= ggregate SESSIONs, it would include an entry for the aggregate that maps to= itself. If the result of the look-up is the same as the input, it knows no= t to forward the RESV refresh further. The wire protocol doesn't need to identify whether the SESSION is an aggreg= ate or not. This is the one case I mentioned at the start {Note 1} where an= aggregate is referred to on the wire. In summary, PCN already reduces reservation state and processing to nothing= on interior nodes. Adding aggregate reservations to PCN requires more proc= essing and state, it unnecessarily pins routes to interior nodes and adds u= nnecessary latency. Bob At 18:23 14/11/2012, karagian@cs.utwente.nl wrote: Hi Bob, Regarding the generic aggregated RSVP selection, actually the PCN WG agreed= with this selection! This was actually the first step that was needed for this work, and the PCN= WG had no main objections on this selection! So I do not understand your remark that your comment will have major implic= ations! Please note that the generic aggregated RSVP is selected since the PCN IEA = are associated with flows that are aggregated at the edges. So a signalling= protocol that supports aggregation of flows at the edges is very suitable = for this purpose! The generic aggregated RSVP is such a signalling protocol= ! Best regards, Georgios From: Bob Briscoe [mailto:bob.briscoe@bt.com] Sent: woensdag 14 november 2012 12:57 To: Anurag Bhargava (anuragb) Cc: Karagiannis, G. (EWI) Subject: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 Anurag, I have my comments half-written up. I will try to finish them by the end of= today. They should be orthogonal to the PBAC comment below, so if you wanted to st= art altering that area, I don't think it would waste too much time. However, my main comments will concern the use of aggregated reservations (= as I said at the mic), so that could have major implications. Bob At 20:14 13/11/2012, Anurag Bhargava (anuragb) wrote: Hi Bob, Thanks for the comments. If U have some text that will be great els I have= also started putting some text on the topic U brought up. May be we can conference after US thanksgiving week and collaborate the te= xt and try to move forward. Please let us know what might be a good time and I can schedule a Webex co= nf. Thx -Anurag From: "karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl> " <karagian@cs= .utwente.nl<mailto:karagian@cs.utwente.nl> > Date: Saturday, November 10, 2012 8:10 AM To: "bob.briscoe@bt.com<mailto:bob.briscoe@bt.com>" <bob.briscoe@bt.com<mai= lto:bob.briscoe@bt.com>> Cc: "carlberg@g11.org.uk<mailto:carlberg@g11.org.uk>" <carlberg@g11.org.uk<= mailto:carlberg@g11.org.uk>>, Anurag Bhargava <anuragb@cisco.com<mailto:anu= ragb@cisco.com>>, "tsvwg@ietf.org<mailto:tsvwg@ietf.org>" <tsvwg@ietf.org<m= ailto:tsvwg@ietf.org>>, "philip.eardley@bt.com<mailto:philip.eardley@bt.com= > " <philip.eardley@bt.com<mailto:philip.eardley@bt.com> > Subject: RE: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 Hi Bob, Thanks very much for the comments! I think that they are very useful! It will be very beneficiary for the fast progress of this draft if you woul= d like to contribute as a co-author to this draft and write this additional= section that describes "that the PCN-ingress can refer flow admission and termination decisions to a central decision point (using e.g. COPS), which = will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingr= ess could itself be the policy decision point.)" Best regards, Georgios ________________________________ Van: Bob Briscoe [bob.briscoe@bt.com<mailto:bob.briscoe@bt.com>] Verzonden: vrijdag 9 november 2012 16:33 To: Karagiannis, G. (EWI) Cc: carlberg@g11.org.uk<mailto:carlberg@g11.org.uk>; anuragb@cisco.com<mail= to:anuragb@cisco.com>; tsvwg@ietf.org<mailto:tsvwg@ietf.org>; EARDLEY, Phil Onderwerp: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 Georgios, I shall post my full review of this draft in the next few days (needs typing up - currently scribbled on a paper copy). This email is solely in response to your answer about on-path vs off-path policy. At 18:55 04/11/2012, karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl> = wrote: >So in this case an additional signaling protocol will be >needed to be specified that covers the signaling between the >PCN-egress-node and the centralized node >and between PCN-ingress-node and the centralized node. >In PCN we decdided to only focus on the specification of the >signaling protocol that completes the >feedback loop from PCN-egress-node to PCN-ingress-node and to focus >on the signaling protocol >used between the edge nodes and the centralized node. When I/we originally designed CL-PCN over RSVP (2005), the idea was that it would fit with the policy-based admission control (PBAC) architecture of RFC2753. In this architecture, an Intserv node at the ingress to a domain is the policy enforcement point (PEP), and it refers to a logically centralised 'policy decision point' (PDP) for decisions on which flows to block/terminate, typically using COPS. To make this doc fit the PBAC framework, all we have to do is: * Describe the PCN-ingress only as the PCN-ingress and not as the decision point (find 'decision' throughout doc and fix). * Add a section saying the PCN-ingress can refer flow admission and termination decisions to a central decision point (using e.g. COPS), which will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingress could itself be the policy decision point.) * Refer to this new PBAC section from Section 3.11 giving the admission decision procedure. * Some people might think this means COPS will need new protocol elements to carry PCN marking rates to the policy decision point. But PCN marking rates are irrelevant to the policy decision: the PCN-ingress just uses PCN to determine whether it needs to block or terminate, and it refers to the policy decision point for which flows to block/terminate. * Unfortunately, neither of the two PCN system descriptions [RFC6661, RFC6662] describe a PBAC-based case. The architecture [RFC5559] refers to the PBAC framework [RFC2753] but unfortunately doesn't spell out how it fits. Originally, I referenced PBAC from RFC5559, but just as the PCN w-g was closing I realised that (some?) others in the PCN w-g were working under the assumption that the only way to talk to a centralised policy node was from the egress, possibly without being aware of the contents of RFC2753. I think it's OK to introduce a new architectural arrangement in this RSVP doc, given RFC2753 is specific to the way RSVP works. Bob At 12:28 05/11/2012, karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl> = wrote: >Hi Ken, > >Thank you very much! >We will try to catch Francois and discuss the last (in line) issue with hi= m! > >Best regards, >Georgios > >________________________________________ >Van: ken carlberg [carlberg@g11.org.uk<mailto:carlberg@g11.org.uk>] >Verzonden: maandag 5 november 2012 13:23 >To: Karagiannis, G. (EWI) >Cc: tsvwg@ietf.org<mailto:tsvwg@ietf.org>; anuragb@cisco.com<mailto:anurag= b@cisco.com> >Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03 > >Georgios, > > > Georgios: We will try to explain the rationale of why we consider > that RSVP can only be used for the situation that the > > decision point is collocated with the PCN-ingress-node. The main > reason of this is that in the case that the > > decision point is collocated with the PCN-ingress-node,the > required signaling protocol used to complete a > > feedback loop from egress to ingress can be an entirely on-path > protocol, like what RSVP is. > > In the situation that the the decision point is a centralized > node, then the required signaling protocol > > can be a combination of an on-path and off-path protocol. This is > because the > > decision point might not be located on the data path! So in this > case an additional signaling protocol will be > > needed to be specified that covers the signaling between the > PCN-egress-node and the centralized node > > and between PCN-ingress-node and the centralized node. > > In PCN we decdided to only focus on the specification of the > signaling protocol that completes the > > feedback loop from PCN-egress-node to PCN-ingress-node and to > focus on the signaling protocol > > used between the edge nodes and the centralized node. > > This is also the reason of why PCN WG decided to only focus on > the situation that the decision point is > > collocated with the PCN-ingress-node. > >Great, this is helpful, and this is the information that needs to be >in the draft. > > >> 6) This comment is just for you to contemplate -- I'm not > expecting any changes. > >> I noticed that you have a fair number of SHOULD, and some SHOULD NOTs. > >> And it seems a lot of this is a carry over from rfc-4860, so in > a sense you are inheriting an approach that > >> was agreed to from an earlier effort. But I wonder in the back > of my mind, what impact occurs if > >> an implementor doesn't follow the SHOULD? Does the design break > in supporting PCN? > >> Again, I want to stress that this isnt a show stopper, but I > would appreciate it if you gave it some thought. > > > > Georgios: Yes, in several cases the design might break in supporting PC= N. > > This is also the reason of using SHOULD instead of MAY. Do you > want us to explain this in more detail in the draft? > >well, actually, I was more curious as to why a number of these cases >are SHOULD instead of MUST. Again, the SHOULD's in your document >seem to be a carry-over from rfc-4860 (which set the precedent), so >its a bit unfair for you to explain what was done in an earlier >effort. I just wanted to make sure you gave some thought to the >subject. And if things will break if SHOULD is not followed by an >implementer/configuration, then maybe you should be more stringent >and change things to MUST. Perhaps a brief private conversation >with Francois Le Faucheur will be helpful. > >cheers, > >-ken ________________________________________________________________ Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design --_000_1E38B46DC2704D6EB97A619C00259FECmimectl_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <9C14CC6243A29E4391C9BBB5AE110384@exchange.utwente.nl> Content-Transfer-Encoding: quoted-printable <html dir=3D"ltr"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style id=3D"owaParaStyle">P { MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px } </style> </head> <body ocsi=3D"0" fPStyle=3D"1"> <div style=3D"FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: #000000; FONT-SIZ= E: 10pt"> <p>Hi Bob,</p> <p> </p> <p>So, what you actually proposing is to discard a specification that has b= een accepted by both PCN and tsvwg WGs to be considered as a WG specificati= on and to use a specification that you are proposing and that is conceptual= ly and architecturally wrong.</p> <p> </p> <p>The solution that you are proposing, i.e., use of the e2e RSVP (RFC2205)= , is in my opinion architecturally and conceptually wrong!</p> <p>The reason is the following!</p> <p></p> <p> </p> <p>In PCN we need a signaling protocol that is able to: (1) to carry inform= ation from PCN-egress-edge to PCN-ingress-edge and (2) the carried informat= ion needs to be related to an aggregated state, i.e., the ingress-egress-ag= gregate state.</p> <p></p> <p>The e2e RSVP (RFC2205) can only support requirement (1), but is not able= to support (2), since the e2e RSVP carries information that is associated = with a per flow state maintained at the edges.</p> <p></p> <p>Aggregated RSVP (RFC3175) and Generic Aggregated RSVP (RFC4860) can supp= ort both requirements, since one of the features that are supported by both= is to carry objects that are associated to an aggregated state maintained = at the edges. In the context of PCN, the aggregated state is the ingress egress aggregate state.</p> <p></p> <p> </p> <p>Best regards,</p> <p>Georgios</p> <p></p> <hr tabindex=3D"-1"> <div style=3D"DIRECTION: ltr" id=3D"divRpF569877"><font color=3D"#000000" s= ize=3D"2" face=3D"Tahoma"><b>Van:</b> Bob Briscoe [bob.briscoe@bt.com]<br> <b>Verzonden:</b> vrijdag 16 november 2012 21:14<br> <b>To:</b> Karagiannis, G. (EWI)<br> <b>Cc:</b> carlberg@g11.org.uk; tsvwg@ietf.org; philip.eardley@bt.com; pcn@= ietf.org; rsvp-dir@ietfa.amsl.com; sob@harvard.edu; slblake@petri-meat.com;= gorry@erg.abdn.ac.uk; jmpolk@cisco.com; anuragb@cisco.com<br> <b>Onderwerp:</b> RE: Redundant aggregate reservations: draft-ietf-tsvwg-rs= vp-pcn-03<br> </font><br> </div> <div></div> <div>Georgios,<br> <br> Yes, I apologise for not reviewing earlier. I appreciate you followed the p= rocedure.<br> <br> My problem was that a quick read of tsvwg-rsvp-pcn wasn't enough to underst= and it. So I stayed quiet even though I wasn't so happy about the direction= , because I didn't have enough understanding to feel I could argue.<br> <br> Only in the last week or so, I collected together all the references and re= -read them and their references, and made a concerted effort to understand = what your draft was proposing. I have to say, it was quite a struggle (over= a few days and the write-up took 2 days). <br> <br> However, I admit that it would have been preferable for everyone if I had m= ade this effort earlier.<br> <br> <br> Bob<br> <br> At 13:02 16/11/2012, karagian@cs.utwente.nl wrote:<br> <br> <blockquote class=3D"cite" type=3D"cite">Hi Bob,<br> <br> $B!!(B<br> <br> Thanks for your comments!<br> <br> Regarding your statement: What I meant in my previous email is that our ind= ividual draft that was used as a working basis for this WG draft  was = already using the generic aggregation RSVP (RFC 4860) as the existing signa= ling protocol, see:<br> <br>  <br> <br> <a href=3D"http://tools.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01= .txt" target=3D"_blank">http://tools.ietf.org/id/draft-karagiannis-pcn-tsvw= g-rsvp-pcn-01.txt</a> <br> <br>  <br> <br> Moreover, during IETF 81, this individual draft has been presneted, where a= lso the rationale of using (RFC 4860) was also the following slides see pre= sentation slides (slide 5):<br> <br>  <br> <br> <a href=3D"http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf" target=3D= "_blank">http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf</a><br> <br> $B!!(B<br> <br> In particular in slide 4 mentions:<br> <br> "All PCN charter items are fulfilled, except:<br> <br> Submit Encoding and Transport of PCN from Domain Egress to Ingress to the I= ESG for consideration as a Proposed Standard RFC<br> <br> Pairs of PCN edge nodes use ingress-egress-aggregates (IEA):<br> <br> Need a signaling protocol to transport PCN information from PCN-egress-node= to PCN-ingress-node and to maintain ingress-egress-aggregate between each = pair of PCN edge nodes"<br> <br> Furthermore Slide 5 mentions:<br> <br> $B!!(B<br> <br> "IETF QoS signaling protocols to solve problem:<br> <br> Next Steps in Signaling Protocol (NSIS) subset (RFC 5971, RFC 5974, RFC 597= 9)<br> <br> Aggregation of RSVP for IPv4 and IPv6 Reservations (RFC3175)<br> <br> Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations (RFC486= 0)<br> <br> All can be used, but for time being selected RFC 4860 due:<br> <br> possible deployment interest<br> <br> supports RFC 3175 and additional features such as: <br> <br> support of multiple IEAs from same pair of PCN edge nodes <br> <br> support of bandwidth reduction for individual flows (RFC 4495)"<br> <br> $B!!(B<br> <br> Before IETF 81 and during IETF 81 this point has been discussed.<br> <br> The outcome of these discussions is that short after IETF 81, the individua= l draft (draft-karagiannis-pcn-tsvwg-rsvp-pcn-01) <br> <br> become (after small modifications) the draft-ietf-tsvwg-rsvp-pcn-00, which = also was using RFC 4860 as the base signaling protocol.<br> <br> $B!!(B<br> <br> It will be very helpful if the PCN WG chairs (Scott and/or Steve) and the t= svwg WG chairs (Gorry and/or James) could confirm the above statement!<br> <br> $B!!(B<br> <br> So both the PCN WG and tsvwg WG agreed that this specifictaion should use a= s basis the generic RSVP aggregation protocol!<br> <br> $B!!(B<br> <br> $B!!(B<br> <br> $B!!(B<br> <br> In a subsequent email and on a later moment I will also answer to your furt= her remarks!<br> <br> $B!!(B<br> <br> Best regards,<br> <br> Georgios<br> <hr> <font size=3D"2" face=3D"Tahoma"><b>Van:</b> Bob Briscoe [bob.briscoe@bt.co= m]<br> <b>Verzonden:</b> donderdag 15 november 2012 14:07<br> <b>To:</b> Karagiannis, G. (EWI); anuragb@cisco.com<br> <b>Cc:</b> carlberg@g11.org.uk; anuragb@cisco.com; tsvwg@ietf.org; philip.e= ardley@bt.com; PCN IETF list; rsvp-dir@ietfa.amsl.com<br> <b>Onderwerp:</b> Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-p= cn-03<br> </font><br> Georgios, Anurag,<br> <br> Below is the main point of my review, arguing that aggregate reservations a= re redundant. I'm reviewing as:<br> - a member of the RSVP directorate<br> - one of the early PCN design team<br> - a co-author of draft-lefaucheur-rsvp-ecn-01, on which this draft is based= .<br> <br> I would have missed any decision to use aggregate reservations. Pls point m= e to the relevant discussion (e.g. Subject line / date).<br> <br> I admit I tuned out of much of the later PCN signalling discussion. I found= the whole exercise of abstracting PCN away from specific signalling protoc= ols highly tedious; it meant we couldn't sensibly address important issues = like message reliability, timeliness etc. <br> <br> Nonetheless, here's why I believe RSVP aggregation is redundant:<br> <br> PCN edge-nodes support the concept of an ingress-egress aggregate in their = own internal tables, but they don't need to refer to an aggregate on the wi= re{Note 1}. PCN-ingress and PCN-egress nodes intrinscially know which e2e r= eservations belong to which aggregate by grouping together those e2e reservations with the same next hop or prev= ious hop respectively.<br> <br> {Note 1: except in one case described later - but it doesn't require all th= e other baggage of aggregate reservations}<br> <br> =3D=3DBackground=3D=3D<br> Aggregate reservations [RFC3175, RFC4860] are designed to reduce the state = required on interior nodes. Interior nodes still require state per aggregat= e reservation, but only reservation state, not classification and schedulin= g state [RFC3175, Section 1.4.1 last para].<br> <br> In contrast, as you correctly point out (in Section 2.1.7), PCN requires ab= solutely no reservation-related state on interior nodes.<br> <br> =3D=3DDisadvantages=3D=3D<br> Requiring PCN to use aggregate reservations has the following three disadva= ntages and no advantages:<br> <br> 1) Redundant Processing<br> The PATH message between aggregator and deaggregator in rsvp-pcn-03 (trigge= red by an E2E PathErr message from deaggregator to aggregator) is redundant= , and just doubles the processing required at the PCN-edge-nodes (if this i= sn't obvious, I spell it out separately for PATH & RESV messages below). <br> <br> 2) Reduced Resilience<br> Not only is an aggregate PATH redundant, it actually reduces resilience. Be= cause an aggregate PATH is pinned to interior routers. Therefore, when rout= ing changes, it is more complex and slower to move to the new route. By not= pinning to interior routers, PCN was designed to 'just work' over interior routing changes - with no need f= or any changes to the RSVP PATHs. (But it would still detect overload after= a re-route and terminate or rate-reduce flows if necessary.)<br> <br> 3) Extra Latency<br> A further disadvantage is the extra latency required for the first reservat= ion that sets up an aggregate. This is two ingress-egress round trips minus= the round trip time from egress to destination (or one ingress-egress roun= d trip if it is greater). This will rarely add to latency on heavily used ingress-egress aggregates, but it wi= ll occur frequently on all the 'long-tail' (lightly used) ingress-egress ag= gregates.<br> <br> =3D=3DPATH=3D=3D<br> <br> With RFC 3175 or 4860 aggregate paths, the aggregator forwards the e2e PATH= messages with IP protocol number RSVP-E2E-IGNORE and the deaggregator chan= ges them back to RSVP before forwarding onward. Also the aggregator sends a= n aggregate PATH message, which is processed by each interior node and by the deaggregator.<br> <br> On a path across a PCN region, given interior nodes ignore aggregate PATH m= essages as well, the only PCN nodes that handle aggregate messages are the = aggregator and the deaggregator. The aggregator and deaggregator process al= l the e2e PATH messages anyway, so if we require the aggregator to add up all the e2e PATH messages and fo= rm them into an aggregate PATH message, this is just extra redundant work f= or both PCN-edge-nodes.<br> <br> =3D=3DRESV=3D=3D<br> <br> The deaggregator unicasts e2e RESV messages to the previous RSVP hop, which= is the aggregator. Therefore, if we require the deaggregator to add up all= the RESV messages and form them into an aggregate RESV message, this is ju= st redundant work for both PCN-edge-nodes, because they both already process all the e2e RESV messages anyway, and no= other node uses the aggregate RESV messages.<br> <br> =3D=3DPCN object=3D=3D<br> <br> This raises the question of how the PCN-egress communicates the various mar= king rates (the PCN object) to the PCN-ingress. There are two possibilities= :<br> i) the PCN-egress includes a current PCN object in each e2e RESV that it re= turns to the PCN-ingress. The PCN-ingress strips the PCN object out before = forwarding the RESV back to the previous RSVP hop.<br> ii) the PCN-egress attaches a PCN object to an aggregate reservation, as in= pcn-rsvp-03.<br> <br> Either are possible, because a PCN object carries information about marking= probabilities, and PCN works on the assumption that the marking probabilit= y of an ingress-egress aggregate is the same as the marking probability of = the flows within the aggregate. A PCN object can be contained either in an e2e RESV or an aggregate RESV a= s long as the PCN-ingress can associate an e2e RESV with the correct aggreg= ate (which it can, because it maintains an internal table of mappings betwe= en e2e reservations and their aggregates).<br> <br> Which of the two is best is a question of message timing...<br> <br> * For e2e admission decisions, the PCN object is only needed at the time ea= ch e2e RESV is sent, so option i) makes sense.<br> <br> * For flow rate reduction or flow termination decisions, the deaggregator n= eeds to regularly send PCN objects to the ingress. <br> <br> The PCN-egress is sending regular e2e RESV refresh messages to the PCN-ingr= ess, so a PCN object can be included in each of these. To ensure that PCN o= bjects are sent often enough, I suggest the PCN-egress also maintains a tim= er per ingress-egress aggregate which it resets every time it sends a PCN object for that IEA. If the time= r expires, the PCN-egress sends a PCN object to the PCN-egress even thought= it was not triggered by an e2e RESV refresh. We could require the SESSION = object in this message to refer to either of:<br> a) any one of the e2e SESSIONs in the aggregate, <br> b) the aggregate.<br> <br> In case (a), the message would need to somehow tell the ingress not to forw= ard this RESV refresh to the RSVP previous hop.<br> <br> In case (b) in the PCN-ingress table of mappings between e2e SESSIONs and a= ggregate SESSIONs, it would include an entry for the aggregate that maps to= itself. If the result of the look-up is the same as the input, it knows no= t to forward the RESV refresh further. <br> <br> The wire protocol doesn't need to identify whether the SESSION is an aggreg= ate or not. This is the one case I mentioned at the start {Note 1} where an= aggregate is referred to on the wire.<br> <br> <br> <br> In summary, PCN already reduces reservation state and processing to nothing= on interior nodes. Adding aggregate reservations to PCN requires more proc= essing and state, it unnecessarily pins routes to interior nodes and adds u= nnecessary latency.<br> <br> <br> Bob<br> <br> At 18:23 14/11/2012, karagian@cs.utwente.nl wrote:<br> <blockquote class=3D"cite" type=3D"cite">Hi Bob,<br>  <br> Regarding the generic aggregated RSVP selection, actually the PCN WG agreed= with this selection!<br> This was actually the first step that was needed for this work, and the PCN= WG had no main objections on this selection!<br>  <br> So I do not understand your remark that your comment will have major implic= ations!<br>  <br> Please note that the generic aggregated RSVP is selected since the PCN IEA = are associated with flows that are aggregated at the edges. So a signalling= protocol that supports aggregation of flows at the edges is very suitable = for this purpose! The generic aggregated RSVP is such a signalling protocol!<br>  <br>  <br> Best regards,<br> Georgios<br>  <br>  <br>  <br>  <br> <b>From:</b> Bob Briscoe [<a href=3D"mailto:bob.briscoe@bt.com" target=3D"_= blank">mailto:bob.briscoe@bt.com</a>] <br> <b>Sent:</b> woensdag 14 november 2012 12:57<br> <b>To:</b> Anurag Bhargava (anuragb)<br> <b>Cc:</b> Karagiannis, G. (EWI)<br> <b>Subject:</b> Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br>  <br> Anurag,<br> <br> I have my comments half-written up. I will try to finish them by the end of= today.<br> <br> They should be orthogonal to the PBAC comment below, so if you wanted to st= art altering that area, I don't think it would waste too much time. <br> <br> However, my main comments will concern the use of aggregated reservations (= as I said at the mic), so that could have major implications.<br> <br> <br> Bob<br> <br> At 20:14 13/11/2012, Anurag Bhargava (anuragb) wrote:<br> <br> Hi Bob,<br>  Thanks for the comments. If U have some text that will be great els I= have also started putting some text on the topic U brought up.<br>  May be we can conference after US thanksgiving week and collaborate t= he text and try to move forward.<br> <br>  Please let us know what might be a good time and I can schedule a Web= ex conf.<br> <br> Thx<br> -Anurag<br> <br> From: "<a href=3D"mailto:karagian@cs.utwente.nl" target=3D"_blank">kar= agian@cs.utwente.nl</a> " <<a href=3D"mailto:karagian@cs.utwente.nl= " target=3D"_blank">karagian@cs.utwente.nl</a> ><br> Date: Saturday, November 10, 2012 8:10 AM<br> To: "<a href=3D"mailto:bob.briscoe@bt.com" target=3D"_blank">bob.brisc= oe@bt.com</a>" <<a href=3D"mailto:bob.briscoe@bt.com" target=3D"_bl= ank">bob.briscoe@bt.com</a>><br> Cc: "<a href=3D"mailto:carlberg@g11.org.uk" target=3D"_blank">carlberg= @g11.org.uk</a>" <<a href=3D"mailto:carlberg@g11.org.uk" target=3D"= _blank">carlberg@g11.org.uk</a>>, Anurag Bhargava <<a href=3D"mailto:= anuragb@cisco.com" target=3D"_blank">anuragb@cisco.com</a>>, "<a hr= ef=3D"mailto:tsvwg@ietf.org" target=3D"_blank">tsvwg@ietf.org</a>" <<a href=3D"mailto:tsvwg@ietf.org" target=3D"_blank">tsvwg@ietf.org</a>= >, "<a href=3D"mailto:philip.eardley@bt.com" target=3D"_blank">phil= ip.eardley@bt.com</a> " <<a href=3D"mailto:philip.eardley@bt.com" t= arget=3D"_blank">philip.eardley@bt.com</a> ><br> Subject: RE: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br> <br> Hi Bob,<br> <br>  <br> <br> Thanks very much for the comments! I think that they are very useful! <br> <br>  <br> <br> It will be very beneficiary for the fast progress of this draft if you woul= d like to contribute as a co-author to this draft and write this additional= section that describes "that the PCN-ingress can refer flow admission= and <br> termination decisions to a central decision point (using e.g. COPS), which = will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingr= ess could itself be the policy decision point.)"<br> <br>  <br> <br> Best regards,<br> <br> Georgios<br> <br>  <br> <hr> <b>Van:</b> Bob Briscoe [<a href=3D"mailto:bob.briscoe@bt.com" target=3D"_b= lank">bob.briscoe@bt.com</a>]<br> <b>Verzonden:</b> vrijdag 9 november 2012 16:33<br> <b>To:</b> Karagiannis, G. (EWI)<br> <b>Cc:</b> <a href=3D"mailto:carlberg@g11.org.uk" target=3D"_blank">carlber= g@g11.org.uk</a>; <a href=3D"mailto:anuragb@cisco.com" target=3D"_blank">anuragb@cisco.com</a= >; <a href=3D"mailto:tsvwg@ietf.org" target=3D"_blank"> tsvwg@ietf.org</a>; EARDLEY, Phil<br> <b>Onderwerp:</b> Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br> <br> Georgios,<br> <br> I shall post my full review of this draft in the next few days (needs <br> typing up - currently scribbled on a paper copy). This email is <br> solely in response to your answer about on-path vs off-path policy.<br> <br> At 18:55 04/11/2012, <a href=3D"mailto:karagian@cs.utwente.nl" target=3D"_b= lank">karagian@cs.utwente.nl</a> wrote:<br> >So in this case an additional signaling protocol will be<br> >needed to be specified that covers the signaling between the <br> >PCN-egress-node and the centralized node<br> >and between PCN-ingress-node and the centralized node.<br> >In PCN we decdided to only focus on the specification of the <br> >signaling protocol that completes the<br> >feedback loop from PCN-egress-node to PCN-ingress-node and to focus <br= > >on the signaling protocol<br> >used between the edge nodes and the centralized node.<br> <br> When I/we originally designed CL-PCN over RSVP (2005), the idea was <br> that it would fit with the policy-based admission control (PBAC) <br> architecture of RFC2753. In this architecture, an Intserv node at the <br> ingress to a domain is the policy enforcement point (PEP), and it <br> refers to a logically centralised 'policy decision point' (PDP) for <br> decisions on which flows to block/terminate, typically using COPS.<br> <br> To make this doc fit the PBAC framework, all we have to do is:<br> * Describe the PCN-ingress only as the PCN-ingress and not as the <br> decision point (find 'decision' throughout doc and fix).<br> * Add a section saying the PCN-ingress can refer flow admission and <br> termination decisions to a central decision point (using e.g. COPS), <br> which will respond to the PCN-ingress as per RFC2753. (Alternatively <br> the PCN-ingress could itself be the policy decision point.)<br> * Refer to this new PBAC section from Section 3.11 giving the <br> admission decision procedure.<br> <br> * Some people might think this means COPS will need new protocol <br> elements to carry PCN marking rates to the policy decision point. But <br> PCN marking rates are irrelevant to the policy decision: the <br> PCN-ingress just uses PCN to determine whether it needs to block or <br> terminate, and it refers to the policy decision point for which flows <br> to block/terminate.<br> <br> * Unfortunately, neither of the two PCN system descriptions [RFC6661, <br> RFC6662] describe a PBAC-based case. The architecture [RFC5559] <br> refers to the PBAC framework [RFC2753] but unfortunately doesn't <br> spell out how it fits. Originally, I referenced PBAC from RFC5559, <br> but just as the PCN w-g was closing I realised that (some?) others in <br> the PCN w-g were working under the assumption that the only way to <br> talk to a centralised policy node was from the egress, possibly <br> without being aware of the contents of RFC2753.<br> <br> I think it's OK to introduce a new architectural arrangement in this <br> RSVP doc, given RFC2753 is specific to the way RSVP works.<br> <br> <br> Bob<br> <br> <br> <br> At 12:28 05/11/2012, <a href=3D"mailto:karagian@cs.utwente.nl" target=3D"_b= lank">karagian@cs.utwente.nl</a> wrote:<br> >Hi Ken,<br> ><br> >Thank you very much!<br> >We will try to catch Francois and discuss the last (in line) issue with= him!<br> ><br> >Best regards,<br> >Georgios<br> ><br> >________________________________________<br> >Van: ken carlberg [<a href=3D"mailto:carlberg@g11.org.uk" target=3D"_bl= ank">carlberg@g11.org.uk</a>]<br> >Verzonden: maandag 5 november 2012 13:23<br> >To: Karagiannis, G. (EWI)<br> >Cc: <a href=3D"mailto:tsvwg@ietf.org" target=3D"_blank">tsvwg@ietf.org<= /a>; <a href=3D"mailto:anuragb@cisco.com" target=3D"_blank"> anuragb@cisco.com</a><br> >Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03<br> ><br> >Georgios,<br> ><br> > > Georgios: We will try to explain the rationale of why we consider= <br> > that RSVP can only be used for the situation that the<br> > > decision point is collocated with the PCN-ingress-node. The main = <br> > reason of this is that in the case that the<br> > > decision point is collocated with the PCN-ingress-node,the <br> > required signaling protocol used to complete a<br> > > feedback loop from egress to ingress can be an entirely on-path <= br> > protocol, like what RSVP is.<br> > > In the situation that the the decision point is a centralized <br= > > node, then the required signaling protocol<br> > > can be a combination of an on-path and off-path protocol. This is= <br> > because the<br> > > decision point might not be located on the data path! So in this = <br> > case an additional signaling protocol will be<br> > > needed to be specified that covers the signaling between the <br> > PCN-egress-node and the centralized node<br> > > and between PCN-ingress-node and the centralized node.<br> > > In PCN we decdided to only focus on the specification of the <br> > signaling protocol that completes the<br> > > feedback loop from PCN-egress-node to PCN-ingress-node and to <br= > > focus on the signaling protocol<br> > > used between the edge nodes and the centralized node.<br> > > This is also the reason of why PCN WG decided to only focus on <b= r> > the situation that the decision point is<br> > > collocated with the PCN-ingress-node.<br> ><br> >Great, this is helpful, and this is the information that needs to be <b= r> >in the draft.<br> ><br> > >> 6) This comment is just for you to contemplate -- I'm not <br= > > expecting any changes.<br> > >> I noticed that you have a fair number of SHOULD, and some SHO= ULD NOTs.<br> > >> And it seems a lot of this is a carry over from rfc-4860, so = in <br> > a sense you are inheriting an approach that<br> > >> was agreed to from an earlier effort.  But I wonder in t= he back <br> > of my mind, what impact occurs if<br> > >> an implementor doesn't follow the SHOULD?  Does the desi= gn break <br> > in supporting PCN?<br> > >> Again, I want to stress that this isnt a show stopper, but I = <br> > would appreciate it if you gave it some thought.<br> > ><br> > > Georgios: Yes, in several cases the design might break in support= ing PCN.<br> > > This is also the reason of using SHOULD instead of MAY. Do you <b= r> > want us to explain this in more detail in the draft?<br> ><br> >well, actually, I was more curious as to why a number of these cases <b= r> >are SHOULD instead of MUST.  Again, the SHOULD's in your document = <br> >seem to be a carry-over from rfc-4860 (which set the precedent), so <br= > >its a bit unfair for you to explain what was done in an earlier <br> >effort.  I just wanted to make sure you gave some thought to the <= br> >subject.  And if things will break if SHOULD is not followed by an= <br> >implementer/configuration, then maybe you should be more stringent <br> >and change things to MUST.  Perhaps a brief private conversation <= br> >with Francois Le Faucheur will be helpful.<br> ><br> >cheers,<br> ><br> >-ken<br> <br> ________________________________________________________________<br> Bob Briscoe,          &nb= sp;            =          BT Innovate & Design <= br> <br> ________________________________________________________________<br> Bob Briscoe,          &nb= sp;            =          BT Innovate & Design</= blockquote> <br> ________________________________________________________________<br> Bob Briscoe,          &nb= sp;            =          BT Innovate & Design <= /blockquote> <p>________________________________________________________________<br> Bob Briscoe,          &nb= sp;            =          BT Innovate & Design <= /p> </div> </div> </body> </html> --_000_1E38B46DC2704D6EB97A619C00259FECmimectl_-- From bob.briscoe@bt.com Tue Nov 20 13:15:19 2012 Return-Path: <bob.briscoe@bt.com> 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 E569721F849F for <tsvwg@ietfa.amsl.com>; Tue, 20 Nov 2012 13:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.458 X-Spam-Level: X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhmhOPj0JSsR for <tsvwg@ietfa.amsl.com>; Tue, 20 Nov 2012 13:15:19 -0800 (PST) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id C470F21F8235 for <tsvwg@ietf.org>; Tue, 20 Nov 2012 13:15:18 -0800 (PST) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 20 Nov 2012 21:15:16 +0000 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 20 Nov 2012 21:15:16 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.309.2; Tue, 20 Nov 2012 21:15:12 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1353446111158; Tue, 20 Nov 2012 21:15:11 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qAKLF8bf002759; Tue, 20 Nov 2012 21:15:09 GMT Message-ID: <201211202115.qAKLF8bf002759@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Nov 2012 21:15:10 +0000 To: Tom Taylor <tom.taylor.stds@gmail.com> From: Bob Briscoe <bob.briscoe@bt.com> In-Reply-To: <50A7E859.1020305@gmail.com> References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <E728D0E3C41E644A96A7CCA61863BED4081DE009@xmb-aln-x12.cisco.com> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> <FF1A9612A94D5C4A81ED7DE1039AB80F2ED8FEDF@EXMBX04.ad.utwente.nl> <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> <50A51B8C.4010806@gmail.com> <201211152102.qAFL2BWE010641@bagheera.jungle.bt.co.uk> <50A56804.3090208@gmail.com> <201211162003.qAGK3C3s014269@bagheera.jungle.bt.co.uk> <50A7E859.1020305@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: PCN IETF list <pcn@ietf.org>, anuragb@cisco.com, tsvwg@ietf.org, rsvp-dir@ietfa.amsl.com Subject: Re: [tsvwg] [PCN] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 20 Nov 2012 21:15:20 -0000 Tom, I've lost the context - I don't think I said an IEA "is composed of all flows with the same next hop" or anything like this. If it helps, I'm not changing the defintion of an IEA, I'm just saying it doesn't have to be identified in any wire-protocol; it can be known about solely internally on PCN-boundary nodes. Bob At 19:41 17/11/2012, Tom Taylor wrote: >Stepping back a bit here, I have to question your definition of an >ingress-egress aggregate. When you say it is composed of all flows >with the same next hop, what sort of topology are you assuming? The >definition makes sense only if the next hop entity is an egress node. > >If that is not the case, then I would say an ingress-egress >aggregate is defined as the set of all flows where the RESV message >comes from the same egress node. > >On 16/11/2012 3:03 PM, Bob Briscoe wrote: >>Tom, >> >>The edge behaviour RFCs attempted to abstract over any signalling >>protcol, but I think they ended up being biased towards the ITU way of >>doing things, rather than an abstraction that encompassed both RACF and >>RSVP, which was probably too ambitious. >> >>Is you piggy-backing draft effectively what I am describing - >>piggy-backing on e2e signalling? >> >>I don't believe we need any more abstract drafts if that's what you mean >>- we need to focus on RSVP specifically now. We could perhaps re-boot >>from Francois's original draft. >> >> >> >>Bob >> >>At 22:09 15/11/2012, Tom Taylor wrote: >>>OK, I guess I see your point. I was too focussed on the calculations >>>that are done at the Decision Point. >>> >>>It makes me wonder if I should revive that piggy-backing edge >>>behaviour draft I once started. >>> >>>On 15/11/2012 4:02 PM, Bob Briscoe wrote: >>>>Tom, >>>> >>>>The RSVP message I'm proposing doesn't say "Never mind the SESSION in >>>>this message, I'm related to every flow with the same first hop". It >>>>says "These are the marking probabilities for the SESSION in this >>>>message". Then the PCN-ingress (not the message) infers that all other >>>>flows that share the same aggregate will share the same marking >>>>probability, because PCN marking on interior nodes is random and >>>>unbiased. >>>> >>>>It's a subtle distinction, but it preserves the semantics of RSVP >>>>messages, without the three disadvantages of setting up an RSVP >>>>aggregate that I mentioned. >>>> >>>>You will have seen from the rest of the message that I have not rejected >>>>the concept of aggregation, I am merely saying that the PCN-ingress and >>>>PCN-egress can hold the concept internally. >>>> >>>> >>>>Bob >>>> >>>>At 16:42 15/11/2012, Tom Taylor wrote: >>>>>I'm not sure the semantics of the PCN information -- particularly as >>>>>it relates to flow termination -- are correct without some sort of >>>>>concept of aggregation. Or can you really define an RSVP object that >>>>>has semantics "Never mind the SESSION in this message, I'm related to >>>>>every flow with the same first hop"? >>>... >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Tue Nov 20 13:25:47 2012 Return-Path: <bob.briscoe@bt.com> 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 6F30A21F881B for <tsvwg@ietfa.amsl.com>; Tue, 20 Nov 2012 13:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+xGRh7QpMJy for <tsvwg@ietfa.amsl.com>; Tue, 20 Nov 2012 13:25:46 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 03B1821F8765 for <tsvwg@ietf.org>; Tue, 20 Nov 2012 13:25:44 -0800 (PST) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 20 Nov 2012 21:25:43 +0000 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 20 Nov 2012 21:25:42 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.309.2; Tue, 20 Nov 2012 21:25:36 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1353446735337; Tue, 20 Nov 2012 21:25:35 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qAKLPXVQ002786; Tue, 20 Nov 2012 21:25:33 GMT Message-ID: <201211202125.qAKLPXVQ002786@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Nov 2012 21:25:33 +0000 To: <karagian@cs.utwente.nl> From: Bob Briscoe <bob.briscoe@bt.com> In-Reply-To: <3AC1435F-846D-44CB-8F60-1E43C572AA0B@mimectl> References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <E728D0E3C41E644A96A7CCA61863BED4081DE009@xmb-aln-x12.cisco.com> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> <FF1A9612A94D5C4A81ED7DE1039AB80F2ED8FEDF@EXMBX04.ad.utwente.nl> <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> <50A51B8C.4010806@gmail.com> <201211152102.qAFL2BWE010641@bagheera.jungle.bt.co.uk> <50A56804.3090208@gmail.com> <201211162003.qAGK3C3s014269@bagheera.jungle.bt.co.uk> <3AC1435F-846D-44CB-8F60-1E43C572AA0B@mimectl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_287273207==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: rsvp-dir@ietfa.amsl.com, anuragb@cisco.com, tsvwg@ietf.org, pcn@ietf.org, tom.taylor.stds@gmail.com Subject: Re: [tsvwg] [PCN] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 20 Nov 2012 21:25:47 -0000 --=====================_287273207==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Georgios, See the discussion with Tom - he gets what I'm saying. Also, in my mail that started this thread (15 november 2012 14:07) I explained why you can get the benefits of aggregation by solely holding the concept of IEAs on the PCN-boundary nodes, without identifying an aggregate in the signalling protocol at all. I also explained why identifying an aggregate in the signalling protocol led to three worse properties and nothing better. Please argue with that, rather than talking about aggregates only in conceptual terms - and only in terms of whole RFCs, rather than specifics - that is where the problem stemmed from, I believe. Bob At 10:26 17/11/2012, karagian@cs.utwente.nl wrote: >Hi Bob, Hi Tom, > > > >The solution that you are proposing, i.e., use of the e2e RSVP >(RFC2205), is in my opinion architecturally and conceptually wrong! > >The reason is the following! > > > >In PCN we need a signaling protocol that is able to: (1) to carry >information from PCN-egress-edge to PCN-ingress-edge and (2) the >carried information needs to be related to an aggregated state, >i.e., the ingress-egress-aggregate state. > > > >The e2e RSVP (RFC2205) can only support requirement (1), but is not >able to support (2), since the e2e RSVP carries information that is >associated with a per flow state maintained at the edges. > > > >Aggregated RSVP (RFC3175) and Generic Aggregated RSVP (RFC4860) can >support both requirements, since one of the features that are >supported by both is to carry objects that are associated to an >aggregated state maintained at the edges. In the context of PCN, the >aggregated state is the ingress egress aggregate state. > > > >Best regards, > >Georgios > > > >---------- >Van: Bob Briscoe [bob.briscoe@bt.com] >Verzonden: vrijdag 16 november 2012 21:03 >To: Tom Taylor >Cc: Karagiannis, G. (EWI); anuragb@cisco.com; tsvwg@ietf.org; >rsvp-dir@ietfa.amsl.com; PCN IETF list >Onderwerp: Re: [PCN] Redundant aggregate reservations: >draft-ietf-tsvwg-rsvp-pcn-03 > >Tom, > >The edge behaviour RFCs attempted to abstract over any signalling >protcol, but I think they ended up being biased towards the ITU way >of doing things, rather than an abstraction that encompassed both >RACF and RSVP, which was probably too ambitious. > >Is you piggy-backing draft effectively what I am describing - >piggy-backing on e2e signalling? > >I don't believe we need any more abstract drafts if that's what you >mean - we need to focus on RSVP specifically now. We could perhaps >re-boot from Francois's original draft. > > > >Bob > >At 22:09 15/11/2012, Tom Taylor wrote: > >OK, I guess I see your point. I was too focussed on the calculations > >that are done at the Decision Point. > > > >It makes me wonder if I should revive that piggy-backing edge > >behaviour draft I once started. > > > >On 15/11/2012 4:02 PM, Bob Briscoe wrote: > >>Tom, > >> > >>The RSVP message I'm proposing doesn't say "Never mind the SESSION in > >>this message, I'm related to every flow with the same first hop". It > >>says "These are the marking probabilities for the SESSION in this > >>message". Then the PCN-ingress (not the message) infers that all other > >>flows that share the same aggregate will share the same marking > >>probability, because PCN marking on interior nodes is random and unbiased. > >> > >>It's a subtle distinction, but it preserves the semantics of RSVP > >>messages, without the three disadvantages of setting up an RSVP > >>aggregate that I mentioned. > >> > >>You will have seen from the rest of the message that I have not rejected > >>the concept of aggregation, I am merely saying that the PCN-ingress and > >>PCN-egress can hold the concept internally. > >> > >> > >>Bob > >> > >>At 16:42 15/11/2012, Tom Taylor wrote: > >>>I'm not sure the semantics of the PCN information -- particularly as > >>>it relates to flow termination -- are correct without some sort of > >>>concept of aggregation. Or can you really define an RSVP object that > >>>has semantics "Never mind the SESSION in this message, I'm related to > >>>every flow with the same first hop"? > >... > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_287273207==.ALT Content-Type: text/html; charset="us-ascii" <html> <body> Georgios,<br><br> See the discussion with Tom - he gets what I'm saying. <br><br> Also, in my mail that started this thread (15 november 2012 14:07) I explained why you can get the benefits of aggregation by solely holding the concept of IEAs on the PCN-boundary nodes, without identifying an aggregate in the signalling protocol at all.<br><br> I also explained why identifying an aggregate in the signalling protocol led to three worse properties and nothing better.<br><br> Please argue with that, rather than talking about aggregates only in conceptual terms - and only in terms of whole RFCs, rather than specifics - that is where the problem stemmed from, I believe.<br><br> <br><br> Bob<br><br> At 10:26 17/11/2012, karagian@cs.utwente.nl wrote:<br><br> <blockquote type=cite class=cite cite="">Hi Bob, Hi Tom,<br><br>  <br><br> The solution that you are proposing, i.e., use of the e2e RSVP (RFC2205), is in my opinion architecturally and conceptually wrong!<br><br> The reason is the following!<br><br>  <br><br> In PCN we need a signaling protocol that is able to: (1) to carry information from PCN-egress-edge to PCN-ingress-edge and (2) the carried information needs to be related to an aggregated state, i.e., the ingress-egress-aggregate state.<br><br>  <br><br> The e2e RSVP (RFC2205) can only support requirement (1), but is not able to support (2), since the e2e RSVP carries information that is associated with a per flow state maintained at the edges.<br><br>  <br><br> Aggregated RSVP (RFC3175) and Generic Aggregated RSVP (RFC4860) can support both requirements, since one of the features that are supported by both is to carry objects that are associated to an aggregated state maintained at the edges. In the context of PCN, the aggregated state is the ingress egress aggregate state.<br><br>  <br><br> Best regards,<br><br> Georgios<br><br>  <br> <hr> <font face="Tahoma" size=2><b>Van:</b> Bob Briscoe [bob.briscoe@bt.com]<br> <b>Verzonden:</b> vrijdag 16 november 2012 21:03<br> <b>To:</b> Tom Taylor<br> <b>Cc:</b> Karagiannis, G. (EWI); anuragb@cisco.com; tsvwg@ietf.org; rsvp-dir@ietfa.amsl.com; PCN IETF list<br> <b>Onderwerp:</b> Re: [PCN] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03<br> </font><br> <font size=2>Tom,<br><br> The edge behaviour RFCs attempted to abstract over any signalling <br> protcol, but I think they ended up being biased towards the ITU way <br> of doing things, rather than an abstraction that encompassed both <br> RACF and RSVP, which was probably too ambitious.<br><br> Is you piggy-backing draft effectively what I am describing - <br> piggy-backing on e2e signalling?<br><br> I don't believe we need any more abstract drafts if that's what you <br> mean - we need to focus on RSVP specifically now. We could perhaps <br> re-boot from Francois's original draft.<br><br> <br><br> Bob<br><br> At 22:09 15/11/2012, Tom Taylor wrote:<br> >OK, I guess I see your point. I was too focussed on the calculations <br> >that are done at the Decision Point.<br> ><br> >It makes me wonder if I should revive that piggy-backing edge <br> >behaviour draft I once started.<br> ><br> >On 15/11/2012 4:02 PM, Bob Briscoe wrote:<br> >>Tom,<br> >><br> >>The RSVP message I'm proposing doesn't say "Never mind the SESSION in<br> >>this message, I'm related to every flow with the same first hop". It<br> >>says "These are the marking probabilities for the SESSION in this<br> >>message". Then the PCN-ingress (not the message) infers that all other<br> >>flows that share the same aggregate will share the same marking<br> >>probability, because PCN marking on interior nodes is random and unbiased.<br> >><br> >>It's a subtle distinction, but it preserves the semantics of RSVP<br> >>messages, without the three disadvantages of setting up an RSVP<br> >>aggregate that I mentioned.<br> >><br> >>You will have seen from the rest of the message that I have not rejected<br> >>the concept of aggregation, I am merely saying that the PCN-ingress and<br> >>PCN-egress can hold the concept internally.<br> >><br> >><br> >>Bob<br> >><br> >>At 16:42 15/11/2012, Tom Taylor wrote:<br> >>>I'm not sure the semantics of the PCN information -- particularly as<br> >>>it relates to flow termination -- are correct without some sort of<br> >>>concept of aggregation. Or can you really define an RSVP object that<br> >>>has semantics "Never mind the SESSION in this message, I'm related to<br> >>>every flow with the same first hop"?<br> >...<br><br> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design <br> </blockquote> <x-sigsep><p></x-sigsep> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design</font></body> </html> --=====================_287273207==.ALT-- From bob.briscoe@bt.com Tue Nov 20 13:29:42 2012 Return-Path: <bob.briscoe@bt.com> 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 3FE2E21F8815 for <tsvwg@ietfa.amsl.com>; Tue, 20 Nov 2012 13:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.181 X-Spam-Level: X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97V3wo2kKmND for <tsvwg@ietfa.amsl.com>; Tue, 20 Nov 2012 13:29:39 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 44DED21F8765 for <tsvwg@ietf.org>; Tue, 20 Nov 2012 13:29:37 -0800 (PST) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 20 Nov 2012 21:29:36 +0000 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 20 Nov 2012 21:29:35 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.309.2; Tue, 20 Nov 2012 21:29:30 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1353446968843; Tue, 20 Nov 2012 21:29:28 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qAKLTPGC002799; Tue, 20 Nov 2012 21:29:25 GMT Message-ID: <201211202129.qAKLTPGC002799@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Nov 2012 21:29:26 +0000 To: <karagian@cs.utwente.nl> From: Bob Briscoe <bob.briscoe@bt.com> In-Reply-To: <1E38B46D-C270-4D6E-B97A-619C00259FEC@mimectl> References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <E728D0E3C41E644A96A7CCA61863BED4081DE009@xmb-aln-x12.cisco.com> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> <FF1A9612A94D5C4A81ED7DE1039AB80F2ED8FEDF@EXMBX04.ad.utwente.nl> <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> <38323AE1-362C-4DBF-87A0-2D468586CC53@mimectl> <201211162014.qAGKEYxK014300@bagheera.jungle.bt.co.uk> <1E38B46D-C270-4D6E-B97A-619C00259FEC@mimectl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_287505981==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, slblake@petri-meat.com, philip.eardley@bt.com, anuragb@cisco.com, sob@harvard.edu, rsvp-dir@ietfa.amsl.com, pcn@ietf.org, jmpolk@cisco.com Subject: Re: [tsvwg] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 20 Nov 2012 21:29:42 -0000 --=====================_287505981==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Georgios, See other email. Pls focus on the specifics (you will need to go back to my original email in the thread, because the specifics were immediately cut from the thread when Tom understood them). The IETF can choose to continue along a path that it originally agreed, whether right or wrong, but it is important to discuss whether it is right or wrong first. Bob At 10:29 17/11/2012, karagian@cs.utwente.nl wrote: >Hi Bob, > > > >So, what you actually proposing is to discard a specification that >has been accepted by both PCN and tsvwg WGs to be considered as a WG >specification and to use a specification that you are proposing and >that is conceptually and architecturally wrong. > > > >The solution that you are proposing, i.e., use of the e2e RSVP >(RFC2205), is in my opinion architecturally and conceptually wrong! > >The reason is the following! > > > >In PCN we need a signaling protocol that is able to: (1) to carry >information from PCN-egress-edge to PCN-ingress-edge and (2) the >carried information needs to be related to an aggregated state, >i.e., the ingress-egress-aggregate state. > >The e2e RSVP (RFC2205) can only support requirement (1), but is not >able to support (2), since the e2e RSVP carries information that is >associated with a per flow state maintained at the edges. > >Aggregated RSVP (RFC3175) and Generic Aggregated RSVP (RFC4860) can >support both requirements, since one of the features that are >supported by both is to carry objects that are associated to an >aggregated state maintained at the edges. In the context of PCN, the >aggregated state is the ingress egress aggregate state. > > > >Best regards, > >Georgios > > >---------- >Van: Bob Briscoe [bob.briscoe@bt.com] >Verzonden: vrijdag 16 november 2012 21:14 >To: Karagiannis, G. (EWI) >Cc: carlberg@g11.org.uk; tsvwg@ietf.org; philip.eardley@bt.com; >pcn@ietf.org; rsvp-dir@ietfa.amsl.com; sob@harvard.edu; >slblake@petri-meat.com; gorry@erg.abdn.ac.uk; jmpolk@cisco.com; >anuragb@cisco.com >Onderwerp: RE: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 > >Georgios, > >Yes, I apologise for not reviewing earlier. I appreciate you >followed the procedure. > >My problem was that a quick read of tsvwg-rsvp-pcn wasn't enough to >understand it. So I stayed quiet even though I wasn't so happy about >the direction, because I didn't have enough understanding to feel I >could argue. > >Only in the last week or so, I collected together all the references >and re-read them and their references, and made a concerted effort >to understand what your draft was proposing. I have to say, it was >quite a struggle (over a few days and the write-up took 2 days). > >However, I admit that it would have been preferable for everyone if >I had made this effort earlier. > > >Bob > >At 13:02 16/11/2012, karagian@cs.utwente.nl wrote: > >>Hi Bob, >> >>$B!!(B >> >>Thanks for your comments! >> >>Regarding your statement: What I meant in my previous email is that >>our individual draft that was used as a working basis for this WG >>draft was already using the generic aggregation RSVP (RFC 4860) as >>the existing signaling protocol, see: >> >> >> >><http://tools.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt>http://tools.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt >> >> >> >> >>Moreover, during IETF 81, this individual draft has been presneted, >>where also the rationale of using (RFC 4860) was also the following >>slides see presentation slides (slide 5): >> >> >> >><http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf>http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf >> >>$B!!(B >> >>In particular in slide 4 mentions: >> >>"All PCN charter items are fulfilled, except: >> >>Submit Encoding and Transport of PCN from Domain Egress to Ingress >>to the IESG for consideration as a Proposed Standard RFC >> >>Pairs of PCN edge nodes use ingress-egress-aggregates (IEA): >> >>Need a signaling protocol to transport PCN information from >>PCN-egress-node to PCN-ingress-node and to maintain >>ingress-egress-aggregate between each pair of PCN edge nodes" >> >>Furthermore Slide 5 mentions: >> >>$B!!(B >> >>"IETF QoS signaling protocols to solve problem: >> >>Next Steps in Signaling Protocol (NSIS) subset (RFC 5971, RFC 5974, RFC 5979) >> >>Aggregation of RSVP for IPv4 and IPv6 Reservations (RFC3175) >> >>Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations (RFC4860) >> >>All can be used, but for time being selected RFC 4860 due: >> >>possible deployment interest >> >>supports RFC 3175 and additional features such as: >> >>support of multiple IEAs from same pair of PCN edge nodes >> >>support of bandwidth reduction for individual flows (RFC 4495)" >> >>$B!!(B >> >>Before IETF 81 and during IETF 81 this point has been discussed. >> >>The outcome of these discussions is that short after IETF 81, the >>individual draft (draft-karagiannis-pcn-tsvwg-rsvp-pcn-01) >> >>become (after small modifications) the >>draft-ietf-tsvwg-rsvp-pcn-00, which also was using RFC 4860 as the >>base signaling protocol. >> >>$B!!(B >> >>It will be very helpful if the PCN WG chairs (Scott and/or Steve) >>and the tsvwg WG chairs (Gorry and/or James) could confirm the above statement! >> >>$B!!(B >> >>So both the PCN WG and tsvwg WG agreed that this specifictaion >>should use as basis the generic RSVP aggregation protocol! >> >>$B!!(B >> >>$B!!(B >> >>$B!!(B >> >>In a subsequent email and on a later moment I will also answer to >>your further remarks! >> >>$B!!(B >> >>Best regards, >> >>Georgios >> >>---------- >>Van: Bob Briscoe [bob.briscoe@bt.com] >>Verzonden: donderdag 15 november 2012 14:07 >>To: Karagiannis, G. (EWI); anuragb@cisco.com >>Cc: carlberg@g11.org.uk; anuragb@cisco.com; tsvwg@ietf.org; >>philip.eardley@bt.com; PCN IETF list; rsvp-dir@ietfa.amsl.com >>Onderwerp: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 >> >>Georgios, Anurag, >> >>Below is the main point of my review, arguing that aggregate >>reservations are redundant. I'm reviewing as: >>- a member of the RSVP directorate >>- one of the early PCN design team >>- a co-author of draft-lefaucheur-rsvp-ecn-01, on which this draft is based. >> >>I would have missed any decision to use aggregate reservations. Pls >>point me to the relevant discussion (e.g. Subject line / date). >> >>I admit I tuned out of much of the later PCN signalling discussion. >>I found the whole exercise of abstracting PCN away from specific >>signalling protocols highly tedious; it meant we couldn't sensibly >>address important issues like message reliability, timeliness etc. >> >>Nonetheless, here's why I believe RSVP aggregation is redundant: >> >>PCN edge-nodes support the concept of an ingress-egress aggregate >>in their own internal tables, but they don't need to refer to an >>aggregate on the wire{Note 1}. PCN-ingress and PCN-egress nodes >>intrinscially know which e2e reservations belong to which aggregate >>by grouping together those e2e reservations with the same next hop >>or previous hop respectively. >> >>{Note 1: except in one case described later - but it doesn't >>require all the other baggage of aggregate reservations} >> >>==Background== >>Aggregate reservations [RFC3175, RFC4860] are designed to reduce >>the state required on interior nodes. Interior nodes still require >>state per aggregate reservation, but only reservation state, not >>classification and scheduling state [RFC3175, Section 1.4.1 last para]. >> >>In contrast, as you correctly point out (in Section 2.1.7), PCN >>requires absolutely no reservation-related state on interior nodes. >> >>==Disadvantages== >>Requiring PCN to use aggregate reservations has the following three >>disadvantages and no advantages: >> >>1) Redundant Processing >>The PATH message between aggregator and deaggregator in rsvp-pcn-03 >>(triggered by an E2E PathErr message from deaggregator to >>aggregator) is redundant, and just doubles the processing required >>at the PCN-edge-nodes (if this isn't obvious, I spell it out >>separately for PATH & RESV messages below). >> >>2) Reduced Resilience >>Not only is an aggregate PATH redundant, it actually reduces >>resilience. Because an aggregate PATH is pinned to interior >>routers. Therefore, when routing changes, it is more complex and >>slower to move to the new route. By not pinning to interior >>routers, PCN was designed to 'just work' over interior routing >>changes - with no need for any changes to the RSVP PATHs. (But it >>would still detect overload after a re-route and terminate or >>rate-reduce flows if necessary.) >> >>3) Extra Latency >>A further disadvantage is the extra latency required for the first >>reservation that sets up an aggregate. This is two ingress-egress >>round trips minus the round trip time from egress to destination >>(or one ingress-egress round trip if it is greater). This will >>rarely add to latency on heavily used ingress-egress aggregates, >>but it will occur frequently on all the 'long-tail' (lightly used) >>ingress-egress aggregates. >> >>==PATH== >> >>With RFC 3175 or 4860 aggregate paths, the aggregator forwards the >>e2e PATH messages with IP protocol number RSVP-E2E-IGNORE and the >>deaggregator changes them back to RSVP before forwarding onward. >>Also the aggregator sends an aggregate PATH message, which is >>processed by each interior node and by the deaggregator. >> >>On a path across a PCN region, given interior nodes ignore >>aggregate PATH messages as well, the only PCN nodes that handle >>aggregate messages are the aggregator and the deaggregator. The >>aggregator and deaggregator process all the e2e PATH messages >>anyway, so if we require the aggregator to add up all the e2e PATH >>messages and form them into an aggregate PATH message, this is just >>extra redundant work for both PCN-edge-nodes. >> >>==RESV== >> >>The deaggregator unicasts e2e RESV messages to the previous RSVP >>hop, which is the aggregator. Therefore, if we require the >>deaggregator to add up all the RESV messages and form them into an >>aggregate RESV message, this is just redundant work for both >>PCN-edge-nodes, because they both already process all the e2e RESV >>messages anyway, and no other node uses the aggregate RESV messages. >> >>==PCN object== >> >>This raises the question of how the PCN-egress communicates the >>various marking rates (the PCN object) to the PCN-ingress. There >>are two possibilities: >>i) the PCN-egress includes a current PCN object in each e2e RESV >>that it returns to the PCN-ingress. The PCN-ingress strips the PCN >>object out before forwarding the RESV back to the previous RSVP hop. >>ii) the PCN-egress attaches a PCN object to an aggregate >>reservation, as in pcn-rsvp-03. >> >>Either are possible, because a PCN object carries information about >>marking probabilities, and PCN works on the assumption that the >>marking probability of an ingress-egress aggregate is the same as >>the marking probability of the flows within the aggregate. A PCN >>object can be contained either in an e2e RESV or an aggregate RESV >>as long as the PCN-ingress can associate an e2e RESV with the >>correct aggregate (which it can, because it maintains an internal >>table of mappings between e2e reservations and their aggregates). >> >>Which of the two is best is a question of message timing... >> >>* For e2e admission decisions, the PCN object is only needed at the >>time each e2e RESV is sent, so option i) makes sense. >> >>* For flow rate reduction or flow termination decisions, the >>deaggregator needs to regularly send PCN objects to the ingress. >> >>The PCN-egress is sending regular e2e RESV refresh messages to the >>PCN-ingress, so a PCN object can be included in each of these. To >>ensure that PCN objects are sent often enough, I suggest the >>PCN-egress also maintains a timer per ingress-egress aggregate >>which it resets every time it sends a PCN object for that IEA. If >>the timer expires, the PCN-egress sends a PCN object to the >>PCN-egress even thought it was not triggered by an e2e RESV >>refresh. We could require the SESSION object in this message to >>refer to either of: >>a) any one of the e2e SESSIONs in the aggregate, >>b) the aggregate. >> >>In case (a), the message would need to somehow tell the ingress not >>to forward this RESV refresh to the RSVP previous hop. >> >>In case (b) in the PCN-ingress table of mappings between e2e >>SESSIONs and aggregate SESSIONs, it would include an entry for the >>aggregate that maps to itself. If the result of the look-up is the >>same as the input, it knows not to forward the RESV refresh further. >> >>The wire protocol doesn't need to identify whether the SESSION is >>an aggregate or not. This is the one case I mentioned at the start >>{Note 1} where an aggregate is referred to on the wire. >> >> >> >>In summary, PCN already reduces reservation state and processing to >>nothing on interior nodes. Adding aggregate reservations to PCN >>requires more processing and state, it unnecessarily pins routes to >>interior nodes and adds unnecessary latency. >> >> >>Bob >> >>At 18:23 14/11/2012, karagian@cs.utwente.nl wrote: >>>Hi Bob, >>> >>>Regarding the generic aggregated RSVP selection, actually the PCN >>>WG agreed with this selection! >>>This was actually the first step that was needed for this work, >>>and the PCN WG had no main objections on this selection! >>> >>>So I do not understand your remark that your comment will have >>>major implications! >>> >>>Please note that the generic aggregated RSVP is selected since the >>>PCN IEA are associated with flows that are aggregated at the >>>edges. So a signalling protocol that supports aggregation of flows >>>at the edges is very suitable for this purpose! The generic >>>aggregated RSVP is such a signalling protocol! >>> >>> >>>Best regards, >>>Georgios >>> >>> >>> >>> >>>From: Bob Briscoe [<mailto:bob.briscoe@bt.com>mailto:bob.briscoe@bt.com] >>>Sent: woensdag 14 november 2012 12:57 >>>To: Anurag Bhargava (anuragb) >>>Cc: Karagiannis, G. (EWI) >>>Subject: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 >>> >>>Anurag, >>> >>>I have my comments half-written up. I will try to finish them by >>>the end of today. >>> >>>They should be orthogonal to the PBAC comment below, so if you >>>wanted to start altering that area, I don't think it would waste >>>too much time. >>> >>>However, my main comments will concern the use of aggregated >>>reservations (as I said at the mic), so that could have major implications. >>> >>> >>>Bob >>> >>>At 20:14 13/11/2012, Anurag Bhargava (anuragb) wrote: >>> >>>Hi Bob, >>> Thanks for the comments. If U have some text that will be great >>> els I have also started putting some text on the topic U brought up. >>> May be we can conference after US thanksgiving week and >>> collaborate the text and try to move forward. >>> >>> Please let us know what might be a good time and I can schedule >>> a Webex conf. >>> >>>Thx >>>-Anurag >>> >>>From: "<mailto:karagian@cs.utwente.nl>karagian@cs.utwente.nl " >>><<mailto:karagian@cs.utwente.nl>karagian@cs.utwente.nl > >>>Date: Saturday, November 10, 2012 8:10 AM >>>To: "<mailto:bob.briscoe@bt.com>bob.briscoe@bt.com" >>><<mailto:bob.briscoe@bt.com>bob.briscoe@bt.com> >>>Cc: "<mailto:carlberg@g11.org.uk>carlberg@g11.org.uk" >>><<mailto:carlberg@g11.org.uk>carlberg@g11.org.uk>, Anurag Bhargava >>><<mailto:anuragb@cisco.com>anuragb@cisco.com>, >>>"<mailto:tsvwg@ietf.org>tsvwg@ietf.org" >>><<mailto:tsvwg@ietf.org>tsvwg@ietf.org>, >>>"<mailto:philip.eardley@bt.com>philip.eardley@bt.com " >>><<mailto:philip.eardley@bt.com>philip.eardley@bt.com > >>>Subject: RE: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 >>> >>>Hi Bob, >>> >>> >>> >>>Thanks very much for the comments! I think that they are very useful! >>> >>> >>> >>>It will be very beneficiary for the fast progress of this draft if >>>you would like to contribute as a co-author to this draft and >>>write this additional section that describes "that the PCN-ingress >>>can refer flow admission and >>>termination decisions to a central decision point (using e.g. >>>COPS), which will respond to the PCN-ingress as per RFC2753. >>>(Alternatively the PCN-ingress could itself be the policy decision point.)" >>> >>> >>> >>>Best regards, >>> >>>Georgios >>> >>> >>> >>>---------- >>>Van: Bob Briscoe [<mailto:bob.briscoe@bt.com>bob.briscoe@bt.com] >>>Verzonden: vrijdag 9 november 2012 16:33 >>>To: Karagiannis, G. (EWI) >>>Cc: <mailto:carlberg@g11.org.uk>carlberg@g11.org.uk; >>><mailto:anuragb@cisco.com>anuragb@cisco.com; >>><mailto:tsvwg@ietf.org>tsvwg@ietf.org; EARDLEY, Phil >>>Onderwerp: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 >>> >>>Georgios, >>> >>>I shall post my full review of this draft in the next few days (needs >>>typing up - currently scribbled on a paper copy). This email is >>>solely in response to your answer about on-path vs off-path policy. >>> >>>At 18:55 04/11/2012, >>><mailto:karagian@cs.utwente.nl>karagian@cs.utwente.nl wrote: >>> >So in this case an additional signaling protocol will be >>> >needed to be specified that covers the signaling between the >>> >PCN-egress-node and the centralized node >>> >and between PCN-ingress-node and the centralized node. >>> >In PCN we decdided to only focus on the specification of the >>> >signaling protocol that completes the >>> >feedback loop from PCN-egress-node to PCN-ingress-node and to focus >>> >on the signaling protocol >>> >used between the edge nodes and the centralized node. >>> >>>When I/we originally designed CL-PCN over RSVP (2005), the idea was >>>that it would fit with the policy-based admission control (PBAC) >>>architecture of RFC2753. In this architecture, an Intserv node at the >>>ingress to a domain is the policy enforcement point (PEP), and it >>>refers to a logically centralised 'policy decision point' (PDP) for >>>decisions on which flows to block/terminate, typically using COPS. >>> >>>To make this doc fit the PBAC framework, all we have to do is: >>>* Describe the PCN-ingress only as the PCN-ingress and not as the >>>decision point (find 'decision' throughout doc and fix). >>>* Add a section saying the PCN-ingress can refer flow admission and >>>termination decisions to a central decision point (using e.g. COPS), >>>which will respond to the PCN-ingress as per RFC2753. (Alternatively >>>the PCN-ingress could itself be the policy decision point.) >>>* Refer to this new PBAC section from Section 3.11 giving the >>>admission decision procedure. >>> >>>* Some people might think this means COPS will need new protocol >>>elements to carry PCN marking rates to the policy decision point. But >>>PCN marking rates are irrelevant to the policy decision: the >>>PCN-ingress just uses PCN to determine whether it needs to block or >>>terminate, and it refers to the policy decision point for which flows >>>to block/terminate. >>> >>>* Unfortunately, neither of the two PCN system descriptions [RFC6661, >>>RFC6662] describe a PBAC-based case. The architecture [RFC5559] >>>refers to the PBAC framework [RFC2753] but unfortunately doesn't >>>spell out how it fits. Originally, I referenced PBAC from RFC5559, >>>but just as the PCN w-g was closing I realised that (some?) others in >>>the PCN w-g were working under the assumption that the only way to >>>talk to a centralised policy node was from the egress, possibly >>>without being aware of the contents of RFC2753. >>> >>>I think it's OK to introduce a new architectural arrangement in this >>>RSVP doc, given RFC2753 is specific to the way RSVP works. >>> >>> >>>Bob >>> >>> >>> >>>At 12:28 05/11/2012, >>><mailto:karagian@cs.utwente.nl>karagian@cs.utwente.nl wrote: >>> >Hi Ken, >>> > >>> >Thank you very much! >>> >We will try to catch Francois and discuss the last (in line) >>> issue with him! >>> > >>> >Best regards, >>> >Georgios >>> > >>> >________________________________________ >>> >Van: ken carlberg [<mailto:carlberg@g11.org.uk>carlberg@g11.org.uk] >>> >Verzonden: maandag 5 november 2012 13:23 >>> >To: Karagiannis, G. (EWI) >>> >Cc: <mailto:tsvwg@ietf.org>tsvwg@ietf.org; >>> <mailto:anuragb@cisco.com>anuragb@cisco.com >>> >Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03 >>> > >>> >Georgios, >>> > >>> > > Georgios: We will try to explain the rationale of why we consider >>> > that RSVP can only be used for the situation that the >>> > > decision point is collocated with the PCN-ingress-node. The main >>> > reason of this is that in the case that the >>> > > decision point is collocated with the PCN-ingress-node,the >>> > required signaling protocol used to complete a >>> > > feedback loop from egress to ingress can be an entirely on-path >>> > protocol, like what RSVP is. >>> > > In the situation that the the decision point is a centralized >>> > node, then the required signaling protocol >>> > > can be a combination of an on-path and off-path protocol. This is >>> > because the >>> > > decision point might not be located on the data path! So in this >>> > case an additional signaling protocol will be >>> > > needed to be specified that covers the signaling between the >>> > PCN-egress-node and the centralized node >>> > > and between PCN-ingress-node and the centralized node. >>> > > In PCN we decdided to only focus on the specification of the >>> > signaling protocol that completes the >>> > > feedback loop from PCN-egress-node to PCN-ingress-node and to >>> > focus on the signaling protocol >>> > > used between the edge nodes and the centralized node. >>> > > This is also the reason of why PCN WG decided to only focus on >>> > the situation that the decision point is >>> > > collocated with the PCN-ingress-node. >>> > >>> >Great, this is helpful, and this is the information that needs to be >>> >in the draft. >>> > >>> > >> 6) This comment is just for you to contemplate -- I'm not >>> > expecting any changes. >>> > >> I noticed that you have a fair number of SHOULD, and some SHOULD NOTs. >>> > >> And it seems a lot of this is a carry over from rfc-4860, so in >>> > a sense you are inheriting an approach that >>> > >> was agreed to from an earlier effort. But I wonder in the back >>> > of my mind, what impact occurs if >>> > >> an implementor doesn't follow the SHOULD? Does the design break >>> > in supporting PCN? >>> > >> Again, I want to stress that this isnt a show stopper, but I >>> > would appreciate it if you gave it some thought. >>> > > >>> > > Georgios: Yes, in several cases the design might break in >>> supporting PCN. >>> > > This is also the reason of using SHOULD instead of MAY. Do you >>> > want us to explain this in more detail in the draft? >>> > >>> >well, actually, I was more curious as to why a number of these cases >>> >are SHOULD instead of MUST. Again, the SHOULD's in your document >>> >seem to be a carry-over from rfc-4860 (which set the precedent), so >>> >its a bit unfair for you to explain what was done in an earlier >>> >effort. I just wanted to make sure you gave some thought to the >>> >subject. And if things will break if SHOULD is not followed by an >>> >implementer/configuration, then maybe you should be more stringent >>> >and change things to MUST. Perhaps a brief private conversation >>> >with Francois Le Faucheur will be helpful. >>> > >>> >cheers, >>> > >>> >-ken >>> >>>________________________________________________________________ >>>Bob Briscoe, BT Innovate & Design >>> >>>________________________________________________________________ >>>Bob Briscoe, BT Innovate & Design >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_287505981==.ALT Content-Type: text/html; charset="us-ascii" <html> <body> Georgios,<br><br> See other email. Pls focus on the specifics (you will need to go back to my original email in the thread, because the specifics were immediately cut from the thread when Tom understood them).<br><br> The IETF can choose to continue along a path that it originally agreed, whether right or wrong, but it is important to discuss whether it is right or wrong first.<br><br> <br> Bob<br><br> At 10:29 17/11/2012, karagian@cs.utwente.nl wrote:<br><br> <blockquote type=cite class=cite cite="">Hi Bob,<br><br>  <br><br> So, what you actually proposing is to discard a specification that has been accepted by both PCN and tsvwg WGs to be considered as a WG specification and to use a specification that you are proposing and that is conceptually and architecturally wrong.<br><br>  <br><br> The solution that you are proposing, i.e., use of the e2e RSVP (RFC2205), is in my opinion architecturally and conceptually wrong!<br><br> The reason is the following!<br><br>  <br><br> In PCN we need a signaling protocol that is able to: (1) to carry information from PCN-egress-edge to PCN-ingress-edge and (2) the carried information needs to be related to an aggregated state, i.e., the ingress-egress-aggregate state.<br><br> The e2e RSVP (RFC2205) can only support requirement (1), but is not able to support (2), since the e2e RSVP carries information that is associated with a per flow state maintained at the edges.<br><br> Aggregated RSVP (RFC3175) and Generic Aggregated RSVP (RFC4860) can support both requirements, since one of the features that are supported by both is to carry objects that are associated to an aggregated state maintained at the edges. In the context of PCN, the aggregated state is the ingress egress aggregate state.<br><br>  <br><br> Best regards,<br><br> Georgios<br><br> <hr> <font face="Tahoma" size=2><b>Van:</b> Bob Briscoe [bob.briscoe@bt.com]<br> <b>Verzonden:</b> vrijdag 16 november 2012 21:14<br> <b>To:</b> Karagiannis, G. (EWI)<br> <b>Cc:</b> carlberg@g11.org.uk; tsvwg@ietf.org; philip.eardley@bt.com; pcn@ietf.org; rsvp-dir@ietfa.amsl.com; sob@harvard.edu; slblake@petri-meat.com; gorry@erg.abdn.ac.uk; jmpolk@cisco.com; anuragb@cisco.com<br> <b>Onderwerp:</b> RE: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03<br> </font><br> Georgios,<br><br> Yes, I apologise for not reviewing earlier. I appreciate you followed the procedure.<br><br> My problem was that a quick read of tsvwg-rsvp-pcn wasn't enough to understand it. So I stayed quiet even though I wasn't so happy about the direction, because I didn't have enough understanding to feel I could argue.<br><br> Only in the last week or so, I collected together all the references and re-read them and their references, and made a concerted effort to understand what your draft was proposing. I have to say, it was quite a struggle (over a few days and the write-up took 2 days). <br><br> However, I admit that it would have been preferable for everyone if I had made this effort earlier.<br><br> <br> Bob<br><br> At 13:02 16/11/2012, karagian@cs.utwente.nl wrote:<br><br> <blockquote type=cite class=cite cite="">Hi Bob,<br><br> $B!!(B<br><br> Thanks for your comments!<br><br> Regarding your statement: What I meant in my previous email is that our individual draft that was used as a working basis for this WG draft  was already using the generic aggregation RSVP (RFC 4860) as the existing signaling protocol, see:<br><br>  <br><br> <a href="http://tools.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt"> http://tools.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt</a> <br><br>  <br><br> Moreover, during IETF 81, this individual draft has been presneted, where also the rationale of using (RFC 4860) was also the following slides see presentation slides (slide 5):<br><br>  <br><br> <a href="http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf"> http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf</a><br><br> $B!!(B<br><br> In particular in slide 4 mentions:<br><br> "All PCN charter items are fulfilled, except:<br><br> Submit Encoding and Transport of PCN from Domain Egress to Ingress to the IESG for consideration as a Proposed Standard RFC<br><br> Pairs of PCN edge nodes use ingress-egress-aggregates (IEA):<br><br> Need a signaling protocol to transport PCN information from PCN-egress-node to PCN-ingress-node and to maintain ingress-egress-aggregate between each pair of PCN edge nodes"<br><br> Furthermore Slide 5 mentions:<br><br> $B!!(B<br><br> "IETF QoS signaling protocols to solve problem:<br><br> Next Steps in Signaling Protocol (NSIS) subset (RFC 5971, RFC 5974, RFC 5979)<br><br> Aggregation of RSVP for IPv4 and IPv6 Reservations (RFC3175)<br><br> Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations (RFC4860)<br><br> All can be used, but for time being selected RFC 4860 due:<br><br> possible deployment interest<br><br> supports RFC 3175 and additional features such as: <br><br> support of multiple IEAs from same pair of PCN edge nodes <br><br> support of bandwidth reduction for individual flows (RFC 4495)"<br><br> $B!!(B<br><br> Before IETF 81 and during IETF 81 this point has been discussed.<br><br> The outcome of these discussions is that short after IETF 81, the individual draft (draft-karagiannis-pcn-tsvwg-rsvp-pcn-01) <br><br> become (after small modifications) the draft-ietf-tsvwg-rsvp-pcn-00, which also was using RFC 4860 as the base signaling protocol.<br><br> $B!!(B<br><br> It will be very helpful if the PCN WG chairs (Scott and/or Steve) and the tsvwg WG chairs (Gorry and/or James) could confirm the above statement!<br><br> $B!!(B<br><br> So both the PCN WG and tsvwg WG agreed that this specifictaion should use as basis the generic RSVP aggregation protocol!<br><br> $B!!(B<br><br> $B!!(B<br><br> $B!!(B<br><br> In a subsequent email and on a later moment I will also answer to your further remarks!<br><br> $B!!(B<br><br> Best regards,<br><br> Georgios<br> <hr> <font face="Tahoma" size=2><b>Van:</b> Bob Briscoe [bob.briscoe@bt.com]<br> <b>Verzonden:</b> donderdag 15 november 2012 14:07<br> <b>To:</b> Karagiannis, G. (EWI); anuragb@cisco.com<br> <b>Cc:</b> carlberg@g11.org.uk; anuragb@cisco.com; tsvwg@ietf.org; philip.eardley@bt.com; PCN IETF list; rsvp-dir@ietfa.amsl.com<br> <b>Onderwerp:</b> Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03<br> </font><br> Georgios, Anurag,<br><br> Below is the main point of my review, arguing that aggregate reservations are redundant. I'm reviewing as:<br> - a member of the RSVP directorate<br> - one of the early PCN design team<br> - a co-author of draft-lefaucheur-rsvp-ecn-01, on which this draft is based.<br><br> I would have missed any decision to use aggregate reservations. Pls point me to the relevant discussion (e.g. Subject line / date).<br><br> I admit I tuned out of much of the later PCN signalling discussion. I found the whole exercise of abstracting PCN away from specific signalling protocols highly tedious; it meant we couldn't sensibly address important issues like message reliability, timeliness etc. <br><br> Nonetheless, here's why I believe RSVP aggregation is redundant:<br><br> PCN edge-nodes support the concept of an ingress-egress aggregate in their own internal tables, but they don't need to refer to an aggregate on the wire{Note 1}. PCN-ingress and PCN-egress nodes intrinscially know which e2e reservations belong to which aggregate by grouping together those e2e reservations with the same next hop or previous hop respectively.<br><br> {Note 1: except in one case described later - but it doesn't require all the other baggage of aggregate reservations}<br><br> ==Background==<br> Aggregate reservations [RFC3175, RFC4860] are designed to reduce the state required on interior nodes. Interior nodes still require state per aggregate reservation, but only reservation state, not classification and scheduling state [RFC3175, Section 1.4.1 last para].<br><br> In contrast, as you correctly point out (in Section 2.1.7), PCN requires absolutely no reservation-related state on interior nodes.<br><br> ==Disadvantages==<br> Requiring PCN to use aggregate reservations has the following three disadvantages and no advantages:<br><br> 1) Redundant Processing<br> The PATH message between aggregator and deaggregator in rsvp-pcn-03 (triggered by an E2E PathErr message from deaggregator to aggregator) is redundant, and just doubles the processing required at the PCN-edge-nodes (if this isn't obvious, I spell it out separately for PATH & RESV messages below). <br><br> 2) Reduced Resilience<br> Not only is an aggregate PATH redundant, it actually reduces resilience. Because an aggregate PATH is pinned to interior routers. Therefore, when routing changes, it is more complex and slower to move to the new route. By not pinning to interior routers, PCN was designed to 'just work' over interior routing changes - with no need for any changes to the RSVP PATHs. (But it would still detect overload after a re-route and terminate or rate-reduce flows if necessary.)<br><br> 3) Extra Latency<br> A further disadvantage is the extra latency required for the first reservation that sets up an aggregate. This is two ingress-egress round trips minus the round trip time from egress to destination (or one ingress-egress round trip if it is greater). This will rarely add to latency on heavily used ingress-egress aggregates, but it will occur frequently on all the 'long-tail' (lightly used) ingress-egress aggregates.<br><br> ==PATH==<br><br> With RFC 3175 or 4860 aggregate paths, the aggregator forwards the e2e PATH messages with IP protocol number RSVP-E2E-IGNORE and the deaggregator changes them back to RSVP before forwarding onward. Also the aggregator sends an aggregate PATH message, which is processed by each interior node and by the deaggregator.<br><br> On a path across a PCN region, given interior nodes ignore aggregate PATH messages as well, the only PCN nodes that handle aggregate messages are the aggregator and the deaggregator. The aggregator and deaggregator process all the e2e PATH messages anyway, so if we require the aggregator to add up all the e2e PATH messages and form them into an aggregate PATH message, this is just extra redundant work for both PCN-edge-nodes.<br><br> ==RESV==<br><br> The deaggregator unicasts e2e RESV messages to the previous RSVP hop, which is the aggregator. Therefore, if we require the deaggregator to add up all the RESV messages and form them into an aggregate RESV message, this is just redundant work for both PCN-edge-nodes, because they both already process all the e2e RESV messages anyway, and no other node uses the aggregate RESV messages.<br><br> ==PCN object==<br><br> This raises the question of how the PCN-egress communicates the various marking rates (the PCN object) to the PCN-ingress. There are two possibilities:<br> i) the PCN-egress includes a current PCN object in each e2e RESV that it returns to the PCN-ingress. The PCN-ingress strips the PCN object out before forwarding the RESV back to the previous RSVP hop.<br> ii) the PCN-egress attaches a PCN object to an aggregate reservation, as in pcn-rsvp-03.<br><br> Either are possible, because a PCN object carries information about marking probabilities, and PCN works on the assumption that the marking probability of an ingress-egress aggregate is the same as the marking probability of the flows within the aggregate. A PCN object can be contained either in an e2e RESV or an aggregate RESV as long as the PCN-ingress can associate an e2e RESV with the correct aggregate (which it can, because it maintains an internal table of mappings between e2e reservations and their aggregates).<br><br> Which of the two is best is a question of message timing...<br><br> * For e2e admission decisions, the PCN object is only needed at the time each e2e RESV is sent, so option i) makes sense.<br><br> * For flow rate reduction or flow termination decisions, the deaggregator needs to regularly send PCN objects to the ingress. <br><br> The PCN-egress is sending regular e2e RESV refresh messages to the PCN-ingress, so a PCN object can be included in each of these. To ensure that PCN objects are sent often enough, I suggest the PCN-egress also maintains a timer per ingress-egress aggregate which it resets every time it sends a PCN object for that IEA. If the timer expires, the PCN-egress sends a PCN object to the PCN-egress even thought it was not triggered by an e2e RESV refresh. We could require the SESSION object in this message to refer to either of:<br> a) any one of the e2e SESSIONs in the aggregate, <br> b) the aggregate.<br><br> In case (a), the message would need to somehow tell the ingress not to forward this RESV refresh to the RSVP previous hop.<br><br> In case (b) in the PCN-ingress table of mappings between e2e SESSIONs and aggregate SESSIONs, it would include an entry for the aggregate that maps to itself. If the result of the look-up is the same as the input, it knows not to forward the RESV refresh further. <br><br> The wire protocol doesn't need to identify whether the SESSION is an aggregate or not. This is the one case I mentioned at the start {Note 1} where an aggregate is referred to on the wire.<br><br> <br><br> In summary, PCN already reduces reservation state and processing to nothing on interior nodes. Adding aggregate reservations to PCN requires more processing and state, it unnecessarily pins routes to interior nodes and adds unnecessary latency.<br><br> <br> Bob<br><br> At 18:23 14/11/2012, karagian@cs.utwente.nl wrote:<br> <blockquote type=cite class=cite cite="">Hi Bob,<br>  <br> Regarding the generic aggregated RSVP selection, actually the PCN WG agreed with this selection!<br> This was actually the first step that was needed for this work, and the PCN WG had no main objections on this selection!<br>  <br> So I do not understand your remark that your comment will have major implications!<br>  <br> Please note that the generic aggregated RSVP is selected since the PCN IEA are associated with flows that are aggregated at the edges. So a signalling protocol that supports aggregation of flows at the edges is very suitable for this purpose! The generic aggregated RSVP is such a signalling protocol!<br>  <br>  <br> Best regards,<br> Georgios<br>  <br>  <br>  <br>  <br> <b>From:</b> Bob Briscoe [<a href="mailto:bob.briscoe@bt.com">mailto:bob.briscoe@bt.com</a>] <br> <b>Sent:</b> woensdag 14 november 2012 12:57<br> <b>To:</b> Anurag Bhargava (anuragb)<br> <b>Cc:</b> Karagiannis, G. (EWI)<br> <b>Subject:</b> Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br>  <br> Anurag,<br><br> I have my comments half-written up. I will try to finish them by the end of today.<br><br> They should be orthogonal to the PBAC comment below, so if you wanted to start altering that area, I don't think it would waste too much time. <br><br> However, my main comments will concern the use of aggregated reservations (as I said at the mic), so that could have major implications.<br><br> <br> Bob<br><br> At 20:14 13/11/2012, Anurag Bhargava (anuragb) wrote:<br><br> Hi Bob,<br>  Thanks for the comments. If U have some text that will be great els I have also started putting some text on the topic U brought up.<br>  May be we can conference after US thanksgiving week and collaborate the text and try to move forward.<br><br>  Please let us know what might be a good time and I can schedule a Webex conf.<br><br> Thx<br> -Anurag<br><br> From: "<a href="mailto:karagian@cs.utwente.nl">karagian@cs.utwente.nl</a> " <<a href="mailto:karagian@cs.utwente.nl">karagian@cs.utwente.nl</a> ><br> Date: Saturday, November 10, 2012 8:10 AM<br> To: "<a href="mailto:bob.briscoe@bt.com">bob.briscoe@bt.com</a>" <<a href="mailto:bob.briscoe@bt.com">bob.briscoe@bt.com</a>><br> Cc: "<a href="mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>" <<a href="mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>>, Anurag Bhargava <<a href="mailto:anuragb@cisco.com">anuragb@cisco.com</a>>, "<a href="mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>" <<a href="mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>>, "<a href="mailto:philip.eardley@bt.com">philip.eardley@bt.com</a> " <<a href="mailto:philip.eardley@bt.com">philip.eardley@bt.com</a> ><br> Subject: RE: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br><br> Hi Bob,<br><br>  <br><br> Thanks very much for the comments! I think that they are very useful! <br><br>  <br><br> It will be very beneficiary for the fast progress of this draft if you would like to contribute as a co-author to this draft and write this additional section that describes "that the PCN-ingress can refer flow admission and <br> termination decisions to a central decision point (using e.g. COPS), which will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingress could itself be the policy decision point.)"<br><br>  <br><br> Best regards,<br><br> Georgios<br><br>  <br> <hr> <b>Van:</b> Bob Briscoe [<a href="mailto:bob.briscoe@bt.com">bob.briscoe@bt.com</a>]<br> <b>Verzonden:</b> vrijdag 9 november 2012 16:33<br> <b>To:</b> Karagiannis, G. (EWI)<br> <b>Cc:</b> <a href="mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>; <a href="mailto:anuragb@cisco.com">anuragb@cisco.com</a>; <a href="mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>; EARDLEY, Phil<br> <b>Onderwerp:</b> Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br><br> Georgios,<br><br> I shall post my full review of this draft in the next few days (needs <br> typing up - currently scribbled on a paper copy). This email is <br> solely in response to your answer about on-path vs off-path policy.<br><br> At 18:55 04/11/2012, <a href="mailto:karagian@cs.utwente.nl">karagian@cs.utwente.nl</a> wrote:<br> >So in this case an additional signaling protocol will be<br> >needed to be specified that covers the signaling between the <br> >PCN-egress-node and the centralized node<br> >and between PCN-ingress-node and the centralized node.<br> >In PCN we decdided to only focus on the specification of the <br> >signaling protocol that completes the<br> >feedback loop from PCN-egress-node to PCN-ingress-node and to focus <br> >on the signaling protocol<br> >used between the edge nodes and the centralized node.<br><br> When I/we originally designed CL-PCN over RSVP (2005), the idea was <br> that it would fit with the policy-based admission control (PBAC) <br> architecture of RFC2753. In this architecture, an Intserv node at the <br> ingress to a domain is the policy enforcement point (PEP), and it <br> refers to a logically centralised 'policy decision point' (PDP) for <br> decisions on which flows to block/terminate, typically using COPS.<br><br> To make this doc fit the PBAC framework, all we have to do is:<br> * Describe the PCN-ingress only as the PCN-ingress and not as the <br> decision point (find 'decision' throughout doc and fix).<br> * Add a section saying the PCN-ingress can refer flow admission and <br> termination decisions to a central decision point (using e.g. COPS), <br> which will respond to the PCN-ingress as per RFC2753. (Alternatively <br> the PCN-ingress could itself be the policy decision point.)<br> * Refer to this new PBAC section from Section 3.11 giving the <br> admission decision procedure.<br><br> * Some people might think this means COPS will need new protocol <br> elements to carry PCN marking rates to the policy decision point. But <br> PCN marking rates are irrelevant to the policy decision: the <br> PCN-ingress just uses PCN to determine whether it needs to block or <br> terminate, and it refers to the policy decision point for which flows <br> to block/terminate.<br><br> * Unfortunately, neither of the two PCN system descriptions [RFC6661, <br> RFC6662] describe a PBAC-based case. The architecture [RFC5559] <br> refers to the PBAC framework [RFC2753] but unfortunately doesn't <br> spell out how it fits. Originally, I referenced PBAC from RFC5559, <br> but just as the PCN w-g was closing I realised that (some?) others in <br> the PCN w-g were working under the assumption that the only way to <br> talk to a centralised policy node was from the egress, possibly <br> without being aware of the contents of RFC2753.<br><br> I think it's OK to introduce a new architectural arrangement in this <br> RSVP doc, given RFC2753 is specific to the way RSVP works.<br><br> <br> Bob<br><br> <br><br> At 12:28 05/11/2012, <a href="mailto:karagian@cs.utwente.nl">karagian@cs.utwente.nl</a> wrote:<br> >Hi Ken,<br> ><br> >Thank you very much!<br> >We will try to catch Francois and discuss the last (in line) issue with him!<br> ><br> >Best regards,<br> >Georgios<br> ><br> >________________________________________<br> >Van: ken carlberg [<a href="mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>]<br> >Verzonden: maandag 5 november 2012 13:23<br> >To: Karagiannis, G. (EWI)<br> >Cc: <a href="mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>; <a href="mailto:anuragb@cisco.com">anuragb@cisco.com</a><br> >Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03<br> ><br> >Georgios,<br> ><br> > > Georgios: We will try to explain the rationale of why we consider <br> > that RSVP can only be used for the situation that the<br> > > decision point is collocated with the PCN-ingress-node. The main <br> > reason of this is that in the case that the<br> > > decision point is collocated with the PCN-ingress-node,the <br> > required signaling protocol used to complete a<br> > > feedback loop from egress to ingress can be an entirely on-path <br> > protocol, like what RSVP is.<br> > > In the situation that the the decision point is a centralized <br> > node, then the required signaling protocol<br> > > can be a combination of an on-path and off-path protocol. This is <br> > because the<br> > > decision point might not be located on the data path! So in this <br> > case an additional signaling protocol will be<br> > > needed to be specified that covers the signaling between the <br> > PCN-egress-node and the centralized node<br> > > and between PCN-ingress-node and the centralized node.<br> > > In PCN we decdided to only focus on the specification of the <br> > signaling protocol that completes the<br> > > feedback loop from PCN-egress-node to PCN-ingress-node and to <br> > focus on the signaling protocol<br> > > used between the edge nodes and the centralized node.<br> > > This is also the reason of why PCN WG decided to only focus on <br> > the situation that the decision point is<br> > > collocated with the PCN-ingress-node.<br> ><br> >Great, this is helpful, and this is the information that needs to be <br> >in the draft.<br> ><br> > >> 6) This comment is just for you to contemplate -- I'm not <br> > expecting any changes.<br> > >> I noticed that you have a fair number of SHOULD, and some SHOULD NOTs.<br> > >> And it seems a lot of this is a carry over from rfc-4860, so in <br> > a sense you are inheriting an approach that<br> > >> was agreed to from an earlier effort.  But I wonder in the back <br> > of my mind, what impact occurs if<br> > >> an implementor doesn't follow the SHOULD?  Does the design break <br> > in supporting PCN?<br> > >> Again, I want to stress that this isnt a show stopper, but I <br> > would appreciate it if you gave it some thought.<br> > ><br> > > Georgios: Yes, in several cases the design might break in supporting PCN.<br> > > This is also the reason of using SHOULD instead of MAY. Do you <br> > want us to explain this in more detail in the draft?<br> ><br> >well, actually, I was more curious as to why a number of these cases <br> >are SHOULD instead of MUST.  Again, the SHOULD's in your document <br> >seem to be a carry-over from rfc-4860 (which set the precedent), so <br> >its a bit unfair for you to explain what was done in an earlier <br> >effort.  I just wanted to make sure you gave some thought to the <br> >subject.  And if things will break if SHOULD is not followed by an <br> >implementer/configuration, then maybe you should be more stringent <br> >and change things to MUST.  Perhaps a brief private conversation <br> >with Francois Le Faucheur will be helpful.<br> ><br> >cheers,<br> ><br> >-ken<br><br> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design <br><br> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design</blockquote><br> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design </blockquote><br> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design </blockquote> <x-sigsep><p></x-sigsep> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design</body> </html> --=====================_287505981==.ALT-- From mohamed.boucadair@orange.com Tue Nov 20 23:12:22 2012 Return-Path: <mohamed.boucadair@orange.com> 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 01BF521F884F for <tsvwg@ietfa.amsl.com>; Tue, 20 Nov 2012 23:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZET9eSlNcBr8 for <tsvwg@ietfa.amsl.com>; Tue, 20 Nov 2012 23:12:21 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0559321F8849 for <tsvwg@ietf.org>; Tue, 20 Nov 2012 23:12:19 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 460122DC359; Wed, 21 Nov 2012 08:12:18 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1E5CF35C05B; Wed, 21 Nov 2012 08:12:18 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Wed, 21 Nov 2012 08:12:12 +0100 From: <mohamed.boucadair@orange.com> To: "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de> Date: Wed, 21 Nov 2012 08:12:11 +0100 Thread-Topic: Questions about draft-geib-tsvwg-diffserv-intercon Thread-Index: Ac3Ht4a6Pjym/pD4T7aeiC7MeouaDA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E9751EE10@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E9751EE10PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: LEVIS Pierre OLNC/OLPS <pierre.levis@orange.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, JACQUENET Christian OLNC/OLN <christian.jacquenet@orange.com> Subject: [tsvwg] Questions about draft-geib-tsvwg-diffserv-intercon X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 21 Nov 2012 07:12:22 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E9751EE10PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Ruediger, I read your draft and I have some questions for clarification: (1) How to position your proposal with regards to RFC5160 (http://tools.iet= f.org/html/rfc5160)? (2) Wouldn't be more appropriate to have a discussion using PDB rather than= PHBs when discussing interconnection matters? (3) Binding two class of services is mainly driven by out-of-band agreement= s. The document makes use of SLA without having a reference to what may be = contained in such agreement. FWIW, we edited a document to help in this are= a (http://tools.ietf.org/html/draft-boucadair-connectivity-provisioning-pro= file-02). Do you see a value in standardizing such profile? Thanks. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F36E9751EE10PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Dus-ascii" http-equiv=3DContent-Type> <META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18702"></HEAD> <BODY> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN class=3D462030007-21112012>D= ear=20 Ruediger,</SPAN></FONT></DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012></SPAN></FONT> </DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN class=3D462030007-21112012>I= read your=20 draft and I have some questions for clarification:</SPAN></FONT></DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012></SPAN></FONT> </DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN class=3D462030007-21112012>(= 1) How to=20 position your proposal with regards to RFC5160 (<A=20 href=3D"http://tools.ietf.org/html/rfc5160">http://tools.ietf.org/html/rfc5= 160</A>)?</SPAN></FONT></DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012></SPAN></FONT> </DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN class=3D462030007-21112012>(= 2) Wouldn't=20 be more appropriate to have a discussion using PDB rather than PHBs when=20 discussing interconnection matters?</SPAN></FONT></DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012></SPAN></FONT> </DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN class=3D462030007-21112012>(= 3) Binding=20 two class of services is mainly driven by out-of-band agreements. The docum= ent=20 makes use of SLA without having a reference to what may be contained in suc= h=20 agreement. FWIW, we edited a document to help in this area (<A=20 href=3D"http://tools.ietf.org/html/draft-boucadair-connectivity-provisionin= g-profile-02">http://tools.ietf.org/html/draft-boucadair-connectivity-provi= sioning-profile-02</A>).=20 Do you see a value in standardizing such profile?</SPAN></FONT></DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012></SPAN></FONT> </DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012></SPAN></FONT> </DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN class=3D462030007-21112012>T= hanks.=20 </SPAN></FONT></DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012></SPAN></FONT> </DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012>Cheers,</SPAN></FONT></DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012>Med</SPAN></FONT></DIV></BODY></HTML> --_000_94C682931C08B048B7A8645303FDC9F36E9751EE10PUEXCB1Bnante_-- From Ruediger.Geib@telekom.de Tue Nov 20 23:55:15 2012 Return-Path: <Ruediger.Geib@telekom.de> 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 10E5021F8667 for <tsvwg@ietfa.amsl.com>; Tue, 20 Nov 2012 23:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkkF-CjpBUeX for <tsvwg@ietfa.amsl.com>; Tue, 20 Nov 2012 23:55:14 -0800 (PST) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9F78721F85D2 for <tsvwg@ietf.org>; Tue, 20 Nov 2012 23:55:11 -0800 (PST) Received: from he113656.emea1.cds.t-internal.com ([10.134.99.16]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 21 Nov 2012 08:55:07 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113656.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 21 Nov 2012 08:55:06 +0100 From: <Ruediger.Geib@telekom.de> To: <mohamed.boucadair@orange.com> Date: Wed, 21 Nov 2012 08:55:05 +0100 Thread-Topic: Questions about draft-geib-tsvwg-diffserv-intercon Thread-Index: Ac3Ht4a6Pjym/pD4T7aeiC7MeouaDAAA9hyg Message-ID: <CA7A7C64CC4ADB458B74477EA99DF6F5A27E45BD@HE111643.EMEA1.CDS.T-INTERNAL.COM> References: <94C682931C08B048B7A8645303FDC9F36E9751EE10@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E9751EE10@PUEXCB1B.nanterre.francetelecom.fr> 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: multipart/alternative; boundary="_000_CA7A7C64CC4ADB458B74477EA99DF6F5A27E45BDHE111643EMEA1CD_" MIME-Version: 1.0 Cc: pierre.levis@orange.com, tsvwg@ietf.org, christian.jacquenet@orange.com Subject: Re: [tsvwg] Questions about draft-geib-tsvwg-diffserv-intercon X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 21 Nov 2012 07:55:15 -0000 --_000_CA7A7C64CC4ADB458B74477EA99DF6F5A27E45BDHE111643EMEA1CD_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Med, thanks for informing me, as I wasn't aware of your work. I didn't yet read RFC 5160, but hope to do so soon. draft-boucadair-connectivity-provisioning-profile is close to operations or= commercial negotiations. I'm not the one to judge whether the company I wo= rk for is interested in standards on that. Regards, R=FCdiger ________________________________ From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Wednesday, November 21, 2012 8:12 AM To: Geib, R=FCdiger Cc: tsvwg@ietf.org; LEVIS Pierre OLNC/OLPS; JACQUENET Christian OLNC/OLN Subject: Questions about draft-geib-tsvwg-diffserv-intercon Dear Ruediger, I read your draft and I have some questions for clarification: (1) How to position your proposal with regards to RFC5160 (http://tools.iet= f.org/html/rfc5160)? (2) Wouldn't be more appropriate to have a discussion using PDB rather than= PHBs when discussing interconnection matters? (3) Binding two class of services is mainly driven by out-of-band agreement= s. The document makes use of SLA without having a reference to what may be = contained in such agreement. FWIW, we edited a document to help in this are= a (http://tools.ietf.org/html/draft-boucadair-connectivity-provisioning-pro= file-02). Do you see a value in standardizing such profile? Thanks. Cheers, Med --_000_CA7A7C64CC4ADB458B74477EA99DF6F5A27E45BDHE111643EMEA1CD_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type= > <META name=3DGENERATOR content=3D"MSHTML 8.00.6001.19258"></HEAD> <BODY> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color=3D= #0000ff=20 size=3D2 face=3DArial>Dear Med,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color=3D= #0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color=3D= #0000ff=20 size=3D2 face=3DArial>thanks for informing me, as I wasn't aware of your=20 work.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color=3D= #0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color=3D= #0000ff=20 size=3D2 face=3DArial>I didn't yet read RFC 5160, but hope to do so=20 soon.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color=3D= #0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color=3D= #0000ff=20 size=3D2 face=3DArial>draft-boucadair-connectivity-provisioning-profile is = close to=20 operations or commercial negotiations. I'm not the one to judge whether&nbs= p;the=20 company I work for is interested in standards on that.</FONT></SPAN></= DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color=3D= #0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color=3D= #0000ff=20 size=3D2 face=3DArial>Regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color=3D= #0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color=3D= #0000ff=20 size=3D2 face=3DArial>R=FCdiger</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color=3D= #0000ff=20 size=3D2 face=3D"Courier New"></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> </DIV> <DIV dir=3Dltr align=3Dleft><FONT size=3D2 face=3DTahoma><B>From:</B>=20 mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 <BR><B>Sent:</B> Wednesday, November 21, 2012 8:12 AM<BR><B>To:</B> Geib,=20 R=FCdiger<BR><B>Cc:</B> tsvwg@ietf.org; LEVIS Pierre OLNC/OLPS; JACQUENET=20 Christian OLNC/OLN<BR><B>Subject:</B> Questions about=20 draft-geib-tsvwg-diffserv-intercon<BR></FONT><BR></DIV> <DIV></DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN class=3D462030007-21112012>D= ear=20 Ruediger,</SPAN></FONT></DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012></SPAN></FONT> </DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN class=3D462030007-21112012>I= read your=20 draft and I have some questions for clarification:</SPAN></FONT></DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012></SPAN></FONT> </DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN class=3D462030007-21112012>(= 1) How to=20 position your proposal with regards to RFC5160 (<A=20 href=3D"http://tools.ietf.org/html/rfc5160">http://tools.ietf.org/html/rfc5= 160</A>)?</SPAN></FONT></DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012></SPAN></FONT> </DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN class=3D462030007-21112012>(= 2) Wouldn't=20 be more appropriate to have a discussion using PDB rather than PHBs when=20 discussing interconnection matters?</SPAN></FONT></DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012></SPAN></FONT> </DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN class=3D462030007-21112012>(= 3) Binding=20 two class of services is mainly driven by out-of-band agreements. The docum= ent=20 makes use of SLA without having a reference to what may be contained in suc= h=20 agreement. FWIW, we edited a document to help in this area (<A=20 href=3D"http://tools.ietf.org/html/draft-boucadair-connectivity-provisionin= g-profile-02">http://tools.ietf.org/html/draft-boucadair-connectivity-provi= sioning-profile-02</A>).=20 Do you see a value in standardizing such profile?</SPAN></FONT></DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012></SPAN></FONT> </DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012></SPAN></FONT> </DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN class=3D462030007-21112012>T= hanks.=20 </SPAN></FONT></DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012></SPAN></FONT> </DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012>Cheers,</SPAN></FONT></DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012>Med</SPAN></FONT></DIV></BODY></HTML> --_000_CA7A7C64CC4ADB458B74477EA99DF6F5A27E45BDHE111643EMEA1CD_-- From mohamed.boucadair@orange.com Wed Nov 21 00:23:48 2012 Return-Path: <mohamed.boucadair@orange.com> 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 9652121F8835 for <tsvwg@ietfa.amsl.com>; Wed, 21 Nov 2012 00:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TR-kiXqrztqB for <tsvwg@ietfa.amsl.com>; Wed, 21 Nov 2012 00:23:48 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8741A21F883C for <tsvwg@ietf.org>; Wed, 21 Nov 2012 00:23:47 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 2D6153245A3; Wed, 21 Nov 2012 09:23:46 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id F082435C048; Wed, 21 Nov 2012 09:23:45 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 21 Nov 2012 09:23:43 +0100 From: <mohamed.boucadair@orange.com> To: "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de> Date: Wed, 21 Nov 2012 09:23:42 +0100 Thread-Topic: Questions about draft-geib-tsvwg-diffserv-intercon Thread-Index: Ac3Ht4a6Pjym/pD4T7aeiC7MeouaDAAA9hygAAFKBjA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E9751EE6F@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E9751EE10@PUEXCB1B.nanterre.francetelecom.fr> <CA7A7C64CC4ADB458B74477EA99DF6F5A27E45BD@HE111643.EMEA1.CDS.T-INTERNAL.COM> In-Reply-To: <CA7A7C64CC4ADB458B74477EA99DF6F5A27E45BD@HE111643.EMEA1.CDS.T-INTERNAL.COM> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E9751EE6FPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.11.21.74515 Cc: LEVIS Pierre OLNC/OLPS <pierre.levis@orange.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, JACQUENET Christian OLNC/OLN <christian.jacquenet@orange.com> Subject: Re: [tsvwg] Questions about draft-geib-tsvwg-diffserv-intercon X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 21 Nov 2012 08:23:48 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E9751EE6FPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Thanks for your answer. FWIW, draft-boucadair-connectivity-provisioning-profile does not include co= mmercial negotiations but it focuses on technical aspects of IP connectivit= y provisioning. More details about its use is elaborated in the Introductio= n section: http://tools.ietf.org/html/draft-boucadair-connectivity-provisio= ning-profile-02#section-1. The document does not assume Diffserv as the onl= y solution to provide differentiated connectivity services but assumes the = tweaking of various techniques in several dimension may lead to differentia= ted IP transfer service (e.g., routing level, forwarding level, etc.). Cheers, Med ________________________________ De : Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] Envoy=E9 : mercredi 21 novembre 2012 08:55 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : tsvwg@ietf.org; LEVIS Pierre OLNC/OLPS; JACQUENET Christian OLNC/OLN; = JOBERT Sebastien OLNC/OLN Objet : RE: Questions about draft-geib-tsvwg-diffserv-intercon Dear Med, thanks for informing me, as I wasn't aware of your work. I didn't yet read RFC 5160, but hope to do so soon. draft-boucadair-connectivity-provisioning-profile is close to operations or= commercial negotiations. I'm not the one to judge whether the company I wo= rk for is interested in standards on that. Regards, R=FCdiger ________________________________ From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Wednesday, November 21, 2012 8:12 AM To: Geib, R=FCdiger Cc: tsvwg@ietf.org; LEVIS Pierre OLNC/OLPS; JACQUENET Christian OLNC/OLN Subject: Questions about draft-geib-tsvwg-diffserv-intercon Dear Ruediger, I read your draft and I have some questions for clarification: (1) How to position your proposal with regards to RFC5160 (http://tools.iet= f.org/html/rfc5160)? (2) Wouldn't be more appropriate to have a discussion using PDB rather than= PHBs when discussing interconnection matters? (3) Binding two class of services is mainly driven by out-of-band agreement= s. The document makes use of SLA without having a reference to what may be = contained in such agreement. FWIW, we edited a document to help in this are= a (http://tools.ietf.org/html/draft-boucadair-connectivity-provisioning-pro= file-02). Do you see a value in standardizing such profile? Thanks. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F36E9751EE6FPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type= > <META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18702"></HEAD> <BODY> <DIV dir=3Dltr align=3Dleft><SPAN class=3D086381608-21112012><FONT color=3D= #0000ff=20 size=3D2 face=3D"Courier New">Re-,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D086381608-21112012><FONT color=3D= #0000ff=20 size=3D2 face=3D"Courier New"></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D086381608-21112012><FONT color=3D= #0000ff=20 size=3D2 face=3D"Courier New">Thanks for your answer. </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D086381608-21112012><FONT color=3D= #0000ff=20 size=3D2 face=3D"Courier New"></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D086381608-21112012><FONT color=3D= #0000ff=20 size=3D2><FONT face=3D"Courier New">FWIW, <SPAN class=3D355433907-21112012>= <FONT=20 color=3D#0000ff><FONT size=3D2>draft-boucadair-connectivity-provisioning-pr= ofile=20 does not include commercial negotiations but it focuses on technical=20 aspects of IP connectivity provisioning. More details about its use is=20 elaborated in the Introduction section: <A=20 href=3D"http://tools.ietf.org/html/draft-boucadair-connectivity-provisionin= g-profile-02#section-1">http://tools.ietf.org/html/draft-boucadair-connecti= vity-provisioning-profile-02#section-1</A>.=20 The document does not assume Diffserv as the only solution to provide=20 differentiated connectivity services but assumes the tweaking of various=20 techniques in several dimension may lead to differentiated IP transfer serv= ice=20 (e.g., routing level, forwarding level,=20 etc.).</FONT></FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D086381608-21112012><FONT color=3D= #0000ff=20 size=3D2 face=3D"Courier New"><SPAN=20 class=3D355433907-21112012></SPAN></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D086381608-21112012><FONT color=3D= #0000ff=20 size=3D2 face=3D"Courier New">Cheers,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D086381608-21112012><FONT color=3D= #0000ff=20 size=3D2 face=3D"Courier New">Med</FONT></SPAN></DIV><BR> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5p= x; MARGIN-RIGHT: 0px"=20 dir=3Dltr> <DIV dir=3Dltr lang=3Dfr class=3DOutlookMessageHeader align=3Dleft> <HR tabIndex=3D-1> <FONT size=3D2 face=3DTahoma><B>De :</B> Ruediger.Geib@telekom.de=20 [mailto:Ruediger.Geib@telekom.de] <BR><B>Envoy=E9 :</B> mercredi 21= =20 novembre 2012 08:55<BR><B>=C0 :</B> BOUCADAIR Mohamed=20 OLNC/OLN<BR><B>Cc :</B> tsvwg@ietf.org; LEVIS Pierre OLNC/OLPS; JACQ= UENET=20 Christian OLNC/OLN; JOBERT Sebastien OLNC/OLN<BR><B>Objet :</B> RE:= =20 Questions about draft-geib-tsvwg-diffserv-intercon<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color= =3D#0000ff=20 size=3D2 face=3DArial>Dear Med,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color= =3D#0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color= =3D#0000ff=20 size=3D2 face=3DArial>thanks for informing me, as I wasn't aware of your= =20 work.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color= =3D#0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color= =3D#0000ff=20 size=3D2 face=3DArial>I didn't yet read RFC 5160, but hope to do so=20 soon.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color= =3D#0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT face= =3DArial><FONT=20 color=3D#0000ff><FONT size=3D2>draft-boucadair-connectivity-provisioning-= profile=20 is close to operations or commercial negotiations. I'm not the one to jud= ge=20 whether the company I work for is interested in standards on=20 that.</FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT face= =3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN class=3D086381608-21112012><FONT=20 face=3D"Courier New"></FONT></SPAN></FONT></FONT></FONT></SPAN> </DI= V> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color= =3D#0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color= =3D#0000ff=20 size=3D2 face=3DArial>Regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color= =3D#0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color= =3D#0000ff=20 size=3D2 face=3DArial>R=FCdiger</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D355433907-21112012><FONT color= =3D#0000ff=20 size=3D2 face=3D"Courier New"></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> </DIV> <DIV dir=3Dltr align=3Dleft><FONT size=3D2 face=3DTahoma><B>From:</B>=20 mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 <BR><B>Sent:</B> Wednesday, November 21, 2012 8:12 AM<BR><B>To:</B> Geib,= =20 R=FCdiger<BR><B>Cc:</B> tsvwg@ietf.org; LEVIS Pierre OLNC/OLPS; JACQUENET= =20 Christian OLNC/OLN<BR><B>Subject:</B> Questions about=20 draft-geib-tsvwg-diffserv-intercon<BR></FONT><BR></DIV> <DIV></DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN class=3D462030007-21112012= >Dear=20 Ruediger,</SPAN></FONT></DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012></SPAN></FONT> </DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN class=3D462030007-21112012= >I read=20 your draft and I have some questions for clarification:</SPAN></FONT></DI= V> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012></SPAN></FONT> </DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN class=3D462030007-21112012= >(1) How to=20 position your proposal with regards to RFC5160 (<A=20 href=3D"http://tools.ietf.org/html/rfc5160">http://tools.ietf.org/html/rf= c5160</A>)?</SPAN></FONT></DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012></SPAN></FONT> </DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN class=3D462030007-21112012= >(2)=20 Wouldn't be more appropriate to have a discussion using PDB rather than P= HBs=20 when discussing interconnection matters?</SPAN></FONT></DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012></SPAN></FONT> </DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN class=3D462030007-21112012= >(3)=20 Binding two class of services is mainly driven by out-of-band agreements.= The=20 document makes use of SLA without having a reference to what may be conta= ined=20 in such agreement. FWIW, we edited a document to help in this area (<A=20 href=3D"http://tools.ietf.org/html/draft-boucadair-connectivity-provision= ing-profile-02">http://tools.ietf.org/html/draft-boucadair-connectivity-pro= visioning-profile-02</A>).=20 Do you see a value in standardizing such profile?</SPAN></FONT></DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012></SPAN></FONT> </DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012></SPAN></FONT> </DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN class=3D462030007-21112012= >Thanks.=20 </SPAN></FONT></DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012></SPAN></FONT> </DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012>Cheers,</SPAN></FONT></DIV> <DIV><FONT size=3D2 face=3D"Courier New"><SPAN=20 class=3D462030007-21112012>Med</SPAN></FONT></DIV></BLOCKQUOTE></BODY></H= TML> --_000_94C682931C08B048B7A8645303FDC9F36E9751EE6FPUEXCB1Bnante_-- From anuragb@cisco.com Tue Nov 13 12:14:22 2012 Return-Path: <anuragb@cisco.com> 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 77DC021F87CA for <tsvwg@ietfa.amsl.com>; Tue, 13 Nov 2012 12:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfZDqykxHzl9 for <tsvwg@ietfa.amsl.com>; Tue, 13 Nov 2012 12:14:20 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 54B4421F8618 for <tsvwg@ietf.org>; Tue, 13 Nov 2012 12:14:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21702; q=dns/txt; s=iport; t=1352837660; x=1354047260; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=bSH7ph8WzhjgH9flPQFGsqFYIIUNiusYbVfwWkQpp2M=; b=CGEPEbs89l5kFAGdEMZv7hiuRLYI/4Olgfyrn3LW9XBXoVBzKFMLNSEB 6YDVcaKlvuF1siQ2+aAWaQ0si8x4+kEmNjmW2JXB2pekZknKQ0FgzrcSQ eg9PaVrXH/1Nseb2akAtlSa+rxzf1/nChfcnwm5LWLY7NyTpY/+rBbPcb I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADKpolCtJXG8/2dsb2JhbABEgknBOIEIgh4BAQEDARIBVREFDQEIEQECAQIBCh05FAMGCAIEAQ0FCBqHYgaaaI9lkCuMKoVzYQOkVIFrgm+BZBce X-IronPort-AV: E=McAfee;i="5400,1158,6895"; a="142012336" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 13 Nov 2012 20:14:19 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qADKEJUD022195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Nov 2012 20:14:19 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.49]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Tue, 13 Nov 2012 14:14:18 -0600 From: "Anurag Bhargava (anuragb)" <anuragb@cisco.com> To: "karagian@cs.utwente.nl" <karagian@cs.utwente.nl>, "bob.briscoe@bt.com" <bob.briscoe@bt.com> Thread-Topic: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 Thread-Index: AQHNuG54ycIsorhLZEWpePkDEVZ5aJfab4AAgAElDQCAAAEogIAGJnpJgAHBGICABNnhgA== Date: Tue, 13 Nov 2012 20:14:17 +0000 Message-ID: <E728D0E3C41E644A96A7CCA61863BED4081DE009@xmb-aln-x12.cisco.com> In-Reply-To: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.116.186.142] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19360.002 x-tm-as-result: No--64.034100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E728D0E3C41E644A96A7CCA61863BED4081DE009xmbalnx12ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 21 Nov 2012 11:30:18 -0800 Cc: "philip.eardley@bt.com" <philip.eardley@bt.com>, "Anurag Bhargava \(anuragb\)" <anuragb@cisco.com>, "tsvwg@ietf.org" <tsvwg@ietf.org> Subject: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 13 Nov 2012 20:14:22 -0000 --_000_E728D0E3C41E644A96A7CCA61863BED4081DE009xmbalnx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bob, Thanks for the comments. If U have some text that will be great els I have= also started putting some text on the topic U brought up. May be we can conference after US thanksgiving week and collaborate the te= xt and try to move forward. Please let us know what might be a good time and I can schedule a Webex co= nf. Thx -Anurag From: "karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl>" <karagian@cs.= utwente.nl<mailto:karagian@cs.utwente.nl>> Date: Saturday, November 10, 2012 8:10 AM To: "bob.briscoe@bt.com<mailto:bob.briscoe@bt.com>" <bob.briscoe@bt.com<mai= lto:bob.briscoe@bt.com>> Cc: "carlberg@g11.org.uk<mailto:carlberg@g11.org.uk>" <carlberg@g11.org.uk<= mailto:carlberg@g11.org.uk>>, Anurag Bhargava <anuragb@cisco.com<mailto:anu= ragb@cisco.com>>, "tsvwg@ietf.org<mailto:tsvwg@ietf.org>" <tsvwg@ietf.org<m= ailto:tsvwg@ietf.org>>, "philip.eardley@bt.com<mailto:philip.eardley@bt.com= >" <philip.eardley@bt.com<mailto:philip.eardley@bt.com>> Subject: RE: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 Hi Bob, Thanks very much for the comments! I think that they are very useful! It will be very beneficiary for the fast progress of this draft if you woul= d like to contribute as a co-author to this draft and write this additional= section that describes "that the PCN-ingress can refer flow admission and termination decisions to a central decision point (using e.g. COPS), which = will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingr= ess could itself be the policy decision point.)" Best regards, Georgios ________________________________ Van: Bob Briscoe [bob.briscoe@bt.com<mailto:bob.briscoe@bt.com>] Verzonden: vrijdag 9 november 2012 16:33 To: Karagiannis, G. (EWI) Cc: carlberg@g11.org.uk<mailto:carlberg@g11.org.uk>; anuragb@cisco.com<mail= to:anuragb@cisco.com>; tsvwg@ietf.org<mailto:tsvwg@ietf.org>; EARDLEY, Phil Onderwerp: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 Georgios, I shall post my full review of this draft in the next few days (needs typing up - currently scribbled on a paper copy). This email is solely in response to your answer about on-path vs off-path policy. At 18:55 04/11/2012, karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl> = wrote: >So in this case an additional signaling protocol will be >needed to be specified that covers the signaling between the >PCN-egress-node and the centralized node >and between PCN-ingress-node and the centralized node. >In PCN we decdided to only focus on the specification of the >signaling protocol that completes the >feedback loop from PCN-egress-node to PCN-ingress-node and to focus >on the signaling protocol >used between the edge nodes and the centralized node. When I/we originally designed CL-PCN over RSVP (2005), the idea was that it would fit with the policy-based admission control (PBAC) architecture of RFC2753. In this architecture, an Intserv node at the ingress to a domain is the policy enforcement point (PEP), and it refers to a logically centralised 'policy decision point' (PDP) for decisions on which flows to block/terminate, typically using COPS. To make this doc fit the PBAC framework, all we have to do is: * Describe the PCN-ingress only as the PCN-ingress and not as the decision point (find 'decision' throughout doc and fix). * Add a section saying the PCN-ingress can refer flow admission and termination decisions to a central decision point (using e.g. COPS), which will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingress could itself be the policy decision point.) * Refer to this new PBAC section from Section 3.11 giving the admission decision procedure. * Some people might think this means COPS will need new protocol elements to carry PCN marking rates to the policy decision point. But PCN marking rates are irrelevant to the policy decision: the PCN-ingress just uses PCN to determine whether it needs to block or terminate, and it refers to the policy decision point for which flows to block/terminate. * Unfortunately, neither of the two PCN system descriptions [RFC6661, RFC6662] describe a PBAC-based case. The architecture [RFC5559] refers to the PBAC framework [RFC2753] but unfortunately doesn't spell out how it fits. Originally, I referenced PBAC from RFC5559, but just as the PCN w-g was closing I realised that (some?) others in the PCN w-g were working under the assumption that the only way to talk to a centralised policy node was from the egress, possibly without being aware of the contents of RFC2753. I think it's OK to introduce a new architectural arrangement in this RSVP doc, given RFC2753 is specific to the way RSVP works. Bob At 12:28 05/11/2012, karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl> = wrote: >Hi Ken, > >Thank you very much! >We will try to catch Francois and discuss the last (in line) issue with hi= m! > >Best regards, >Georgios > >________________________________________ >Van: ken carlberg [carlberg@g11.org.uk<mailto:carlberg@g11.org.uk>] >Verzonden: maandag 5 november 2012 13:23 >To: Karagiannis, G. (EWI) >Cc: tsvwg@ietf.org<mailto:tsvwg@ietf.org>; anuragb@cisco.com<mailto:anurag= b@cisco.com> >Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03 > >Georgios, > > > Georgios: We will try to explain the rationale of why we consider > that RSVP can only be used for the situation that the > > decision point is collocated with the PCN-ingress-node. The main > reason of this is that in the case that the > > decision point is collocated with the PCN-ingress-node,the > required signaling protocol used to complete a > > feedback loop from egress to ingress can be an entirely on-path > protocol, like what RSVP is. > > In the situation that the the decision point is a centralized > node, then the required signaling protocol > > can be a combination of an on-path and off-path protocol. This is > because the > > decision point might not be located on the data path! So in this > case an additional signaling protocol will be > > needed to be specified that covers the signaling between the > PCN-egress-node and the centralized node > > and between PCN-ingress-node and the centralized node. > > In PCN we decdided to only focus on the specification of the > signaling protocol that completes the > > feedback loop from PCN-egress-node to PCN-ingress-node and to > focus on the signaling protocol > > used between the edge nodes and the centralized node. > > This is also the reason of why PCN WG decided to only focus on > the situation that the decision point is > > collocated with the PCN-ingress-node. > >Great, this is helpful, and this is the information that needs to be >in the draft. > > >> 6) This comment is just for you to contemplate -- I'm not > expecting any changes. > >> I noticed that you have a fair number of SHOULD, and some SHOULD NOTs. > >> And it seems a lot of this is a carry over from rfc-4860, so in > a sense you are inheriting an approach that > >> was agreed to from an earlier effort. But I wonder in the back > of my mind, what impact occurs if > >> an implementor doesn't follow the SHOULD? Does the design break > in supporting PCN? > >> Again, I want to stress that this isnt a show stopper, but I > would appreciate it if you gave it some thought. > > > > Georgios: Yes, in several cases the design might break in supporting PC= N. > > This is also the reason of using SHOULD instead of MAY. Do you > want us to explain this in more detail in the draft? > >well, actually, I was more curious as to why a number of these cases >are SHOULD instead of MUST. Again, the SHOULD's in your document >seem to be a carry-over from rfc-4860 (which set the precedent), so >its a bit unfair for you to explain what was done in an earlier >effort. I just wanted to make sure you gave some thought to the >subject. And if things will break if SHOULD is not followed by an >implementer/configuration, then maybe you should be more stringent >and change things to MUST. Perhaps a brief private conversation >with Francois Le Faucheur will be helpful. > >cheers, > >-ken ________________________________________________________________ Bob Briscoe, BT Innovate & Design --_000_E728D0E3C41E644A96A7CCA61863BED4081DE009xmbalnx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <B0E26A3AEF73A948BA11023D8B4FE5B4@cisco.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami= ly: Calibri, sans-serif; "> <div>Hi Bob,</div> <div> Thanks for the comments. If U have some text that will be great = els I have also started putting some text on the topic U brought up.</div> <div> May be we can conference after US thanksgiving week and collabor= ate the text and try to move forward.</div> <div><br> </div> <div> Please let us know what might be a good time and I can schedule = a Webex conf.</div> <div><br> </div> <div>Thx</div> <div>-Anurag</div> <div><br> </div> <span id=3D"OLK_SRC_BODY_SECTION"> <div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b= lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:= 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;= BORDER-RIGHT: medium none; PADDING-TOP: 3pt"> <span style=3D"font-weight:bold">From: </span>"<a href=3D"mailto:karag= ian@cs.utwente.nl">karagian@cs.utwente.nl</a>" <<a href=3D"mailto:k= aragian@cs.utwente.nl">karagian@cs.utwente.nl</a>><br> <span style=3D"font-weight:bold">Date: </span>Saturday, November 10, 2012 8= :10 AM<br> <span style=3D"font-weight:bold">To: </span>"<a href=3D"mailto:bob.bri= scoe@bt.com">bob.briscoe@bt.com</a>" <<a href=3D"mailto:bob.briscoe= @bt.com">bob.briscoe@bt.com</a>><br> <span style=3D"font-weight:bold">Cc: </span>"<a href=3D"mailto:carlber= g@g11.org.uk">carlberg@g11.org.uk</a>" <<a href=3D"mailto:carlberg@= g11.org.uk">carlberg@g11.org.uk</a>>, Anurag Bhargava <<a href=3D"mai= lto:anuragb@cisco.com">anuragb@cisco.com</a>>, "<a href=3D"mailto:t= svwg@ietf.org">tsvwg@ietf.org</a>" <<a href=3D"mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>>, "<a hre= f=3D"mailto:philip.eardley@bt.com">philip.eardley@bt.com</a>" <<a h= ref=3D"mailto:philip.eardley@bt.com">philip.eardley@bt.com</a>><br> <span style=3D"font-weight:bold">Subject: </span>RE: [tsvwg] draft-ietf-tsv= wg-rsvp-pcn-03<br> </div> <div><br> </div> <div dir=3D"ltr" xmlns:o=3D"urn:schemas-microsoft-com:office:office"><style= >.EmailQuote { BORDER-LEFT: #800000 2px solid; PADDING-LEFT: 4pt; MARGIN-LEFT: 1pt } </style><style id=3D"owaParaStyle">P { MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px } </style> <div ocsi=3D"0" fpstyle=3D"1"> <div style=3D"FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: #000000; FONT-SIZ= E: 10pt"> <p><span style=3D"color: black; font-size: 10pt; font-family: Tahoma, sans-= serif; " lang=3D"EN-US">Hi Bob,<o:p></o:p></span></p> <p><span style=3D"color: black; font-size: 10pt; font-family: Tahoma, sans-= serif; " lang=3D"EN-US"><o:p> </o:p></span></p> <p><span style=3D"color: black; font-size: 10pt; font-family: Tahoma, sans-= serif; " lang=3D"EN-US">Thanks very much for the comments! I think that the= y are very useful! <o:p></o:p></span></p> <p><span style=3D"color: black; font-size: 10pt; font-family: Tahoma, sans-= serif; " lang=3D"EN-US"><o:p> </o:p></span></p> <p><span style=3D"color: black; font-size: 10pt; font-family: Tahoma, sans-= serif; " lang=3D"EN-US">It will be very beneficiary for the fast progr= ess of this draft if you would like to contribute as a co-author to th= is draft and write this additional section that describes "that the PCN-ingress can refer flow admission and <br> termination decisions to a central decision point (using e.g. COPS), which = will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingr= ess could itself be the policy decision point.)"<o:p></o:p></span></p> <p><span style=3D"color: black; font-size: 10pt; font-family: Tahoma, sans-= serif; " lang=3D"EN-US"><o:p> </o:p></span></p> <p><span style=3D"color: black; font-size: 10pt; font-family: Tahoma, sans-= serif; " lang=3D"EN-US">Best regards,<o:p></o:p></span></p> <p><span style=3D"color: black; font-size: 10pt; font-family: Tahoma, sans-= serif; " lang=3D"EN-US">Georgios<o:p></o:p></span></p> <p><span style=3D"color: black; font-size: 10pt; font-family: Tahoma, sans-= serif; " lang=3D"EN-US"><o:p> </o:p></span></p> <div> <hr tabindex=3D"-1"> <div id=3D"x_divRplyFwdMsg"><font color=3D"#000000" size=3D"2" face=3D"Taho= ma"><b>Van:</b> Bob Briscoe [<a href=3D"mailto:bob.briscoe@bt.com">bob.bris= coe@bt.com</a>]<br> <b>Verzonden:</b> vrijdag 9 november 2012 16:33<br> <b>To:</b> Karagiannis, G. (EWI)<br> <b>Cc:</b> <a href=3D"mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>; = <a href=3D"mailto:anuragb@cisco.com"> anuragb@cisco.com</a>; <a href=3D"mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>= ; EARDLEY, Phil<br> <b>Onderwerp:</b> Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br> </font><br> </div> <div></div> </div> <font size=3D"2"><span style=3D"FONT-SIZE: 10pt"> <div class=3D"PlainText">Georgios,<br> <br> I shall post my full review of this draft in the next few days (needs <br> typing up - currently scribbled on a paper copy). This email is <br> solely in response to your answer about on-path vs off-path policy.<br> <br> At 18:55 04/11/2012, <a href=3D"mailto:karagian@cs.utwente.nl">karagian@cs.= utwente.nl</a> wrote:<br> >So in this case an additional signaling protocol will be<br> >needed to be specified that covers the signaling between the <br> >PCN-egress-node and the centralized node<br> >and between PCN-ingress-node and the centralized node.<br> >In PCN we decdided to only focus on the specification of the <br> >signaling protocol that completes the<br> >feedback loop from PCN-egress-node to PCN-ingress-node and to focus <br= > >on the signaling protocol<br> >used between the edge nodes and the centralized node.<br> <br> When I/we originally designed CL-PCN over RSVP (2005), the idea was <br> that it would fit with the policy-based admission control (PBAC) <br> architecture of RFC2753. In this architecture, an Intserv node at the <br> ingress to a domain is the policy enforcement point (PEP), and it <br> refers to a logically centralised 'policy decision point' (PDP) for <br> decisions on which flows to block/terminate, typically using COPS.<br> <br> To make this doc fit the PBAC framework, all we have to do is:<br> * Describe the PCN-ingress only as the PCN-ingress and not as the <br> decision point (find 'decision' throughout doc and fix).<br> * Add a section saying the PCN-ingress can refer flow admission and <br> termination decisions to a central decision point (using e.g. COPS), <br> which will respond to the PCN-ingress as per RFC2753. (Alternatively <br> the PCN-ingress could itself be the policy decision point.)<br> * Refer to this new PBAC section from Section 3.11 giving the <br> admission decision procedure.<br> <br> * Some people might think this means COPS will need new protocol <br> elements to carry PCN marking rates to the policy decision point. But <br> PCN marking rates are irrelevant to the policy decision: the <br> PCN-ingress just uses PCN to determine whether it needs to block or <br> terminate, and it refers to the policy decision point for which flows <br> to block/terminate.<br> <br> * Unfortunately, neither of the two PCN system descriptions [RFC6661, <br> RFC6662] describe a PBAC-based case. The architecture [RFC5559] <br> refers to the PBAC framework [RFC2753] but unfortunately doesn't <br> spell out how it fits. Originally, I referenced PBAC from RFC5559, <br> but just as the PCN w-g was closing I realised that (some?) others in <br> the PCN w-g were working under the assumption that the only way to <br> talk to a centralised policy node was from the egress, possibly <br> without being aware of the contents of RFC2753.<br> <br> I think it's OK to introduce a new architectural arrangement in this <br> RSVP doc, given RFC2753 is specific to the way RSVP works.<br> <br> <br> Bob<br> <br> <br> <br> At 12:28 05/11/2012, <a href=3D"mailto:karagian@cs.utwente.nl">karagian@cs.= utwente.nl</a> wrote:<br> >Hi Ken,<br> ><br> >Thank you very much!<br> >We will try to catch Francois and discuss the last (in line) issue with= him!<br> ><br> >Best regards,<br> >Georgios<br> ><br> >________________________________________<br> >Van: ken carlberg [<a href=3D"mailto:carlberg@g11.org.uk">carlberg@g11.= org.uk</a>]<br> >Verzonden: maandag 5 november 2012 13:23<br> >To: Karagiannis, G. (EWI)<br> >Cc: <a href=3D"mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>; <a href=3D"ma= ilto:anuragb@cisco.com"> anuragb@cisco.com</a><br> >Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03<br> ><br> >Georgios,<br> ><br> > > Georgios: We will try to explain the rationale of why we consider= <br> > that RSVP can only be used for the situation that the<br> > > decision point is collocated with the PCN-ingress-node. The main = <br> > reason of this is that in the case that the<br> > > decision point is collocated with the PCN-ingress-node,the <br> > required signaling protocol used to complete a<br> > > feedback loop from egress to ingress can be an entirely on-path <= br> > protocol, like what RSVP is.<br> > > In the situation that the the decision point is a centralized <br= > > node, then the required signaling protocol<br> > > can be a combination of an on-path and off-path protocol. This is= <br> > because the<br> > > decision point might not be located on the data path! So in this = <br> > case an additional signaling protocol will be<br> > > needed to be specified that covers the signaling between the <br> > PCN-egress-node and the centralized node<br> > > and between PCN-ingress-node and the centralized node.<br> > > In PCN we decdided to only focus on the specification of the <br> > signaling protocol that completes the<br> > > feedback loop from PCN-egress-node to PCN-ingress-node and to <br= > > focus on the signaling protocol<br> > > used between the edge nodes and the centralized node.<br> > > This is also the reason of why PCN WG decided to only focus on <b= r> > the situation that the decision point is<br> > > collocated with the PCN-ingress-node.<br> ><br> >Great, this is helpful, and this is the information that needs to be <b= r> >in the draft.<br> ><br> > >> 6) This comment is just for you to contemplate -- I'm not <br= > > expecting any changes.<br> > >> I noticed that you have a fair number of SHOULD, and some SHO= ULD NOTs.<br> > >> And it seems a lot of this is a carry over from rfc-4860, so = in <br> > a sense you are inheriting an approach that<br> > >> was agreed to from an earlier effort.  But I wonder in t= he back <br> > of my mind, what impact occurs if<br> > >> an implementor doesn't follow the SHOULD?  Does the desi= gn break <br> > in supporting PCN?<br> > >> Again, I want to stress that this isnt a show stopper, but I = <br> > would appreciate it if you gave it some thought.<br> > ><br> > > Georgios: Yes, in several cases the design might break in support= ing PCN.<br> > > This is also the reason of using SHOULD instead of MAY. Do you <b= r> > want us to explain this in more detail in the draft?<br> ><br> >well, actually, I was more curious as to why a number of these cases <b= r> >are SHOULD instead of MUST.  Again, the SHOULD's in your document = <br> >seem to be a carry-over from rfc-4860 (which set the precedent), so <br= > >its a bit unfair for you to explain what was done in an earlier <br> >effort.  I just wanted to make sure you gave some thought to the <= br> >subject.  And if things will break if SHOULD is not followed by an= <br> >implementer/configuration, then maybe you should be more stringent <br> >and change things to MUST.  Perhaps a brief private conversation <= br> >with Francois Le Faucheur will be helpful.<br> ><br> >cheers,<br> ><br> >-ken<br> <br> ________________________________________________________________<br> Bob Briscoe,          &nb= sp;            =          BT Innovate & Design <= br> <br> </div> </span></font></div> </div> </div> </span> </body> </html> --_000_E728D0E3C41E644A96A7CCA61863BED4081DE009xmbalnx12ciscoc_-- From tom.taylor.stds@gmail.com Thu Nov 15 08:42:56 2012 Return-Path: <tom.taylor.stds@gmail.com> 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 C9BEA21F86D1; Thu, 15 Nov 2012 08:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXZr6AGSG2sg; Thu, 15 Nov 2012 08:42:56 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 23CA921F869B; Thu, 15 Nov 2012 08:42:56 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so2692324iec.31 for <multiple recipients>; Thu, 15 Nov 2012 08:42:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=2cZm8Yo1jgdg9mjfF+JxotGUnDMp2wvcDkrzFWrLPWU=; b=Gr6TImeq/0L35brJcJncnJFuW332vUfieD1rtHI2z81XEEATy3SWbD2D1Usa7BzSmI 5huiAqqgvY8RwV766M21MlLRndHP6tVl8JCgScpvup/EV/kmkxRnZIj5hJSIDIXYQo8N HGk5AtnH/IWe0po2C1+HSKlwMUePheSTwAsL8fvALjrz/iV7KuiOiUi536By5lWKcOuf W3e1UUqlM49ZtSyHAcCsM6dt9OKIa9S42lH67uMoOqeG3O3oxRTlowz8jdOo8orLsBXA VCrmetiIFOjOHXYbXqp4c0XJ3mKpAs8Q5j13ObNGSD+Inp3sdgXT9nzw2kNXl/aJAx0L iyng== Received: by 10.50.152.196 with SMTP id va4mr615332igb.13.1352997775618; Thu, 15 Nov 2012 08:42:55 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-12-215.tor.primus.ca. [173.206.12.215]) by mx.google.com with ESMTPS id bg10sm3996238igc.6.2012.11.15.08.42.53 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 08:42:54 -0800 (PST) Message-ID: <50A51B8C.4010806@gmail.com> Date: Thu, 15 Nov 2012 11:42:52 -0500 From: Tom Taylor <tom.taylor.stds@gmail.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Bob Briscoe <bob.briscoe@bt.com> References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <E728D0E3C41E644A96A7CCA61863BED4081DE009@xmb-aln-x12.cisco.com> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> <FF1A9612A94D5C4A81ED7DE1039AB80F2ED8FEDF@EXMBX04.ad.utwente.nl> <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> In-Reply-To: <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 121115-0, 15/11/2012), Outbound message X-Antivirus-Status: Clean X-Mailman-Approved-At: Wed, 21 Nov 2012 11:30:39 -0800 Cc: PCN IETF list <pcn@ietf.org>, anuragb@cisco.com, tsvwg@ietf.org, rsvp-dir@ietfa.amsl.com Subject: Re: [tsvwg] [PCN] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 15 Nov 2012 16:42:56 -0000 I'm not sure the semantics of the PCN information -- particularly as it relates to flow termination -- are correct without some sort of concept of aggregation. Or can you really define an RSVP object that has semantics "Never mind the SESSION in this message, I'm related to every flow with the same first hop"? On 15/11/2012 8:07 AM, Bob Briscoe wrote: > Georgios, Anurag, > > Below is the main point of my review, arguing that aggregate > reservations are redundant. I'm reviewing as: > - a member of the RSVP directorate > - one of the early PCN design team > - a co-author of draft-lefaucheur-rsvp-ecn-01, on which this draft is > based. > > I would have missed any decision to use aggregate reservations. Pls > point me to the relevant discussion (e.g. Subject line / date). > ... From tom.taylor.stds@gmail.com Thu Nov 15 14:09:13 2012 Return-Path: <tom.taylor.stds@gmail.com> 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 A6DFF21F8A23; Thu, 15 Nov 2012 14:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRU0IgoZnIZO; Thu, 15 Nov 2012 14:09:13 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7EE21F8A1F; Thu, 15 Nov 2012 14:09:12 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so3018773iec.31 for <multiple recipients>; Thu, 15 Nov 2012 14:09:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=Pn46t6G0M84JTYJVv/cjjEfs9NmqgD1IVJwpxITrEK0=; b=IqEB/jCBIE5oIRx4f7zbJC1VK5s4u0j0Kd95/K07XMVTN9h+3/tZwZpD3OgZUTqwwe /WyTIH1ztv0a4Xa9fuBXDDxX34LtatyxEOukKHkjkrK24L7GMRO/O8nSXpeweHDGK/gX TFtkavsaqdiDwl3gPsa57D94N2uNbh6vPcI+WGLaTaALdnBGFfc6CZLub3XFSTEcsSWL ACYYfIXqYfWFYrBx7/dzF4Dilvz/VIpqV4RNaNKpDOkMEQKYpvwoQtIuthKwyhIme3jl 2uBI9uLT6hm3YXxJ4HEaO41OPueae6StKiRKwc5RS4AyTAW1siMP7tHAQpliiIzfJNcE QfcQ== Received: by 10.50.95.161 with SMTP id dl1mr1854246igb.0.1353017352677; Thu, 15 Nov 2012 14:09:12 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-12-215.tor.primus.ca. [173.206.12.215]) by mx.google.com with ESMTPS id l8sm5044227igo.13.2012.11.15.14.09.10 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 14:09:11 -0800 (PST) Message-ID: <50A56804.3090208@gmail.com> Date: Thu, 15 Nov 2012 17:09:08 -0500 From: Tom Taylor <tom.taylor.stds@gmail.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Bob Briscoe <bob.briscoe@bt.com> References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <E728D0E3C41E644A96A7CCA61863BED4081DE009@xmb-aln-x12.cisco.com> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> <FF1A9612A94D5C4A81ED7DE1039AB80F2ED8FEDF@EXMBX04.ad.utwente.nl> <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> <50A51B8C.4010806@gmail.com> <201211152102.qAFL2BWE010641@bagheera.jungle.bt.co.uk> In-Reply-To: <201211152102.qAFL2BWE010641@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 121115-0, 15/11/2012), Outbound message X-Antivirus-Status: Clean X-Mailman-Approved-At: Wed, 21 Nov 2012 11:30:40 -0800 Cc: PCN IETF list <pcn@ietf.org>, anuragb@cisco.com, tsvwg@ietf.org, rsvp-dir@ietfa.amsl.com Subject: Re: [tsvwg] [PCN] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 15 Nov 2012 22:09:13 -0000 OK, I guess I see your point. I was too focussed on the calculations that are done at the Decision Point. It makes me wonder if I should revive that piggy-backing edge behaviour draft I once started. On 15/11/2012 4:02 PM, Bob Briscoe wrote: > Tom, > > The RSVP message I'm proposing doesn't say "Never mind the SESSION in > this message, I'm related to every flow with the same first hop". It > says "These are the marking probabilities for the SESSION in this > message". Then the PCN-ingress (not the message) infers that all other > flows that share the same aggregate will share the same marking > probability, because PCN marking on interior nodes is random and unbiased. > > It's a subtle distinction, but it preserves the semantics of RSVP > messages, without the three disadvantages of setting up an RSVP > aggregate that I mentioned. > > You will have seen from the rest of the message that I have not rejected > the concept of aggregation, I am merely saying that the PCN-ingress and > PCN-egress can hold the concept internally. > > > Bob > > At 16:42 15/11/2012, Tom Taylor wrote: >> I'm not sure the semantics of the PCN information -- particularly as >> it relates to flow termination -- are correct without some sort of >> concept of aggregation. Or can you really define an RSVP object that >> has semantics "Never mind the SESSION in this message, I'm related to >> every flow with the same first hop"? >> ... From tom.taylor.stds@gmail.com Sat Nov 17 11:41:17 2012 Return-Path: <tom.taylor.stds@gmail.com> 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 91E1A21F8687; Sat, 17 Nov 2012 11:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.382 X-Spam-Level: X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1mJ8S10TQZa; Sat, 17 Nov 2012 11:41:16 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B942B21F851F; Sat, 17 Nov 2012 11:41:16 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so2727378iaf.31 for <multiple recipients>; Sat, 17 Nov 2012 11:41:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=7V6iYPQSWKS/kmbNkIQJ9Q/NI7NPHSheqYQmXtAGEIc=; b=jBZu46loyzz+1KKOM5YrPQX7v7jca3Se4GcpSd/yKqYmuIcKw6jMuBsznX40JcXIDu nmaaumd75P5SAfk19ovCfos7y94T7NKpnaxGAZEAVGxHcVbYfpdIhz2D2EoxWH6WJUV9 72US2kHrhsagCYfjUbIunoWSJYEeamZFjJConGVWhoSN0rLscZOgMG0I5J+HgO0D56tG X+G5ZXVz16mZs4CFNZsQHVYH2KqMQBwAVg09fsyDe67/8DkMUt37CMLktblsT/yYD8BO 7qtKerCGtwaM0oUuY3CzD22dDdEgjHt1fczsIOCNAkTS7vbnQvM0XgsDYrV9A/C2gWhM uk4w== Received: by 10.50.189.193 with SMTP id gk1mr2686702igc.22.1353181276188; Sat, 17 Nov 2012 11:41:16 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-12-215.tor.primus.ca. [173.206.12.215]) by mx.google.com with ESMTPS id uz1sm3501146igb.16.2012.11.17.11.41.13 (version=SSLv3 cipher=OTHER); Sat, 17 Nov 2012 11:41:14 -0800 (PST) Message-ID: <50A7E859.1020305@gmail.com> Date: Sat, 17 Nov 2012 14:41:13 -0500 From: Tom Taylor <tom.taylor.stds@gmail.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Bob Briscoe <bob.briscoe@bt.com> References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <E728D0E3C41E644A96A7CCA61863BED4081DE009@xmb-aln-x12.cisco.com> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> <FF1A9612A94D5C4A81ED7DE1039AB80F2ED8FEDF@EXMBX04.ad.utwente.nl> <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> <50A51B8C.4010806@gmail.com> <201211152102.qAFL2BWE010641@bagheera.jungle.bt.co.uk> <50A56804.3090208@gmail.com> <201211162003.qAGK3C3s014269@bagheera.jungle.bt.co.uk> In-Reply-To: <201211162003.qAGK3C3s014269@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 121117-0, 17/11/2012), Outbound message X-Antivirus-Status: Clean X-Mailman-Approved-At: Wed, 21 Nov 2012 11:30:40 -0800 Cc: PCN IETF list <pcn@ietf.org>, anuragb@cisco.com, tsvwg@ietf.org, rsvp-dir@ietfa.amsl.com Subject: Re: [tsvwg] [PCN] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 17 Nov 2012 19:41:17 -0000 Stepping back a bit here, I have to question your definition of an ingress-egress aggregate. When you say it is composed of all flows with the same next hop, what sort of topology are you assuming? The definition makes sense only if the next hop entity is an egress node. If that is not the case, then I would say an ingress-egress aggregate is defined as the set of all flows where the RESV message comes from the same egress node. On 16/11/2012 3:03 PM, Bob Briscoe wrote: > Tom, > > The edge behaviour RFCs attempted to abstract over any signalling > protcol, but I think they ended up being biased towards the ITU way of > doing things, rather than an abstraction that encompassed both RACF and > RSVP, which was probably too ambitious. > > Is you piggy-backing draft effectively what I am describing - > piggy-backing on e2e signalling? > > I don't believe we need any more abstract drafts if that's what you mean > - we need to focus on RSVP specifically now. We could perhaps re-boot > from Francois's original draft. > > > > Bob > > At 22:09 15/11/2012, Tom Taylor wrote: >> OK, I guess I see your point. I was too focussed on the calculations >> that are done at the Decision Point. >> >> It makes me wonder if I should revive that piggy-backing edge >> behaviour draft I once started. >> >> On 15/11/2012 4:02 PM, Bob Briscoe wrote: >>> Tom, >>> >>> The RSVP message I'm proposing doesn't say "Never mind the SESSION in >>> this message, I'm related to every flow with the same first hop". It >>> says "These are the marking probabilities for the SESSION in this >>> message". Then the PCN-ingress (not the message) infers that all other >>> flows that share the same aggregate will share the same marking >>> probability, because PCN marking on interior nodes is random and >>> unbiased. >>> >>> It's a subtle distinction, but it preserves the semantics of RSVP >>> messages, without the three disadvantages of setting up an RSVP >>> aggregate that I mentioned. >>> >>> You will have seen from the rest of the message that I have not rejected >>> the concept of aggregation, I am merely saying that the PCN-ingress and >>> PCN-egress can hold the concept internally. >>> >>> >>> Bob >>> >>> At 16:42 15/11/2012, Tom Taylor wrote: >>>> I'm not sure the semantics of the PCN information -- particularly as >>>> it relates to flow termination -- are correct without some sort of >>>> concept of aggregation. Or can you really define an RSVP object that >>>> has semantics "Never mind the SESSION in this message, I'm related to >>>> every flow with the same first hop"? >> ... > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > From flefauch@cisco.com Thu Nov 22 05:45:58 2012 Return-Path: <flefauch@cisco.com> 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 710E521F842A; Thu, 22 Nov 2012 05:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.066 X-Spam-Level: X-Spam-Status: No, score=-10.066 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7ndR2oUGAmy; Thu, 22 Nov 2012 05:45:47 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A964C21F8947; Thu, 22 Nov 2012 05:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=61019; q=dns/txt; s=iport; t=1353591930; x=1354801530; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Bq+U7mxA3VtJw6XwKpFA8GGdR3XmWrrKijozJzW1o4U=; b=g0/dmcAjLHzX4EXmZCREvo/AR4V1HlwYDDYmH/EXoEAi5mdInrCu+QCP MSoZQa7q6sqqs2INVHVdWgoRPRgZ8KPUOG+Ajd8Eo9kaAnlKWmb0Qo0G5 UJ03UiIBGdWT/kfX88tb65JCKtuEwGxydOEJZPyAAc+OQU4GnPITD4zZu w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAOIqrlCtJV2b/2dsb2JhbAA6CrkaAYkCFnOCHgEBAQIBARoBTAERBQsCAQgRAQIBAQEBChYBBgcyFAMGCAIEDgUIARKHbAYMwAyMNwoBBoNfYQOSFYUIjyaCb4FoFx4 X-IronPort-AV: E=McAfee;i="5400,1158,6903"; a="145259423" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 22 Nov 2012 13:40:14 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAMDeEcl012749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Nov 2012 13:40:14 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.192]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Thu, 22 Nov 2012 07:40:14 -0600 From: "Francois Le Faucheur (flefauch)" <flefauch@cisco.com> To: Bob Briscoe <bob.briscoe@bt.com> Thread-Topic: [tsvwg] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 Thread-Index: AQHNx2Ysq6goFkOn1k+WwIO3Y651p5f2Q5KA Date: Thu, 22 Nov 2012 13:40:13 +0000 Message-ID: <FC236DA6F2DA77449EF2D02DF4471A8D258244@xmb-rcd-x10.cisco.com> References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <E728D0E3C41E644A96A7CCA61863BED4081DE009@xmb-aln-x12.cisco.com> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> <FF1A9612A94D5C4A81ED7DE1039AB80F2ED8FEDF@EXMBX04.ad.utwente.nl> <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> <38323AE1-362C-4DBF-87A0-2D468586CC53@mimectl> <201211162014.qAGKEYxK014300@bagheera.jungle.bt.co.uk> <1E38B46D-C270-4D6E-B97A-619C00259FEC@mimectl> <201211202129.qAKLTPGC002799@bagheera.jungle.bt.co.uk> In-Reply-To: <201211202129.qAKLTPGC002799@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.198] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D258244xmbrcdx10ciscocom_" MIME-Version: 1.0 Cc: "<gorry@erg.abdn.ac.uk>" <gorry@erg.abdn.ac.uk>, "<tsvwg@ietf.org>" <tsvwg@ietf.org>, "<slblake@petri-meat.com>" <slblake@petri-meat.com>, "<philip.eardley@bt.com>" <philip.eardley@bt.com>, "Anurag Bhargava \(anuragb\)" <anuragb@cisco.com>, "<sob@harvard.edu>" <sob@harvard.edu>, "<rsvp-dir@ietfa.amsl.com>" <rsvp-dir@ietfa.amsl.com>, "<pcn@ietf.org>" <pcn@ietf.org>, "James Polk \(jmpolk\)" <jmpolk@cisco.com> Subject: Re: [tsvwg] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 22 Nov 2012 13:45:59 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D258244xmbrcdx10ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Bob, Georgios, >From a scan of the thread and an off-line discussion with Georgios, my perc= eption of the situation is: * PCN edges need to maintain logical aggregate constructs (i.e. ingress-egr= ees PCN state) and map e2e reservations to these aggregate constructs * we need to convey aggregate PCN info from edge to edge * no actual reservation state is needed inside the PCN Core This could be achieved by: (A): * adapting RFC 4860 aggregation procedures to fit PCN with as little change= as possible over RFC4860 * hence performing aggregate RSVP signaling (even if it is to be ignored by= PCN interior nodes) * using this aggregate RSVP signaling to convey PCN info edge to edge OR (B): * adapting RFC 4860 aggregation procedures to fit PCN with more significant= changes over RFC4860 (i.e. you keep the aspect of the procedures that have= to do with maintaining aggregate states and to do with mapping e2e to aggr= egates, but you drop procedures that have too do with aggregate RSVP signal= ing and aggregate reservation establishment/maintenance) * hence not performing aggregate RSVP signaling * piggy-backing PCN info inside e2e RSVP signaling. I think both approaches are probably viable. I tend to think the difference= between the two is actually not that big at the end of the day because the= key of the logic is how you maintain aggregate states at the edge and how = you map 2e2 RSVP to these aggregates (i.e. the concept of aggregation withi= n RFC4860 - independently of the notion of aggregate RSVP signaling) and I = don't think the ingress-egress signaling channel (i.e. aggregate RSVP or e2= e RSVP) is so significant given the PCN specifics. I think the drawbacks you pointed out, Bob, in your initial message are pro= bably not as serious as you suggested, given aggregate RSVP signaling would= be ignored by interior nodes (for example, I don't see why aggregate RSVP = signaling would impact rerouting inside the PCN core since packets from ind= ividual sessions would be routed independently of the reservation. As anoth= er example you mentioned that it might double the signaling processing load= on edges while i suspect it would only increase by some fraction given the= level of aggregate signaling should be much lower than collective e2e sign= aling). Nevertheless, If an approach along the lines of (B) removes the dra= wbacks completely while behaving as well, then that may be a better approac= h. An attractive properly of (A) is that RFC4860 operations has been thought t= hrough and there has been some implementation of RSVP Aggregation, so we ha= ve some confidence that the solution can deal with the more challenging sit= uations (rerouting in core, failure of an ingress edge, failure of an egres= s edge, rerouting towards a different edge,=85). My suggestion would be to try identify if a (B)-type approach can be devise= d with comparable properties in dealing with basic as well as more challeng= ing situations, or conversely if the (A)-type approach really has some supe= rior behavior afforded by the extra ingress-egress dedicated signaling chan= nel. That should be a key deciding factor. Perhaps Georgios could look into this direction? I hope that helps Francois Caveat: I am operating based on slowly-but-surely fainting intimacy with PC= N and RSVP aggregation technologies On 20 Nov 2012, at 22:29, Bob Briscoe wrote: Georgios, See other email. Pls focus on the specifics (you will need to go back to my= original email in the thread, because the specifics were immediately cut f= rom the thread when Tom understood them). The IETF can choose to continue along a path that it originally agreed, whe= ther right or wrong, but it is important to discuss whether it is right or = wrong first. Bob At 10:29 17/11/2012, karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl> = wrote: Hi Bob, So, what you actually proposing is to discard a specification that has been= accepted by both PCN and tsvwg WGs to be considered as a WG specification = and to use a specification that you are proposing and that is conceptually = and architecturally wrong. The solution that you are proposing, i.e., use of the e2e RSVP (RFC2205), i= s in my opinion architecturally and conceptually wrong! The reason is the following! In PCN we need a signaling protocol that is able to: (1) to carry informati= on from PCN-egress-edge to PCN-ingress-edge and (2) the carried information= needs to be related to an aggregated state, i.e., the ingress-egress-aggre= gate state. The e2e RSVP (RFC2205) can only support requirement (1), but is not able to= support (2), since the e2e RSVP carries information that is associated wit= h a per flow state maintained at the edges. Aggregated RSVP (RFC3175) and Generic Aggregated RSVP (RFC4860) can support= both requirements, since one of the features that are supported by both is= to carry objects that are associated to an aggregated state maintained at = the edges. In the context of PCN, the aggregated state is the ingress egres= s aggregate state. Best regards, Georgios ________________________________ Van: Bob Briscoe [bob.briscoe@bt.com<mailto:bob.briscoe@bt.com>] Verzonden: vrijdag 16 november 2012 21:14 To: Karagiannis, G. (EWI) Cc: carlberg@g11.org.uk<mailto:carlberg@g11.org.uk>; tsvwg@ietf.org<mailto:= tsvwg@ietf.org>; philip.eardley@bt.com<mailto:philip.eardley@bt.com>; pcn@i= etf.org<mailto:pcn@ietf.org>; rsvp-dir@ietfa.amsl.com<mailto:rsvp-dir@ietfa= .amsl.com>; sob@harvard.edu<mailto:sob@harvard.edu>; slblake@petri-meat.com= <mailto:slblake@petri-meat.com>; gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn= .ac.uk>; jmpolk@cisco.com<mailto:jmpolk@cisco.com>; anuragb@cisco.com<mailt= o:anuragb@cisco.com> Onderwerp: RE: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-= 03 Georgios, Yes, I apologise for not reviewing earlier. I appreciate you followed the p= rocedure. My problem was that a quick read of tsvwg-rsvp-pcn wasn't enough to underst= and it. So I stayed quiet even though I wasn't so happy about the direction= , because I didn't have enough understanding to feel I could argue. Only in the last week or so, I collected together all the references and re= -read them and their references, and made a concerted effort to understand = what your draft was proposing. I have to say, it was quite a struggle (over= a few days and the write-up took 2 days). However, I admit that it would have been preferable for everyone if I had m= ade this effort earlier. Bob At 13:02 16/11/2012, karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl> = wrote: Hi Bob, $B!!(B Thanks for your comments! Regarding your statement: What I meant in my previous email is that our ind= ividual draft that was used as a working basis for this WG draft was alrea= dy using the generic aggregation RSVP (RFC 4860) as the existing signaling = protocol, see: http://tools.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt Moreover, during IETF 81, this individual draft has been presneted, where a= lso the rationale of using (RFC 4860) was also the following slides see pre= sentation slides (slide 5): http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf $B!!(B In particular in slide 4 mentions: "All PCN charter items are fulfilled, except: Submit Encoding and Transport of PCN from Domain Egress to Ingress to the I= ESG for consideration as a Proposed Standard RFC Pairs of PCN edge nodes use ingress-egress-aggregates (IEA): Need a signaling protocol to transport PCN information from PCN-egress-node= to PCN-ingress-node and to maintain ingress-egress-aggregate between each = pair of PCN edge nodes" Furthermore Slide 5 mentions: $B!!(B "IETF QoS signaling protocols to solve problem: Next Steps in Signaling Protocol (NSIS) subset (RFC 5971, RFC 5974, RFC 597= 9) Aggregation of RSVP for IPv4 and IPv6 Reservations (RFC3175) Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations (RFC486= 0) All can be used, but for time being selected RFC 4860 due: possible deployment interest supports RFC 3175 and additional features such as: support of multiple IEAs from same pair of PCN edge nodes support of bandwidth reduction for individual flows (RFC 4495)" $B!!(B Before IETF 81 and during IETF 81 this point has been discussed. The outcome of these discussions is that short after IETF 81, the individua= l draft (draft-karagiannis-pcn-tsvwg-rsvp-pcn-01) become (after small modifications) the draft-ietf-tsvwg-rsvp-pcn-00, which = also was using RFC 4860 as the base signaling protocol. $B!!(B It will be very helpful if the PCN WG chairs (Scott and/or Steve) and the t= svwg WG chairs (Gorry and/or James) could confirm the above statement! $B!!(B So both the PCN WG and tsvwg WG agreed that this specifictaion should use a= s basis the generic RSVP aggregation protocol! $B!!(B $B!!(B $B!!(B In a subsequent email and on a later moment I will also answer to your furt= her remarks! $B!!(B Best regards, Georgios ________________________________ Van: Bob Briscoe [bob.briscoe@bt.com<mailto:bob.briscoe@bt.com>] Verzonden: donderdag 15 november 2012 14:07 To: Karagiannis, G. (EWI); anuragb@cisco.com<mailto:anuragb@cisco.com> Cc: carlberg@g11.org.uk<mailto:carlberg@g11.org.uk>; anuragb@cisco.com<mail= to:anuragb@cisco.com>; tsvwg@ietf.org<mailto:tsvwg@ietf.org>; philip.eardle= y@bt.com<mailto:philip.eardley@bt.com>; PCN IETF list; rsvp-dir@ietfa.amsl.= com<mailto:rsvp-dir@ietfa.amsl.com> Onderwerp: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 Georgios, Anurag, Below is the main point of my review, arguing that aggregate reservations a= re redundant. I'm reviewing as: - a member of the RSVP directorate - one of the early PCN design team - a co-author of draft-lefaucheur-rsvp-ecn-01, on which this draft is based= . I would have missed any decision to use aggregate reservations. Pls point m= e to the relevant discussion (e.g. Subject line / date). I admit I tuned out of much of the later PCN signalling discussion. I found= the whole exercise of abstracting PCN away from specific signalling protoc= ols highly tedious; it meant we couldn't sensibly address important issues = like message reliability, timeliness etc. Nonetheless, here's why I believe RSVP aggregation is redundant: PCN edge-nodes support the concept of an ingress-egress aggregate in their = own internal tables, but they don't need to refer to an aggregate on the wi= re{Note 1}. PCN-ingress and PCN-egress nodes intrinscially know which e2e r= eservations belong to which aggregate by grouping together those e2e reserv= ations with the same next hop or previous hop respectively. {Note 1: except in one case described later - but it doesn't require all th= e other baggage of aggregate reservations} =3D=3DBackground=3D=3D Aggregate reservations [RFC3175, RFC4860] are designed to reduce the state = required on interior nodes. Interior nodes still require state per aggregat= e reservation, but only reservation state, not classification and schedulin= g state [RFC3175, Section 1.4.1 last para]. In contrast, as you correctly point out (in Section 2.1.7), PCN requires ab= solutely no reservation-related state on interior nodes. =3D=3DDisadvantages=3D=3D Requiring PCN to use aggregate reservations has the following three disadva= ntages and no advantages: 1) Redundant Processing The PATH message between aggregator and deaggregator in rsvp-pcn-03 (trigge= red by an E2E PathErr message from deaggregator to aggregator) is redundant= , and just doubles the processing required at the PCN-edge-nodes (if this i= sn't obvious, I spell it out separately for PATH & RESV messages below). 2) Reduced Resilience Not only is an aggregate PATH redundant, it actually reduces resilience. Be= cause an aggregate PATH is pinned to interior routers. Therefore, when rout= ing changes, it is more complex and slower to move to the new route. By not= pinning to interior routers, PCN was designed to 'just work' over interior= routing changes - with no need for any changes to the RSVP PATHs. (But it = would still detect overload after a re-route and terminate or rate-reduce f= lows if necessary.) 3) Extra Latency A further disadvantage is the extra latency required for the first reservat= ion that sets up an aggregate. This is two ingress-egress round trips minus= the round trip time from egress to destination (or one ingress-egress roun= d trip if it is greater). This will rarely add to latency on heavily used i= ngress-egress aggregates, but it will occur frequently on all the 'long-tai= l' (lightly used) ingress-egress aggregates. =3D=3DPATH=3D=3D With RFC 3175 or 4860 aggregate paths, the aggregator forwards the e2e PATH= messages with IP protocol number RSVP-E2E-IGNORE and the deaggregator chan= ges them back to RSVP before forwarding onward. Also the aggregator sends a= n aggregate PATH message, which is processed by each interior node and by t= he deaggregator. On a path across a PCN region, given interior nodes ignore aggregate PATH m= essages as well, the only PCN nodes that handle aggregate messages are the = aggregator and the deaggregator. The aggregator and deaggregator process al= l the e2e PATH messages anyway, so if we require the aggregator to add up a= ll the e2e PATH messages and form them into an aggregate PATH message, this= is just extra redundant work for both PCN-edge-nodes. =3D=3DRESV=3D=3D The deaggregator unicasts e2e RESV messages to the previous RSVP hop, which= is the aggregator. Therefore, if we require the deaggregator to add up all= the RESV messages and form them into an aggregate RESV message, this is ju= st redundant work for both PCN-edge-nodes, because they both already proces= s all the e2e RESV messages anyway, and no other node uses the aggregate RE= SV messages. =3D=3DPCN object=3D=3D This raises the question of how the PCN-egress communicates the various mar= king rates (the PCN object) to the PCN-ingress. There are two possibilities= : i) the PCN-egress includes a current PCN object in each e2e RESV that it re= turns to the PCN-ingress. The PCN-ingress strips the PCN object out before = forwarding the RESV back to the previous RSVP hop. ii) the PCN-egress attaches a PCN object to an aggregate reservation, as in= pcn-rsvp-03. Either are possible, because a PCN object carries information about marking= probabilities, and PCN works on the assumption that the marking probabilit= y of an ingress-egress aggregate is the same as the marking probability of = the flows within the aggregate. A PCN object can be contained either in an = e2e RESV or an aggregate RESV as long as the PCN-ingress can associate an e= 2e RESV with the correct aggregate (which it can, because it maintains an i= nternal table of mappings between e2e reservations and their aggregates). Which of the two is best is a question of message timing... * For e2e admission decisions, the PCN object is only needed at the time ea= ch e2e RESV is sent, so option i) makes sense. * For flow rate reduction or flow termination decisions, the deaggregator n= eeds to regularly send PCN objects to the ingress. The PCN-egress is sending regular e2e RESV refresh messages to the PCN-ingr= ess, so a PCN object can be included in each of these. To ensure that PCN o= bjects are sent often enough, I suggest the PCN-egress also maintains a tim= er per ingress-egress aggregate which it resets every time it sends a PCN o= bject for that IEA. If the timer expires, the PCN-egress sends a PCN object= to the PCN-egress even thought it was not triggered by an e2e RESV refresh= . We could require the SESSION object in this message to refer to either of= : a) any one of the e2e SESSIONs in the aggregate, b) the aggregate. In case (a), the message would need to somehow tell the ingress not to forw= ard this RESV refresh to the RSVP previous hop. In case (b) in the PCN-ingress table of mappings between e2e SESSIONs and a= ggregate SESSIONs, it would include an entry for the aggregate that maps to= itself. If the result of the look-up is the same as the input, it knows no= t to forward the RESV refresh further. The wire protocol doesn't need to identify whether the SESSION is an aggreg= ate or not. This is the one case I mentioned at the start {Note 1} where an= aggregate is referred to on the wire. In summary, PCN already reduces reservation state and processing to nothing= on interior nodes. Adding aggregate reservations to PCN requires more proc= essing and state, it unnecessarily pins routes to interior nodes and adds u= nnecessary latency. Bob At 18:23 14/11/2012, karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl> = wrote: Hi Bob, Regarding the generic aggregated RSVP selection, actually the PCN WG agreed= with this selection! This was actually the first step that was needed for this work, and the PCN= WG had no main objections on this selection! So I do not understand your remark that your comment will have major implic= ations! Please note that the generic aggregated RSVP is selected since the PCN IEA = are associated with flows that are aggregated at the edges. So a signalling= protocol that supports aggregation of flows at the edges is very suitable = for this purpose! The generic aggregated RSVP is such a signalling protocol= ! Best regards, Georgios From: Bob Briscoe [mailto:bob.briscoe@bt.com] Sent: woensdag 14 november 2012 12:57 To: Anurag Bhargava (anuragb) Cc: Karagiannis, G. (EWI) Subject: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 Anurag, I have my comments half-written up. I will try to finish them by the end of= today. They should be orthogonal to the PBAC comment below, so if you wanted to st= art altering that area, I don't think it would waste too much time. However, my main comments will concern the use of aggregated reservations (= as I said at the mic), so that could have major implications. Bob At 20:14 13/11/2012, Anurag Bhargava (anuragb) wrote: Hi Bob, Thanks for the comments. If U have some text that will be great els I have= also started putting some text on the topic U brought up. May be we can conference after US thanksgiving week and collaborate the te= xt and try to move forward. Please let us know what might be a good time and I can schedule a Webex co= nf. Thx -Anurag From: "karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl> " <karagian@cs= .utwente.nl<mailto:karagian@cs.utwente.nl> > Date: Saturday, November 10, 2012 8:10 AM To: "bob.briscoe@bt.com<mailto:bob.briscoe@bt.com>" <bob.briscoe@bt.com<mai= lto:bob.briscoe@bt.com>> Cc: "carlberg@g11.org.uk<mailto:carlberg@g11.org.uk>" <carlberg@g11.org.uk<= mailto:carlberg@g11.org.uk>>, Anurag Bhargava <anuragb@cisco.com<mailto:anu= ragb@cisco.com>>, "tsvwg@ietf.org<mailto:tsvwg@ietf.org>" <tsvwg@ietf.org<m= ailto:tsvwg@ietf.org>>, "philip.eardley@bt.com<mailto:philip.eardley@bt.com= > " <philip.eardley@bt.com<mailto:philip.eardley@bt.com> > Subject: RE: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 Hi Bob, Thanks very much for the comments! I think that they are very useful! It will be very beneficiary for the fast progress of this draft if you woul= d like to contribute as a co-author to this draft and write this additional= section that describes "that the PCN-ingress can refer flow admission and termination decisions to a central decision point (using e.g. COPS), which = will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingr= ess could itself be the policy decision point.)" Best regards, Georgios ________________________________ Van: Bob Briscoe [bob.briscoe@bt.com<mailto:bob.briscoe@bt.com>] Verzonden: vrijdag 9 november 2012 16:33 To: Karagiannis, G. (EWI) Cc: carlberg@g11.org.uk<mailto:carlberg@g11.org.uk>; anuragb@cisco.com<mail= to:anuragb@cisco.com>; tsvwg@ietf.org<mailto:tsvwg@ietf.org>; EARDLEY, Phil Onderwerp: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 Georgios, I shall post my full review of this draft in the next few days (needs typing up - currently scribbled on a paper copy). This email is solely in response to your answer about on-path vs off-path policy. At 18:55 04/11/2012, karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl> = wrote: >So in this case an additional signaling protocol will be >needed to be specified that covers the signaling between the >PCN-egress-node and the centralized node >and between PCN-ingress-node and the centralized node. >In PCN we decdided to only focus on the specification of the >signaling protocol that completes the >feedback loop from PCN-egress-node to PCN-ingress-node and to focus >on the signaling protocol >used between the edge nodes and the centralized node. When I/we originally designed CL-PCN over RSVP (2005), the idea was that it would fit with the policy-based admission control (PBAC) architecture of RFC2753. In this architecture, an Intserv node at the ingress to a domain is the policy enforcement point (PEP), and it refers to a logically centralised 'policy decision point' (PDP) for decisions on which flows to block/terminate, typically using COPS. To make this doc fit the PBAC framework, all we have to do is: * Describe the PCN-ingress only as the PCN-ingress and not as the decision point (find 'decision' throughout doc and fix). * Add a section saying the PCN-ingress can refer flow admission and termination decisions to a central decision point (using e.g. COPS), which will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingress could itself be the policy decision point.) * Refer to this new PBAC section from Section 3.11 giving the admission decision procedure. * Some people might think this means COPS will need new protocol elements to carry PCN marking rates to the policy decision point. But PCN marking rates are irrelevant to the policy decision: the PCN-ingress just uses PCN to determine whether it needs to block or terminate, and it refers to the policy decision point for which flows to block/terminate. * Unfortunately, neither of the two PCN system descriptions [RFC6661, RFC6662] describe a PBAC-based case. The architecture [RFC5559] refers to the PBAC framework [RFC2753] but unfortunately doesn't spell out how it fits. Originally, I referenced PBAC from RFC5559, but just as the PCN w-g was closing I realised that (some?) others in the PCN w-g were working under the assumption that the only way to talk to a centralised policy node was from the egress, possibly without being aware of the contents of RFC2753. I think it's OK to introduce a new architectural arrangement in this RSVP doc, given RFC2753 is specific to the way RSVP works. Bob At 12:28 05/11/2012, karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl> = wrote: >Hi Ken, > >Thank you very much! >We will try to catch Francois and discuss the last (in line) issue with hi= m! > >Best regards, >Georgios > >________________________________________ >Van: ken carlberg [carlberg@g11.org.uk<mailto:carlberg@g11.org.uk>] >Verzonden: maandag 5 november 2012 13:23 >To: Karagiannis, G. (EWI) >Cc: tsvwg@ietf.org<mailto:tsvwg@ietf.org>; anuragb@cisco.com<mailto:anurag= b@cisco.com> >Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03 > >Georgios, > > > Georgios: We will try to explain the rationale of why we consider > that RSVP can only be used for the situation that the > > decision point is collocated with the PCN-ingress-node. The main > reason of this is that in the case that the > > decision point is collocated with the PCN-ingress-node,the > required signaling protocol used to complete a > > feedback loop from egress to ingress can be an entirely on-path > protocol, like what RSVP is. > > In the situation that the the decision point is a centralized > node, then the required signaling protocol > > can be a combination of an on-path and off-path protocol. This is > because the > > decision point might not be located on the data path! So in this > case an additional signaling protocol will be > > needed to be specified that covers the signaling between the > PCN-egress-node and the centralized node > > and between PCN-ingress-node and the centralized node. > > In PCN we decdided to only focus on the specification of the > signaling protocol that completes the > > feedback loop from PCN-egress-node to PCN-ingress-node and to > focus on the signaling protocol > > used between the edge nodes and the centralized node. > > This is also the reason of why PCN WG decided to only focus on > the situation that the decision point is > > collocated with the PCN-ingress-node. > >Great, this is helpful, and this is the information that needs to be >in the draft. > > >> 6) This comment is just for you to contemplate -- I'm not > expecting any changes. > >> I noticed that you have a fair number of SHOULD, and some SHOULD NOTs. > >> And it seems a lot of this is a carry over from rfc-4860, so in > a sense you are inheriting an approach that > >> was agreed to from an earlier effort. But I wonder in the back > of my mind, what impact occurs if > >> an implementor doesn't follow the SHOULD? Does the design break > in supporting PCN? > >> Again, I want to stress that this isnt a show stopper, but I > would appreciate it if you gave it some thought. > > > > Georgios: Yes, in several cases the design might break in supporting PC= N. > > This is also the reason of using SHOULD instead of MAY. Do you > want us to explain this in more detail in the draft? > >well, actually, I was more curious as to why a number of these cases >are SHOULD instead of MUST. Again, the SHOULD's in your document >seem to be a carry-over from rfc-4860 (which set the precedent), so >its a bit unfair for you to explain what was done in an earlier >effort. I just wanted to make sure you gave some thought to the >subject. And if things will break if SHOULD is not followed by an >implementer/configuration, then maybe you should be more stringent >and change things to MUST. Perhaps a brief private conversation >with Francois Le Faucheur will be helpful. > >cheers, > >-ken ________________________________________________________________ Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design --_000_FC236DA6F2DA77449EF2D02DF4471A8D258244xmbrcdx10ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <AF0632F35929B747AC57FECB5DF22EB5@cisco.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; "> Hello Bob, Georgios, <div><br> </div> <div>From a scan of the thread and an off-line discussion with Georgios, my= perception of the situation is:</div> <div> <div><br> </div> <div>* PCN edges need to maintain logical aggregate constructs (i.e. ingres= s-egrees PCN state) and map e2e reservations to these aggregate constructs<= /div> <div> <div>* we need to convey aggregate PCN info from edge to edge</div> <div><span class=3D"Apple-tab-span" style=3D"white-space: pre; "></span>* n= o actual reservation state is needed inside the PCN Core</div> <div><br> </div> <div>This could be achieved by:</div> <div><br> </div> <div>(A):</div> <div>* adapting RFC 4860 aggregation procedures to fit PCN with as little c= hange as possible over RFC4860</div> <div>* hence performing aggregate RSVP signaling (even if it is to be ignor= ed by PCN interior nodes)</div> <div>* using this aggregate RSVP signaling to convey PCN info edge to edge<= /div> <div><br> </div> <div>OR</div> <div><br> </div> <div>(B):</div> <div>* adapting RFC 4860 aggregation procedures to fit PCN with more signif= icant changes over RFC4860 (i.e. you keep the aspect of the procedures that= have to do with maintaining aggregate states and to do with mapping e2e to= aggregates, but you drop procedures that have too do with aggregate RSVP signaling and aggregate reservation e= stablishment/maintenance)</div> <div>* hence not performing aggregate RSVP signaling</div> <div>* piggy-backing PCN info inside e2e RSVP signaling.</div> <div><br> </div> <div><br> </div> <div>I think both approaches are probably viable. I tend to think the diffe= rence between the two is actually not that big at the end of the day becaus= e the key of the logic is how you maintain aggregate states at the edge and= how you map 2e2 RSVP to these aggregates (i.e. the concept of aggregation within RFC4860 - independently of the not= ion of aggregate RSVP signaling) and I don't think the ingress-egress signa= ling channel (i.e. aggregate RSVP or e2e RSVP) is so significant given the = PCN specifics. </div> <div>I think the drawbacks you pointed out, Bob, in your initial message ar= e probably not as serious as you suggested, given aggregate RSVP signaling = would be ignored by interior nodes (for example, I don't see why aggregate = RSVP signaling would impact rerouting inside the PCN core since packets from individual sessions would be routed= independently of the reservation. As another example you mentioned that it= might double the signaling processing load on edges while i suspect it wou= ld only increase by some fraction given the level of aggregate signaling should be much lower than collectiv= e e2e signaling). Nevertheless, If an approach along the lines of (B) remov= es the drawbacks completely while behaving as well, then that may be a bett= er approach.</div> <div><br> </div> <div>An attractive properly of (A) is that RFC4860 operations has been thou= ght through and there has been some implementation of RSVP Aggregation, so = we have some confidence that the solution can deal with the more challengin= g situations (rerouting in core, failure of an ingress edge, failure of an egress edge, rerouting towards a= different edge,=85).</div> <div>My suggestion would be to try identify if a (B)-type approach can be d= evised with comparable properties in dealing with basic as well as more cha= llenging situations, or conversely if the (A)-type approach really has some= superior behavior afforded by the extra ingress-egress dedicated signaling channel. That should be a key dec= iding factor.</div> <div>Perhaps Georgios could look into this direction?</div> <div><br> </div> <div>I hope that helps</div> </div> </div> <div><br> </div> <div>Francois</div> <div><br> </div> <div>Caveat: I am operating based on slowly-but-surely fainting intimacy wi= th PCN and RSVP aggregation technologies</div> <div><br> </div> <div><br> </div> <div><br> <div> <div>On 20 Nov 2012, at 22:29, Bob Briscoe wrote:</div> <br class=3D"Apple-interchange-newline"> <blockquote type=3D"cite"> <div>Georgios,<br> <br> See other email. Pls focus on the specifics (you will need to go back to my= original email in the thread, because the specifics were immediately cut f= rom the thread when Tom understood them).<br> <br> The IETF can choose to continue along a path that it originally agreed, whe= ther right or wrong, but it is important to discuss whether it is right or = wrong first.<br> <br> <br> Bob<br> <br> At 10:29 17/11/2012, <a href=3D"mailto:karagian@cs.utwente.nl">karagian@cs.= utwente.nl</a> wrote:<br> <br> <blockquote type=3D"cite" class=3D"cite" cite=3D"x-msg://1934/">Hi Bob,<br> <br>  <br> <br> So, what you actually proposing is to discard a specification that has been= accepted by both PCN and tsvwg WGs to be considered as a WG specification = and to use a specification that you are proposing and that is conceptually = and architecturally wrong.<br> <br>  <br> <br> The solution that you are proposing, i.e., use of the e2e RSVP (RFC2205), i= s in my opinion architecturally and conceptually wrong!<br> <br> The reason is the following!<br> <br>  <br> <br> In PCN we need a signaling protocol that is able to: (1) to carry informati= on from PCN-egress-edge to PCN-ingress-edge and (2) the carried information= needs to be related to an aggregated state, i.e., the ingress-egress-aggre= gate state.<br> <br> The e2e RSVP (RFC2205) can only support requirement (1), but is not able to= support (2), since the e2e RSVP carries information that is associated wit= h a per flow state maintained at the edges.<br> <br> Aggregated RSVP (RFC3175) and Generic Aggregated RSVP (RFC4860) can support= both requirements, since one of the features that are supported by both is= to carry objects that are associated to an aggregated state maintained at = the edges. In the context of PCN, the aggregated state is the ingress egress aggregate state.<br> <br>  <br> <br> Best regards,<br> <br> Georgios<br> <br> <hr> <font face=3D"Tahoma" size=3D"2"><b>Van:</b> Bob Briscoe [<a href=3D"mailto= :bob.briscoe@bt.com">bob.briscoe@bt.com</a>]<br> <b>Verzonden:</b> vrijdag 16 november 2012 21:14<br> <b>To:</b> Karagiannis, G. (EWI)<br> <b>Cc:</b> <a href=3D"mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>; = <a href=3D"mailto:tsvwg@ietf.org"> tsvwg@ietf.org</a>; <a href=3D"mailto:philip.eardley@bt.com">philip.eardley= @bt.com</a>; <a href=3D"mailto:pcn@ietf.org">pcn@ietf.org</a>; <a href=3D"mailto:rsvp-di= r@ietfa.amsl.com"> rsvp-dir@ietfa.amsl.com</a>; <a href=3D"mailto:sob@harvard.edu">sob@harvard= .edu</a>; <a href=3D"mailto:slblake@petri-meat.com">slblake@petri-meat.com</a>; <a hr= ef=3D"mailto:gorry@erg.abdn.ac.uk"> gorry@erg.abdn.ac.uk</a>; <a href=3D"mailto:jmpolk@cisco.com">jmpolk@cisco.= com</a>; <a href=3D"mailto:anuragb@cisco.com">anuragb@cisco.com</a><br> <b>Onderwerp:</b> RE: Redundant aggregate reservations: draft-ietf-tsvwg-rs= vp-pcn-03<br> </font><br> Georgios,<br> <br> Yes, I apologise for not reviewing earlier. I appreciate you followed the p= rocedure.<br> <br> My problem was that a quick read of tsvwg-rsvp-pcn wasn't enough to underst= and it. So I stayed quiet even though I wasn't so happy about the direction= , because I didn't have enough understanding to feel I could argue.<br> <br> Only in the last week or so, I collected together all the references and re= -read them and their references, and made a concerted effort to understand = what your draft was proposing. I have to say, it was quite a struggle (over= a few days and the write-up took 2 days). <br> <br> However, I admit that it would have been preferable for everyone if I had m= ade this effort earlier.<br> <br> <br> Bob<br> <br> At 13:02 16/11/2012, <a href=3D"mailto:karagian@cs.utwente.nl">karagian@cs.= utwente.nl</a> wrote:<br> <br> <blockquote type=3D"cite" class=3D"cite" cite=3D"x-msg://1934/">Hi Bob,<br> <br> $B!!(B<br> <br> Thanks for your comments!<br> <br> Regarding your statement: What I meant in my previous email is that our ind= ividual draft that was used as a working basis for this WG draft  was = already using the generic aggregation RSVP (RFC 4860) as the existing signa= ling protocol, see:<br> <br>  <br> <br> <a href=3D"http://tools.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01= .txt">http://tools.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt<= /a> <br> <br>  <br> <br> Moreover, during IETF 81, this individual draft has been presneted, where a= lso the rationale of using (RFC 4860) was also the following slides see pre= sentation slides (slide 5):<br> <br>  <br> <br> <a href=3D"http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf">http://ww= w.ietf.org/proceedings/81/slides/tsvwg-0.pdf</a><br> <br> $B!!(B<br> <br> In particular in slide 4 mentions:<br> <br> "All PCN charter items are fulfilled, except:<br> <br> Submit Encoding and Transport of PCN from Domain Egress to Ingress to the I= ESG for consideration as a Proposed Standard RFC<br> <br> Pairs of PCN edge nodes use ingress-egress-aggregates (IEA):<br> <br> Need a signaling protocol to transport PCN information from PCN-egress-node= to PCN-ingress-node and to maintain ingress-egress-aggregate between each = pair of PCN edge nodes"<br> <br> Furthermore Slide 5 mentions:<br> <br> $B!!(B<br> <br> "IETF QoS signaling protocols to solve problem:<br> <br> Next Steps in Signaling Protocol (NSIS) subset (RFC 5971, RFC 5974, RFC 597= 9)<br> <br> Aggregation of RSVP for IPv4 and IPv6 Reservations (RFC3175)<br> <br> Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations (RFC486= 0)<br> <br> All can be used, but for time being selected RFC 4860 due:<br> <br> possible deployment interest<br> <br> supports RFC 3175 and additional features such as: <br> <br> support of multiple IEAs from same pair of PCN edge nodes <br> <br> support of bandwidth reduction for individual flows (RFC 4495)"<br> <br> $B!!(B<br> <br> Before IETF 81 and during IETF 81 this point has been discussed.<br> <br> The outcome of these discussions is that short after IETF 81, the individua= l draft (draft-karagiannis-pcn-tsvwg-rsvp-pcn-01) <br> <br> become (after small modifications) the draft-ietf-tsvwg-rsvp-pcn-00, which = also was using RFC 4860 as the base signaling protocol.<br> <br> $B!!(B<br> <br> It will be very helpful if the PCN WG chairs (Scott and/or Steve) and the t= svwg WG chairs (Gorry and/or James) could confirm the above statement!<br> <br> $B!!(B<br> <br> So both the PCN WG and tsvwg WG agreed that this specifictaion should use a= s basis the generic RSVP aggregation protocol!<br> <br> $B!!(B<br> <br> $B!!(B<br> <br> $B!!(B<br> <br> In a subsequent email and on a later moment I will also answer to your furt= her remarks!<br> <br> $B!!(B<br> <br> Best regards,<br> <br> Georgios<br> <hr> <font face=3D"Tahoma" size=3D"2"><b>Van:</b> Bob Briscoe [<a href=3D"mailto= :bob.briscoe@bt.com">bob.briscoe@bt.com</a>]<br> <b>Verzonden:</b> donderdag 15 november 2012 14:07<br> <b>To:</b> Karagiannis, G. (EWI); <a href=3D"mailto:anuragb@cisco.com">anur= agb@cisco.com</a><br> <b>Cc:</b> <a href=3D"mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>; = <a href=3D"mailto:anuragb@cisco.com"> anuragb@cisco.com</a>; <a href=3D"mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>= ; <a href=3D"mailto:philip.eardley@bt.com"> philip.eardley@bt.com</a>; PCN IETF list; <a href=3D"mailto:rsvp-dir@ietfa.= amsl.com"> rsvp-dir@ietfa.amsl.com</a><br> <b>Onderwerp:</b> Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-p= cn-03<br> </font><br> Georgios, Anurag,<br> <br> Below is the main point of my review, arguing that aggregate reservations a= re redundant. I'm reviewing as:<br> - a member of the RSVP directorate<br> - one of the early PCN design team<br> - a co-author of draft-lefaucheur-rsvp-ecn-01, on which this draft is based= .<br> <br> I would have missed any decision to use aggregate reservations. Pls point m= e to the relevant discussion (e.g. Subject line / date).<br> <br> I admit I tuned out of much of the later PCN signalling discussion. I found= the whole exercise of abstracting PCN away from specific signalling protoc= ols highly tedious; it meant we couldn't sensibly address important issues = like message reliability, timeliness etc. <br> <br> Nonetheless, here's why I believe RSVP aggregation is redundant:<br> <br> PCN edge-nodes support the concept of an ingress-egress aggregate in their = own internal tables, but they don't need to refer to an aggregate on the wi= re{Note 1}. PCN-ingress and PCN-egress nodes intrinscially know which e2e r= eservations belong to which aggregate by grouping together those e2e reservations with the same next hop or prev= ious hop respectively.<br> <br> {Note 1: except in one case described later - but it doesn't require all th= e other baggage of aggregate reservations}<br> <br> =3D=3DBackground=3D=3D<br> Aggregate reservations [RFC3175, RFC4860] are designed to reduce the state = required on interior nodes. Interior nodes still require state per aggregat= e reservation, but only reservation state, not classification and schedulin= g state [RFC3175, Section 1.4.1 last para].<br> <br> In contrast, as you correctly point out (in Section 2.1.7), PCN requires ab= solutely no reservation-related state on interior nodes.<br> <br> =3D=3DDisadvantages=3D=3D<br> Requiring PCN to use aggregate reservations has the following three disadva= ntages and no advantages:<br> <br> 1) Redundant Processing<br> The PATH message between aggregator and deaggregator in rsvp-pcn-03 (trigge= red by an E2E PathErr message from deaggregator to aggregator) is redundant= , and just doubles the processing required at the PCN-edge-nodes (if this i= sn't obvious, I spell it out separately for PATH & RESV messages below). <br> <br> 2) Reduced Resilience<br> Not only is an aggregate PATH redundant, it actually reduces resilience. Be= cause an aggregate PATH is pinned to interior routers. Therefore, when rout= ing changes, it is more complex and slower to move to the new route. By not= pinning to interior routers, PCN was designed to 'just work' over interior routing changes - with no need f= or any changes to the RSVP PATHs. (But it would still detect overload after= a re-route and terminate or rate-reduce flows if necessary.)<br> <br> 3) Extra Latency<br> A further disadvantage is the extra latency required for the first reservat= ion that sets up an aggregate. This is two ingress-egress round trips minus= the round trip time from egress to destination (or one ingress-egress roun= d trip if it is greater). This will rarely add to latency on heavily used ingress-egress aggregates, but it wi= ll occur frequently on all the 'long-tail' (lightly used) ingress-egress ag= gregates.<br> <br> =3D=3DPATH=3D=3D<br> <br> With RFC 3175 or 4860 aggregate paths, the aggregator forwards the e2e PATH= messages with IP protocol number RSVP-E2E-IGNORE and the deaggregator chan= ges them back to RSVP before forwarding onward. Also the aggregator sends a= n aggregate PATH message, which is processed by each interior node and by the deaggregator.<br> <br> On a path across a PCN region, given interior nodes ignore aggregate PATH m= essages as well, the only PCN nodes that handle aggregate messages are the = aggregator and the deaggregator. The aggregator and deaggregator process al= l the e2e PATH messages anyway, so if we require the aggregator to add up all the e2e PATH messages and fo= rm them into an aggregate PATH message, this is just extra redundant work f= or both PCN-edge-nodes.<br> <br> =3D=3DRESV=3D=3D<br> <br> The deaggregator unicasts e2e RESV messages to the previous RSVP hop, which= is the aggregator. Therefore, if we require the deaggregator to add up all= the RESV messages and form them into an aggregate RESV message, this is ju= st redundant work for both PCN-edge-nodes, because they both already process all the e2e RESV messages anyway, and no= other node uses the aggregate RESV messages.<br> <br> =3D=3DPCN object=3D=3D<br> <br> This raises the question of how the PCN-egress communicates the various mar= king rates (the PCN object) to the PCN-ingress. There are two possibilities= :<br> i) the PCN-egress includes a current PCN object in each e2e RESV that it re= turns to the PCN-ingress. The PCN-ingress strips the PCN object out before = forwarding the RESV back to the previous RSVP hop.<br> ii) the PCN-egress attaches a PCN object to an aggregate reservation, as in= pcn-rsvp-03.<br> <br> Either are possible, because a PCN object carries information about marking= probabilities, and PCN works on the assumption that the marking probabilit= y of an ingress-egress aggregate is the same as the marking probability of = the flows within the aggregate. A PCN object can be contained either in an e2e RESV or an aggregate RESV a= s long as the PCN-ingress can associate an e2e RESV with the correct aggreg= ate (which it can, because it maintains an internal table of mappings betwe= en e2e reservations and their aggregates).<br> <br> Which of the two is best is a question of message timing...<br> <br> * For e2e admission decisions, the PCN object is only needed at the time ea= ch e2e RESV is sent, so option i) makes sense.<br> <br> * For flow rate reduction or flow termination decisions, the deaggregator n= eeds to regularly send PCN objects to the ingress. <br> <br> The PCN-egress is sending regular e2e RESV refresh messages to the PCN-ingr= ess, so a PCN object can be included in each of these. To ensure that PCN o= bjects are sent often enough, I suggest the PCN-egress also maintains a tim= er per ingress-egress aggregate which it resets every time it sends a PCN object for that IEA. If the time= r expires, the PCN-egress sends a PCN object to the PCN-egress even thought= it was not triggered by an e2e RESV refresh. We could require the SESSION = object in this message to refer to either of:<br> a) any one of the e2e SESSIONs in the aggregate, <br> b) the aggregate.<br> <br> In case (a), the message would need to somehow tell the ingress not to forw= ard this RESV refresh to the RSVP previous hop.<br> <br> In case (b) in the PCN-ingress table of mappings between e2e SESSIONs and a= ggregate SESSIONs, it would include an entry for the aggregate that maps to= itself. If the result of the look-up is the same as the input, it knows no= t to forward the RESV refresh further. <br> <br> The wire protocol doesn't need to identify whether the SESSION is an aggreg= ate or not. This is the one case I mentioned at the start {Note 1} where an= aggregate is referred to on the wire.<br> <br> <br> <br> In summary, PCN already reduces reservation state and processing to nothing= on interior nodes. Adding aggregate reservations to PCN requires more proc= essing and state, it unnecessarily pins routes to interior nodes and adds u= nnecessary latency.<br> <br> <br> Bob<br> <br> At 18:23 14/11/2012, <a href=3D"mailto:karagian@cs.utwente.nl">karagian@cs.= utwente.nl</a> wrote:<br> <blockquote type=3D"cite" class=3D"cite" cite=3D"x-msg://1934/">Hi Bob,<br>  <br> Regarding the generic aggregated RSVP selection, actually the PCN WG agreed= with this selection!<br> This was actually the first step that was needed for this work, and the PCN= WG had no main objections on this selection!<br>  <br> So I do not understand your remark that your comment will have major implic= ations!<br>  <br> Please note that the generic aggregated RSVP is selected since the PCN IEA = are associated with flows that are aggregated at the edges. So a signalling= protocol that supports aggregation of flows at the edges is very suitable = for this purpose! The generic aggregated RSVP is such a signalling protocol!<br>  <br>  <br> Best regards,<br> Georgios<br>  <br>  <br>  <br>  <br> <b>From:</b> Bob Briscoe [<a href=3D"mailto:bob.briscoe@bt.com">mailto:bob.= briscoe@bt.com</a>] <br> <b>Sent:</b> woensdag 14 november 2012 12:57<br> <b>To:</b> Anurag Bhargava (anuragb)<br> <b>Cc:</b> Karagiannis, G. (EWI)<br> <b>Subject:</b> Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br>  <br> Anurag,<br> <br> I have my comments half-written up. I will try to finish them by the end of= today.<br> <br> They should be orthogonal to the PBAC comment below, so if you wanted to st= art altering that area, I don't think it would waste too much time. <br> <br> However, my main comments will concern the use of aggregated reservations (= as I said at the mic), so that could have major implications.<br> <br> <br> Bob<br> <br> At 20:14 13/11/2012, Anurag Bhargava (anuragb) wrote:<br> <br> Hi Bob,<br>  Thanks for the comments. If U have some text that will be great els I= have also started putting some text on the topic U brought up.<br>  May be we can conference after US thanksgiving week and collaborate t= he text and try to move forward.<br> <br>  Please let us know what might be a good time and I can schedule a Web= ex conf.<br> <br> Thx<br> -Anurag<br> <br> From: "<a href=3D"mailto:karagian@cs.utwente.nl">karagian@cs.utwente.n= l</a> " <<a href=3D"mailto:karagian@cs.utwente.nl">karagian@cs.utwe= nte.nl</a> ><br> Date: Saturday, November 10, 2012 8:10 AM<br> To: "<a href=3D"mailto:bob.briscoe@bt.com">bob.briscoe@bt.com</a>"= ; <<a href=3D"mailto:bob.briscoe@bt.com">bob.briscoe@bt.com</a>><br> Cc: "<a href=3D"mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>&qu= ot; <<a href=3D"mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>>,= Anurag Bhargava <<a href=3D"mailto:anuragb@cisco.com">anuragb@cisco.com= </a>>, "<a href=3D"mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>" <<a href=3D"mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>>, "<a hre= f=3D"mailto:philip.eardley@bt.com">philip.eardley@bt.com</a> " <<a = href=3D"mailto:philip.eardley@bt.com">philip.eardley@bt.com</a> ><br> Subject: RE: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br> <br> Hi Bob,<br> <br>  <br> <br> Thanks very much for the comments! I think that they are very useful! <br> <br>  <br> <br> It will be very beneficiary for the fast progress of this draft if you woul= d like to contribute as a co-author to this draft and write this additional= section that describes "that the PCN-ingress can refer flow admission= and <br> termination decisions to a central decision point (using e.g. COPS), which = will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingr= ess could itself be the policy decision point.)"<br> <br>  <br> <br> Best regards,<br> <br> Georgios<br> <br>  <br> <hr> <b>Van:</b> Bob Briscoe [<a href=3D"mailto:bob.briscoe@bt.com">bob.briscoe@= bt.com</a>]<br> <b>Verzonden:</b> vrijdag 9 november 2012 16:33<br> <b>To:</b> Karagiannis, G. (EWI)<br> <b>Cc:</b> <a href=3D"mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>; = <a href=3D"mailto:anuragb@cisco.com"> anuragb@cisco.com</a>; <a href=3D"mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>= ; EARDLEY, Phil<br> <b>Onderwerp:</b> Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br> <br> Georgios,<br> <br> I shall post my full review of this draft in the next few days (needs <br> typing up - currently scribbled on a paper copy). This email is <br> solely in response to your answer about on-path vs off-path policy.<br> <br> At 18:55 04/11/2012, <a href=3D"mailto:karagian@cs.utwente.nl">karagian@cs.= utwente.nl</a> wrote:<br> >So in this case an additional signaling protocol will be<br> >needed to be specified that covers the signaling between the <br> >PCN-egress-node and the centralized node<br> >and between PCN-ingress-node and the centralized node.<br> >In PCN we decdided to only focus on the specification of the <br> >signaling protocol that completes the<br> >feedback loop from PCN-egress-node to PCN-ingress-node and to focus <br= > >on the signaling protocol<br> >used between the edge nodes and the centralized node.<br> <br> When I/we originally designed CL-PCN over RSVP (2005), the idea was <br> that it would fit with the policy-based admission control (PBAC) <br> architecture of RFC2753. In this architecture, an Intserv node at the <br> ingress to a domain is the policy enforcement point (PEP), and it <br> refers to a logically centralised 'policy decision point' (PDP) for <br> decisions on which flows to block/terminate, typically using COPS.<br> <br> To make this doc fit the PBAC framework, all we have to do is:<br> * Describe the PCN-ingress only as the PCN-ingress and not as the <br> decision point (find 'decision' throughout doc and fix).<br> * Add a section saying the PCN-ingress can refer flow admission and <br> termination decisions to a central decision point (using e.g. COPS), <br> which will respond to the PCN-ingress as per RFC2753. (Alternatively <br> the PCN-ingress could itself be the policy decision point.)<br> * Refer to this new PBAC section from Section 3.11 giving the <br> admission decision procedure.<br> <br> * Some people might think this means COPS will need new protocol <br> elements to carry PCN marking rates to the policy decision point. But <br> PCN marking rates are irrelevant to the policy decision: the <br> PCN-ingress just uses PCN to determine whether it needs to block or <br> terminate, and it refers to the policy decision point for which flows <br> to block/terminate.<br> <br> * Unfortunately, neither of the two PCN system descriptions [RFC6661, <br> RFC6662] describe a PBAC-based case. The architecture [RFC5559] <br> refers to the PBAC framework [RFC2753] but unfortunately doesn't <br> spell out how it fits. Originally, I referenced PBAC from RFC5559, <br> but just as the PCN w-g was closing I realised that (some?) others in <br> the PCN w-g were working under the assumption that the only way to <br> talk to a centralised policy node was from the egress, possibly <br> without being aware of the contents of RFC2753.<br> <br> I think it's OK to introduce a new architectural arrangement in this <br> RSVP doc, given RFC2753 is specific to the way RSVP works.<br> <br> <br> Bob<br> <br> <br> <br> At 12:28 05/11/2012, <a href=3D"mailto:karagian@cs.utwente.nl">karagian@cs.= utwente.nl</a> wrote:<br> >Hi Ken,<br> ><br> >Thank you very much!<br> >We will try to catch Francois and discuss the last (in line) issue with= him!<br> ><br> >Best regards,<br> >Georgios<br> ><br> >________________________________________<br> >Van: ken carlberg [<a href=3D"mailto:carlberg@g11.org.uk">carlberg@g11.= org.uk</a>]<br> >Verzonden: maandag 5 november 2012 13:23<br> >To: Karagiannis, G. (EWI)<br> >Cc: <a href=3D"mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>; <a href=3D"ma= ilto:anuragb@cisco.com"> anuragb@cisco.com</a><br> >Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03<br> ><br> >Georgios,<br> ><br> > > Georgios: We will try to explain the rationale of why we consider= <br> > that RSVP can only be used for the situation that the<br> > > decision point is collocated with the PCN-ingress-node. The main = <br> > reason of this is that in the case that the<br> > > decision point is collocated with the PCN-ingress-node,the <br> > required signaling protocol used to complete a<br> > > feedback loop from egress to ingress can be an entirely on-path <= br> > protocol, like what RSVP is.<br> > > In the situation that the the decision point is a centralized <br= > > node, then the required signaling protocol<br> > > can be a combination of an on-path and off-path protocol. This is= <br> > because the<br> > > decision point might not be located on the data path! So in this = <br> > case an additional signaling protocol will be<br> > > needed to be specified that covers the signaling between the <br> > PCN-egress-node and the centralized node<br> > > and between PCN-ingress-node and the centralized node.<br> > > In PCN we decdided to only focus on the specification of the <br> > signaling protocol that completes the<br> > > feedback loop from PCN-egress-node to PCN-ingress-node and to <br= > > focus on the signaling protocol<br> > > used between the edge nodes and the centralized node.<br> > > This is also the reason of why PCN WG decided to only focus on <b= r> > the situation that the decision point is<br> > > collocated with the PCN-ingress-node.<br> ><br> >Great, this is helpful, and this is the information that needs to be <b= r> >in the draft.<br> ><br> > >> 6) This comment is just for you to contemplate -- I'm not <br= > > expecting any changes.<br> > >> I noticed that you have a fair number of SHOULD, and some SHO= ULD NOTs.<br> > >> And it seems a lot of this is a carry over from rfc-4860, so = in <br> > a sense you are inheriting an approach that<br> > >> was agreed to from an earlier effort.  But I wonder in t= he back <br> > of my mind, what impact occurs if<br> > >> an implementor doesn't follow the SHOULD?  Does the desi= gn break <br> > in supporting PCN?<br> > >> Again, I want to stress that this isnt a show stopper, but I = <br> > would appreciate it if you gave it some thought.<br> > ><br> > > Georgios: Yes, in several cases the design might break in support= ing PCN.<br> > > This is also the reason of using SHOULD instead of MAY. Do you <b= r> > want us to explain this in more detail in the draft?<br> ><br> >well, actually, I was more curious as to why a number of these cases <b= r> >are SHOULD instead of MUST.  Again, the SHOULD's in your document = <br> >seem to be a carry-over from rfc-4860 (which set the precedent), so <br= > >its a bit unfair for you to explain what was done in an earlier <br> >effort.  I just wanted to make sure you gave some thought to the <= br> >subject.  And if things will break if SHOULD is not followed by an= <br> >implementer/configuration, then maybe you should be more stringent <br> >and change things to MUST.  Perhaps a brief private conversation <= br> >with Francois Le Faucheur will be helpful.<br> ><br> >cheers,<br> ><br> >-ken<br> <br> ________________________________________________________________<br> Bob Briscoe,          &nb= sp;            =          BT Innovate & Design <= br> <br> ________________________________________________________________<br> Bob Briscoe,          &nb= sp;            =          BT Innovate & Design</= blockquote> <br> ________________________________________________________________<br> Bob Briscoe,          &nb= sp;            =          BT Innovate & Design <= /blockquote> <br> ________________________________________________________________<br> Bob Briscoe,          &nb= sp;            =          BT Innovate & Design <= /blockquote> <x-sigsep> <p>________________________________________________________________<br> Bob Briscoe,          &nb= sp;            =          BT Innovate & Design</= p> </x-sigsep></div> </blockquote> </div> <br> </div> </body> </html> --_000_FC236DA6F2DA77449EF2D02DF4471A8D258244xmbrcdx10ciscocom_-- From karagian@cs.utwente.nl Thu Nov 22 07:50:42 2012 Return-Path: <karagian@cs.utwente.nl> 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 B593B21F883B; Thu, 22 Nov 2012 07:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.321 X-Spam-Level: **** X-Spam-Status: No, score=4.321 tagged_above=-999 required=5 tests=[AWL=4.224, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phK47mF2rL8G; Thu, 22 Nov 2012 07:50:29 -0800 (PST) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0C88221F8807; Thu, 22 Nov 2012 07:50:27 -0800 (PST) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 22 Nov 2012 16:50:37 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.65]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.02.0318.004; Thu, 22 Nov 2012 16:50:26 +0100 From: <karagian@cs.utwente.nl> To: <flefauch@cisco.com>, <bob.briscoe@bt.com> Thread-Topic: [tsvwg] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 Thread-Index: AQHNyLbwrdcqdznDREGhgIxXhIDu1Jf1/VBg Date: Thu, 22 Nov 2012 15:50:25 +0000 Message-ID: <FF1A9612A94D5C4A81ED7DE1039AB80F2ED90D42@EXMBX04.ad.utwente.nl> References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <E728D0E3C41E644A96A7CCA61863BED4081DE009@xmb-aln-x12.cisco.com> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> <FF1A9612A94D5C4A81ED7DE1039AB80F2ED8FEDF@EXMBX04.ad.utwente.nl> <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> <38323AE1-362C-4DBF-87A0-2D468586CC53@mimectl> <201211162014.qAGKEYxK014300@bagheera.jungle.bt.co.uk> <1E38B46D-C270-4D6E-B97A-619C00259FEC@mimectl> <201211202129.qAKLTPGC002799@bagheera.jungle.bt.co.uk> <FC236DA6F2DA77449EF2D02DF4471A8D258244@xmb-rcd-x10.cisco.com> In-Reply-To: <FC236DA6F2DA77449EF2D02DF4471A8D258244@xmb-rcd-x10.cisco.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.129] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F2ED90D42EXMBX04adutwent_" MIME-Version: 1.0 Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, slblake@petri-meat.com, philip.eardley@bt.com, anuragb@cisco.com, sob@harvard.edu, rsvp-dir@ietfa.amsl.com, pcn@ietf.org, jmpolk@cisco.com Subject: Re: [tsvwg] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 22 Nov 2012 15:50:43 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F2ED90D42EXMBX04adutwent_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Francois, Thank you very much for summarizing our discussion! Please note that an additional e2e RSVP signalling challenge associated to = Option B can be identified! What happens in the situation where there is a change of route for a given = e2e RSVP reservation/session (i.e. changing its PCN-ingress-node and/or PCN= -egress-node) right when the PCN-egress-node decides to use a e2e RSVP signalling message= (associated with this e2e RSVP session) to notify the aggregate PCN inform= ation (PCN admission control and/or flow termination information) to the PCN-ingr= ess-node? In this situation it is possible that the aggregated PCN information will n= ot be received by the right PCN-ingress-node, having as implication that th= e congestion in the PCN domain will not be solved accurately and in time! Best regards, Georgios From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] Sent: donderdag 22 november 2012 14:40 To: Bob Briscoe Cc: Francois Le Faucheur (flefauch); Karagiannis, G. (EWI); <gorry@erg.abdn= .ac.uk>; <tsvwg@ietf.org>; <slblake@petri-meat.com>; <philip.eardley@bt.com= >; Anurag Bhargava (anuragb); <sob@harvard.edu>; <rsvp-dir@ietfa.amsl.com>;= <pcn@ietf.org>; James Polk (jmpolk) Subject: Re: [tsvwg] Redundant aggregate reservations: draft-ietf-tsvwg-rsv= p-pcn-03 Hello Bob, Georgios, >From a scan of the thread and an off-line discussion with Georgios, my perc= eption of the situation is: * PCN edges need to maintain logical aggregate constructs (i.e. ingress-egr= ees PCN state) and map e2e reservations to these aggregate constructs * we need to convey aggregate PCN info from edge to edge * no actual reservation state is needed inside the PCN Core This could be achieved by: (A): * adapting RFC 4860 aggregation procedures to fit PCN with as little change= as possible over RFC4860 * hence performing aggregate RSVP signaling (even if it is to be ignored by= PCN interior nodes) * using this aggregate RSVP signaling to convey PCN info edge to edge OR (B): * adapting RFC 4860 aggregation procedures to fit PCN with more significant= changes over RFC4860 (i.e. you keep the aspect of the procedures that have= to do with maintaining aggregate states and to do with mapping e2e to aggr= egates, but you drop procedures that have too do with aggregate RSVP signal= ing and aggregate reservation establishment/maintenance) * hence not performing aggregate RSVP signaling * piggy-backing PCN info inside e2e RSVP signaling. I think both approaches are probably viable. I tend to think the difference= between the two is actually not that big at the end of the day because the= key of the logic is how you maintain aggregate states at the edge and how = you map 2e2 RSVP to these aggregates (i.e. the concept of aggregation withi= n RFC4860 - independently of the notion of aggregate RSVP signaling) and I = don't think the ingress-egress signaling channel (i.e. aggregate RSVP or e2= e RSVP) is so significant given the PCN specifics. I think the drawbacks you pointed out, Bob, in your initial message are pro= bably not as serious as you suggested, given aggregate RSVP signaling would= be ignored by interior nodes (for example, I don't see why aggregate RSVP = signaling would impact rerouting inside the PCN core since packets from ind= ividual sessions would be routed independently of the reservation. As anoth= er example you mentioned that it might double the signaling processing load= on edges while i suspect it would only increase by some fraction given the= level of aggregate signaling should be much lower than collective e2e sign= aling). Nevertheless, If an approach along the lines of (B) removes the dra= wbacks completely while behaving as well, then that may be a better approac= h. An attractive properly of (A) is that RFC4860 operations has been thought t= hrough and there has been some implementation of RSVP Aggregation, so we ha= ve some confidence that the solution can deal with the more challenging sit= uations (rerouting in core, failure of an ingress edge, failure of an egres= s edge, rerouting towards a different edge,...). My suggestion would be to try identify if a (B)-type approach can be devise= d with comparable properties in dealing with basic as well as more challeng= ing situations, or conversely if the (A)-type approach really has some supe= rior behavior afforded by the extra ingress-egress dedicated signaling chan= nel. That should be a key deciding factor. Perhaps Georgios could look into this direction? I hope that helps Francois Caveat: I am operating based on slowly-but-surely fainting intimacy with PC= N and RSVP aggregation technologies On 20 Nov 2012, at 22:29, Bob Briscoe wrote: Georgios, See other email. Pls focus on the specifics (you will need to go back to my= original email in the thread, because the specifics were immediately cut f= rom the thread when Tom understood them). The IETF can choose to continue along a path that it originally agreed, whe= ther right or wrong, but it is important to discuss whether it is right or = wrong first. Bob At 10:29 17/11/2012, karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl> = wrote: Hi Bob, So, what you actually proposing is to discard a specification that has been= accepted by both PCN and tsvwg WGs to be considered as a WG specification = and to use a specification that you are proposing and that is conceptually = and architecturally wrong. The solution that you are proposing, i.e., use of the e2e RSVP (RFC2205), i= s in my opinion architecturally and conceptually wrong! The reason is the following! In PCN we need a signaling protocol that is able to: (1) to carry informati= on from PCN-egress-edge to PCN-ingress-edge and (2) the carried information= needs to be related to an aggregated state, i.e., the ingress-egress-aggre= gate state. The e2e RSVP (RFC2205) can only support requirement (1), but is not able to= support (2), since the e2e RSVP carries information that is associated wit= h a per flow state maintained at the edges. Aggregated RSVP (RFC3175) and Generic Aggregated RSVP (RFC4860) can support= both requirements, since one of the features that are supported by both is= to carry objects that are associated to an aggregated state maintained at = the edges. In the context of PCN, the aggregated state is the ingress egres= s aggregate state. Best regards, Georgios ________________________________ Van: Bob Briscoe [bob.briscoe@bt.com<mailto:bob.briscoe@bt.com>] Verzonden: vrijdag 16 november 2012 21:14 To: Karagiannis, G. (EWI) Cc: carlberg@g11.org.uk<mailto:carlberg@g11.org.uk>; tsvwg@ietf.org<mailto:= tsvwg@ietf.org>; philip.eardley@bt.com<mailto:philip.eardley@bt.com>; pcn@i= etf.org<mailto:pcn@ietf.org>; rsvp-dir@ietfa.amsl.com<mailto:rsvp-dir@ietfa= .amsl.com>; sob@harvard.edu<mailto:sob@harvard.edu>; slblake@petri-meat.com= <mailto:slblake@petri-meat.com>; gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn= .ac.uk>; jmpolk@cisco.com<mailto:jmpolk@cisco.com>; anuragb@cisco.com<mailt= o:anuragb@cisco.com> Onderwerp: RE: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-= 03 Georgios, Yes, I apologise for not reviewing earlier. I appreciate you followed the p= rocedure. My problem was that a quick read of tsvwg-rsvp-pcn wasn't enough to underst= and it. So I stayed quiet even though I wasn't so happy about the direction= , because I didn't have enough understanding to feel I could argue. Only in the last week or so, I collected together all the references and re= -read them and their references, and made a concerted effort to understand = what your draft was proposing. I have to say, it was quite a struggle (over= a few days and the write-up took 2 days). However, I admit that it would have been preferable for everyone if I had m= ade this effort earlier. Bob At 13:02 16/11/2012, karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl> = wrote: Hi Bob, $B!!(B Thanks for your comments! Regarding your statement: What I meant in my previous email is that our ind= ividual draft that was used as a working basis for this WG draft was alrea= dy using the generic aggregation RSVP (RFC 4860) as the existing signaling = protocol, see: http://tools.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt Moreover, during IETF 81, this individual draft has been presneted, where a= lso the rationale of using (RFC 4860) was also the following slides see pre= sentation slides (slide 5): http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf $B!!(B In particular in slide 4 mentions: "All PCN charter items are fulfilled, except: Submit Encoding and Transport of PCN from Domain Egress to Ingress to the I= ESG for consideration as a Proposed Standard RFC Pairs of PCN edge nodes use ingress-egress-aggregates (IEA): Need a signaling protocol to transport PCN information from PCN-egress-node= to PCN-ingress-node and to maintain ingress-egress-aggregate between each = pair of PCN edge nodes" Furthermore Slide 5 mentions: $B!!(B "IETF QoS signaling protocols to solve problem: Next Steps in Signaling Protocol (NSIS) subset (RFC 5971, RFC 5974, RFC 597= 9) Aggregation of RSVP for IPv4 and IPv6 Reservations (RFC3175) Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations (RFC486= 0) All can be used, but for time being selected RFC 4860 due: possible deployment interest supports RFC 3175 and additional features such as: support of multiple IEAs from same pair of PCN edge nodes support of bandwidth reduction for individual flows (RFC 4495)" $B!!(B Before IETF 81 and during IETF 81 this point has been discussed. The outcome of these discussions is that short after IETF 81, the individua= l draft (draft-karagiannis-pcn-tsvwg-rsvp-pcn-01) become (after small modifications) the draft-ietf-tsvwg-rsvp-pcn-00, which = also was using RFC 4860 as the base signaling protocol. $B!!(B It will be very helpful if the PCN WG chairs (Scott and/or Steve) and the t= svwg WG chairs (Gorry and/or James) could confirm the above statement! $B!!(B So both the PCN WG and tsvwg WG agreed that this specifictaion should use a= s basis the generic RSVP aggregation protocol! $B!!(B $B!!(B $B!!(B In a subsequent email and on a later moment I will also answer to your furt= her remarks! $B!!(B Best regards, Georgios ________________________________ Van: Bob Briscoe [bob.briscoe@bt.com<mailto:bob.briscoe@bt.com>] Verzonden: donderdag 15 november 2012 14:07 To: Karagiannis, G. (EWI); anuragb@cisco.com<mailto:anuragb@cisco.com> Cc: carlberg@g11.org.uk<mailto:carlberg@g11.org.uk>; anuragb@cisco.com<mail= to:anuragb@cisco.com>; tsvwg@ietf.org<mailto:tsvwg@ietf.org>; philip.eardle= y@bt.com<mailto:philip.eardley@bt.com>; PCN IETF list; rsvp-dir@ietfa.amsl.= com<mailto:rsvp-dir@ietfa.amsl.com> Onderwerp: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 Georgios, Anurag, Below is the main point of my review, arguing that aggregate reservations a= re redundant. I'm reviewing as: - a member of the RSVP directorate - one of the early PCN design team - a co-author of draft-lefaucheur-rsvp-ecn-01, on which this draft is based= . I would have missed any decision to use aggregate reservations. Pls point m= e to the relevant discussion (e.g. Subject line / date). I admit I tuned out of much of the later PCN signalling discussion. I found= the whole exercise of abstracting PCN away from specific signalling protoc= ols highly tedious; it meant we couldn't sensibly address important issues = like message reliability, timeliness etc. Nonetheless, here's why I believe RSVP aggregation is redundant: PCN edge-nodes support the concept of an ingress-egress aggregate in their = own internal tables, but they don't need to refer to an aggregate on the wi= re{Note 1}. PCN-ingress and PCN-egress nodes intrinscially know which e2e r= eservations belong to which aggregate by grouping together those e2e reserv= ations with the same next hop or previous hop respectively. {Note 1: except in one case described later - but it doesn't require all th= e other baggage of aggregate reservations} =3D=3DBackground=3D=3D Aggregate reservations [RFC3175, RFC4860] are designed to reduce the state = required on interior nodes. Interior nodes still require state per aggregat= e reservation, but only reservation state, not classification and schedulin= g state [RFC3175, Section 1.4.1 last para]. In contrast, as you correctly point out (in Section 2.1.7), PCN requires ab= solutely no reservation-related state on interior nodes. =3D=3DDisadvantages=3D=3D Requiring PCN to use aggregate reservations has the following three disadva= ntages and no advantages: 1) Redundant Processing The PATH message between aggregator and deaggregator in rsvp-pcn-03 (trigge= red by an E2E PathErr message from deaggregator to aggregator) is redundant= , and just doubles the processing required at the PCN-edge-nodes (if this i= sn't obvious, I spell it out separately for PATH & RESV messages below). 2) Reduced Resilience Not only is an aggregate PATH redundant, it actually reduces resilience. Be= cause an aggregate PATH is pinned to interior routers. Therefore, when rout= ing changes, it is more complex and slower to move to the new route. By not= pinning to interior routers, PCN was designed to 'just work' over interior= routing changes - with no need for any changes to the RSVP PATHs. (But it = would still detect overload after a re-route and terminate or rate-reduce f= lows if necessary.) 3) Extra Latency A further disadvantage is the extra latency required for the first reservat= ion that sets up an aggregate. This is two ingress-egress round trips minus= the round trip time from egress to destination (or one ingress-egress roun= d trip if it is greater). This will rarely add to latency on heavily used i= ngress-egress aggregates, but it will occur frequently on all the 'long-tai= l' (lightly used) ingress-egress aggregates. =3D=3DPATH=3D=3D With RFC 3175 or 4860 aggregate paths, the aggregator forwards the e2e PATH= messages with IP protocol number RSVP-E2E-IGNORE and the deaggregator chan= ges them back to RSVP before forwarding onward. Also the aggregator sends a= n aggregate PATH message, which is processed by each interior node and by t= he deaggregator. On a path across a PCN region, given interior nodes ignore aggregate PATH m= essages as well, the only PCN nodes that handle aggregate messages are the = aggregator and the deaggregator. The aggregator and deaggregator process al= l the e2e PATH messages anyway, so if we require the aggregator to add up a= ll the e2e PATH messages and form them into an aggregate PATH message, this= is just extra redundant work for both PCN-edge-nodes. =3D=3DRESV=3D=3D The deaggregator unicasts e2e RESV messages to the previous RSVP hop, which= is the aggregator. Therefore, if we require the deaggregator to add up all= the RESV messages and form them into an aggregate RESV message, this is ju= st redundant work for both PCN-edge-nodes, because they both already proces= s all the e2e RESV messages anyway, and no other node uses the aggregate RE= SV messages. =3D=3DPCN object=3D=3D This raises the question of how the PCN-egress communicates the various mar= king rates (the PCN object) to the PCN-ingress. There are two possibilities= : i) the PCN-egress includes a current PCN object in each e2e RESV that it re= turns to the PCN-ingress. The PCN-ingress strips the PCN object out before = forwarding the RESV back to the previous RSVP hop. ii) the PCN-egress attaches a PCN object to an aggregate reservation, as in= pcn-rsvp-03. Either are possible, because a PCN object carries information about marking= probabilities, and PCN works on the assumption that the marking probabilit= y of an ingress-egress aggregate is the same as the marking probability of = the flows within the aggregate. A PCN object can be contained either in an = e2e RESV or an aggregate RESV as long as the PCN-ingress can associate an e= 2e RESV with the correct aggregate (which it can, because it maintains an i= nternal table of mappings between e2e reservations and their aggregates). Which of the two is best is a question of message timing... * For e2e admission decisions, the PCN object is only needed at the time ea= ch e2e RESV is sent, so option i) makes sense. * For flow rate reduction or flow termination decisions, the deaggregator n= eeds to regularly send PCN objects to the ingress. The PCN-egress is sending regular e2e RESV refresh messages to the PCN-ingr= ess, so a PCN object can be included in each of these. To ensure that PCN o= bjects are sent often enough, I suggest the PCN-egress also maintains a tim= er per ingress-egress aggregate which it resets every time it sends a PCN o= bject for that IEA. If the timer expires, the PCN-egress sends a PCN object= to the PCN-egress even thought it was not triggered by an e2e RESV refresh= . We could require the SESSION object in this message to refer to either of= : a) any one of the e2e SESSIONs in the aggregate, b) the aggregate. In case (a), the message would need to somehow tell the ingress not to forw= ard this RESV refresh to the RSVP previous hop. In case (b) in the PCN-ingress table of mappings between e2e SESSIONs and a= ggregate SESSIONs, it would include an entry for the aggregate that maps to= itself. If the result of the look-up is the same as the input, it knows no= t to forward the RESV refresh further. The wire protocol doesn't need to identify whether the SESSION is an aggreg= ate or not. This is the one case I mentioned at the start {Note 1} where an= aggregate is referred to on the wire. In summary, PCN already reduces reservation state and processing to nothing= on interior nodes. Adding aggregate reservations to PCN requires more proc= essing and state, it unnecessarily pins routes to interior nodes and adds u= nnecessary latency. Bob At 18:23 14/11/2012, karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl> = wrote: Hi Bob, Regarding the generic aggregated RSVP selection, actually the PCN WG agreed= with this selection! This was actually the first step that was needed for this work, and the PCN= WG had no main objections on this selection! So I do not understand your remark that your comment will have major implic= ations! Please note that the generic aggregated RSVP is selected since the PCN IEA = are associated with flows that are aggregated at the edges. So a signalling= protocol that supports aggregation of flows at the edges is very suitable = for this purpose! The generic aggregated RSVP is such a signalling protocol= ! Best regards, Georgios From: Bob Briscoe [mailto:bob.briscoe@bt.com] Sent: woensdag 14 november 2012 12:57 To: Anurag Bhargava (anuragb) Cc: Karagiannis, G. (EWI) Subject: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 Anurag, I have my comments half-written up. I will try to finish them by the end of= today. They should be orthogonal to the PBAC comment below, so if you wanted to st= art altering that area, I don't think it would waste too much time. However, my main comments will concern the use of aggregated reservations (= as I said at the mic), so that could have major implications. Bob At 20:14 13/11/2012, Anurag Bhargava (anuragb) wrote: Hi Bob, Thanks for the comments. If U have some text that will be great els I have= also started putting some text on the topic U brought up. May be we can conference after US thanksgiving week and collaborate the te= xt and try to move forward. Please let us know what might be a good time and I can schedule a Webex co= nf. Thx -Anurag From: "karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl> " <karagian@cs= .utwente.nl<mailto:karagian@cs.utwente.nl> > Date: Saturday, November 10, 2012 8:10 AM To: "bob.briscoe@bt.com<mailto:bob.briscoe@bt.com>" <bob.briscoe@bt.com<mai= lto:bob.briscoe@bt.com>> Cc: "carlberg@g11.org.uk<mailto:carlberg@g11.org.uk>" <carlberg@g11.org.uk<= mailto:carlberg@g11.org.uk>>, Anurag Bhargava <anuragb@cisco.com<mailto:anu= ragb@cisco.com>>, "tsvwg@ietf.org<mailto:tsvwg@ietf.org>" <tsvwg@ietf.org<m= ailto:tsvwg@ietf.org>>, "philip.eardley@bt.com<mailto:philip.eardley@bt.com= > " <philip.eardley@bt.com<mailto:philip.eardley@bt.com> > Subject: RE: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 Hi Bob, Thanks very much for the comments! I think that they are very useful! It will be very beneficiary for the fast progress of this draft if you woul= d like to contribute as a co-author to this draft and write this additional= section that describes "that the PCN-ingress can refer flow admission and termination decisions to a central decision point (using e.g. COPS), which = will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingr= ess could itself be the policy decision point.)" Best regards, Georgios ________________________________ Van: Bob Briscoe [bob.briscoe@bt.com<mailto:bob.briscoe@bt.com>] Verzonden: vrijdag 9 november 2012 16:33 To: Karagiannis, G. (EWI) Cc: carlberg@g11.org.uk<mailto:carlberg@g11.org.uk>; anuragb@cisco.com<mail= to:anuragb@cisco.com>; tsvwg@ietf.org<mailto:tsvwg@ietf.org>; EARDLEY, Phil Onderwerp: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 Georgios, I shall post my full review of this draft in the next few days (needs typing up - currently scribbled on a paper copy). This email is solely in response to your answer about on-path vs off-path policy. At 18:55 04/11/2012, karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl> = wrote: >So in this case an additional signaling protocol will be >needed to be specified that covers the signaling between the >PCN-egress-node and the centralized node >and between PCN-ingress-node and the centralized node. >In PCN we decdided to only focus on the specification of the >signaling protocol that completes the >feedback loop from PCN-egress-node to PCN-ingress-node and to focus >on the signaling protocol >used between the edge nodes and the centralized node. When I/we originally designed CL-PCN over RSVP (2005), the idea was that it would fit with the policy-based admission control (PBAC) architecture of RFC2753. In this architecture, an Intserv node at the ingress to a domain is the policy enforcement point (PEP), and it refers to a logically centralised 'policy decision point' (PDP) for decisions on which flows to block/terminate, typically using COPS. To make this doc fit the PBAC framework, all we have to do is: * Describe the PCN-ingress only as the PCN-ingress and not as the decision point (find 'decision' throughout doc and fix). * Add a section saying the PCN-ingress can refer flow admission and termination decisions to a central decision point (using e.g. COPS), which will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingress could itself be the policy decision point.) * Refer to this new PBAC section from Section 3.11 giving the admission decision procedure. * Some people might think this means COPS will need new protocol elements to carry PCN marking rates to the policy decision point. But PCN marking rates are irrelevant to the policy decision: the PCN-ingress just uses PCN to determine whether it needs to block or terminate, and it refers to the policy decision point for which flows to block/terminate. * Unfortunately, neither of the two PCN system descriptions [RFC6661, RFC6662] describe a PBAC-based case. The architecture [RFC5559] refers to the PBAC framework [RFC2753] but unfortunately doesn't spell out how it fits. Originally, I referenced PBAC from RFC5559, but just as the PCN w-g was closing I realised that (some?) others in the PCN w-g were working under the assumption that the only way to talk to a centralised policy node was from the egress, possibly without being aware of the contents of RFC2753. I think it's OK to introduce a new architectural arrangement in this RSVP doc, given RFC2753 is specific to the way RSVP works. Bob At 12:28 05/11/2012, karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl> = wrote: >Hi Ken, > >Thank you very much! >We will try to catch Francois and discuss the last (in line) issue with hi= m! > >Best regards, >Georgios > >________________________________________ >Van: ken carlberg [carlberg@g11.org.uk<mailto:carlberg@g11.org.uk>] >Verzonden: maandag 5 november 2012 13:23 >To: Karagiannis, G. (EWI) >Cc: tsvwg@ietf.org<mailto:tsvwg@ietf.org>; anuragb@cisco.com<mailto:anurag= b@cisco.com> >Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03 > >Georgios, > > > Georgios: We will try to explain the rationale of why we consider > that RSVP can only be used for the situation that the > > decision point is collocated with the PCN-ingress-node. The main > reason of this is that in the case that the > > decision point is collocated with the PCN-ingress-node,the > required signaling protocol used to complete a > > feedback loop from egress to ingress can be an entirely on-path > protocol, like what RSVP is. > > In the situation that the the decision point is a centralized > node, then the required signaling protocol > > can be a combination of an on-path and off-path protocol. This is > because the > > decision point might not be located on the data path! So in this > case an additional signaling protocol will be > > needed to be specified that covers the signaling between the > PCN-egress-node and the centralized node > > and between PCN-ingress-node and the centralized node. > > In PCN we decdided to only focus on the specification of the > signaling protocol that completes the > > feedback loop from PCN-egress-node to PCN-ingress-node and to > focus on the signaling protocol > > used between the edge nodes and the centralized node. > > This is also the reason of why PCN WG decided to only focus on > the situation that the decision point is > > collocated with the PCN-ingress-node. > >Great, this is helpful, and this is the information that needs to be >in the draft. > > >> 6) This comment is just for you to contemplate -- I'm not > expecting any changes. > >> I noticed that you have a fair number of SHOULD, and some SHOULD NOTs. > >> And it seems a lot of this is a carry over from rfc-4860, so in > a sense you are inheriting an approach that > >> was agreed to from an earlier effort. But I wonder in the back > of my mind, what impact occurs if > >> an implementor doesn't follow the SHOULD? Does the design break > in supporting PCN? > >> Again, I want to stress that this isnt a show stopper, but I > would appreciate it if you gave it some thought. > > > > Georgios: Yes, in several cases the design might break in supporting PC= N. > > This is also the reason of using SHOULD instead of MAY. Do you > want us to explain this in more detail in the draft? > >well, actually, I was more curious as to why a number of these cases >are SHOULD instead of MUST. Again, the SHOULD's in your document >seem to be a carry-over from rfc-4860 (which set the precedent), so >its a bit unfair for you to explain what was done in an earlier >effort. I just wanted to make sure you gave some thought to the >subject. And if things will break if SHOULD is not followed by an >implementer/configuration, then maybe you should be more stringent >and change things to MUST. Perhaps a brief private conversation >with Francois Le Faucheur will be helpful. > >cheers, > >-ken ________________________________________________________________ Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design --_000_FF1A9612A94D5C4A81ED7DE1039AB80F2ED90D42EXMBX04adutwent_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <!--[if !mso]><style>v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style><![endif]--><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p {mso-style-priority:99; mso-margin-top-alt:auto; margin-right:0cm; mso-margin-bottom-alt:auto; margin-left:0cm; font-size:12.0pt; font-family:"Times New Roman","serif";} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0cm; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.apple-tab-span {mso-style-name:apple-tab-span;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} span.EmailStyle21 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:612.0pt 792.0pt; margin:70.85pt 70.85pt 70.85pt 70.85pt;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"NL" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">Hi Francoi= s,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">Thank you = very much for summarizing our discussion!<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">Please not= e that an additional e2e RSVP signalling challenge associated to Option B c= an be identified!<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">What happe= ns in the situation where there is a change of route for a given e2e RSVP r= eservation/session (i.e. changing its PCN-ingress-node and/or PCN-egress-node) <o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">right when= the PCN-egress-node decides to use a e2e RSVP signalling message (associat= ed with this e2e RSVP session) to notify the aggregate PCN information <o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">(PCN admis= sion control and/or flow termination information) to the PCN-ingress-node?<= o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">In this si= tuation it is possible that the aggregated PCN information will not be rece= ived by the right PCN-ingress-node, having as implication that the congestion <o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">in the PCN= domain will not be solved accurately and in time!<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">Best regar= ds,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">Georgios<o= :p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo= nt-family:"Tahoma","sans-serif"">From:</span></b><span = lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma",&qu= ot;sans-serif""> Francois Le Faucheur (flefauch) [mailto:flefauch@cisc= o.com] <br> <b>Sent:</b> donderdag 22 november 2012 14:40<br> <b>To:</b> Bob Briscoe<br> <b>Cc:</b> Francois Le Faucheur (flefauch); Karagiannis, G. (EWI); <gorr= y@erg.abdn.ac.uk>; <tsvwg@ietf.org>; <slblake@petri-meat.com>= ;; <philip.eardley@bt.com>; Anurag Bhargava (anuragb); <sob@harvar= d.edu>; <rsvp-dir@ietfa.amsl.com>; <pcn@ietf.org>; James Pol= k (jmpolk)<br> <b>Subject:</b> Re: [tsvwg] Redundant aggregate reservations: draft-ietf-ts= vwg-rsvp-pcn-03<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Hello Bob, Georgios, <o:p></o:p></p> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">From a scan of the thread and an off-line discussion= with Georgios, my perception of the situation is:<o:p></o:p></p> </div> <div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">* PCN edges need to maintain logical aggregate const= ructs (i.e. ingress-egrees PCN state) and map e2e reservations to these agg= regate constructs<o:p></o:p></p> </div> <div> <div> <p class=3D"MsoNormal">* we need to convey aggregate PCN info from edge to = edge<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">* no actual reservation state is needed inside the P= CN Core<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">This could be achieved by:<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">(A):<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">* adapting RFC 4860 aggregation procedures to fit PC= N with as little change as possible over RFC4860<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">* hence performing aggregate RSVP signaling (even if= it is to be ignored by PCN interior nodes)<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">* using this aggregate RSVP signaling to convey PCN = info edge to edge<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">OR<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">(B):<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">* adapting RFC 4860 aggregation procedures to fit PC= N with more significant changes over RFC4860 (i.e. you keep the aspect of t= he procedures that have to do with maintaining aggregate states and to do w= ith mapping e2e to aggregates, but you drop procedures that have too do with aggregate RSVP signaling and agg= regate reservation establishment/maintenance)<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">* hence not performing aggregate RSVP signaling<o:p>= </o:p></p> </div> <div> <p class=3D"MsoNormal">* piggy-backing PCN info inside e2e RSVP signaling.<= o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">I think both approaches are probably viable. I tend = to think the difference between the two is actually not that big at the end= of the day because the key of the logic is how you maintain aggregate stat= es at the edge and how you map 2e2 RSVP to these aggregates (i.e. the concept of aggregation within RFC4860 -= independently of the notion of aggregate RSVP signaling) and I don't think= the ingress-egress signaling channel (i.e. aggregate RSVP or e2e RSVP) is = so significant given the PCN specifics. <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">I think the drawbacks you pointed out, Bob, in your = initial message are probably not as serious as you suggested, given aggrega= te RSVP signaling would be ignored by interior nodes (for example, I don't = see why aggregate RSVP signaling would impact rerouting inside the PCN core since packets from individual session= s would be routed independently of the reservation. As another example you = mentioned that it might double the signaling processing load on edges while= i suspect it would only increase by some fraction given the level of aggregate signaling should be much low= er than collective e2e signaling). Nevertheless, If an approach along the l= ines of (B) removes the drawbacks completely while behaving as well, then t= hat may be a better approach.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">An attractive properly of (A) is that RFC4860 operat= ions has been thought through and there has been some implementation of RSV= P Aggregation, so we have some confidence that the solution can deal with t= he more challenging situations (rerouting in core, failure of an ingress edge, failure of an egress edge, rerouting = towards a different edge,…).<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">My suggestion would be to try identify if a (B)-type= approach can be devised with comparable properties in dealing with basic a= s well as more challenging situations, or conversely if the (A)-type approa= ch really has some superior behavior afforded by the extra ingress-egress dedicated signaling channel. That sho= uld be a key deciding factor.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">Perhaps Georgios could look into this direction?<o:p= ></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">I hope that helps<o:p></o:p></p> </div> </div> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">Francois<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">Caveat: I am operating based on slowly-but-surely fa= inting intimacy with PCN and RSVP aggregation technologies<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <div> <p class=3D"MsoNormal">On 20 Nov 2012, at 22:29, Bob Briscoe wrote:<o:p></o= :p></p> </div> <p class=3D"MsoNormal"><br> <br> <o:p></o:p></p> <div> <p class=3D"MsoNormal">Georgios,<br> <br> See other email. Pls focus on the specifics (you will need to go back to my= original email in the thread, because the specifics were immediately cut f= rom the thread when Tom understood them).<br> <br> The IETF can choose to continue along a path that it originally agreed, whe= ther right or wrong, but it is important to discuss whether it is right or = wrong first.<br> <br> <br> Bob<br> <br> At 10:29 17/11/2012, <a href=3D"mailto:karagian@cs.utwente.nl">karagian@cs.= utwente.nl</a> wrote:<br> <br> <br> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi Bob,<br> <br>  <br> <br> So, what you actually proposing is to discard a specification that has been= accepted by both PCN and tsvwg WGs to be considered as a WG specification = and to use a specification that you are proposing and that is conceptually = and architecturally wrong.<br> <br>  <br> <br> The solution that you are proposing, i.e., use of the e2e RSVP (RFC2205), i= s in my opinion architecturally and conceptually wrong!<br> <br> The reason is the following!<br> <br>  <br> <br> In PCN we need a signaling protocol that is able to: (1) to carry informati= on from PCN-egress-edge to PCN-ingress-edge and (2) the carried information= needs to be related to an aggregated state, i.e., the ingress-egress-aggre= gate state.<br> <br> The e2e RSVP (RFC2205) can only support requirement (1), but is not able to= support (2), since the e2e RSVP carries information that is associated wit= h a per flow state maintained at the edges.<br> <br> Aggregated RSVP (RFC3175) and Generic Aggregated RSVP (RFC4860) can support= both requirements, since one of the features that are supported by both is= to carry objects that are associated to an aggregated state maintained at = the edges. In the context of PCN, the aggregated state is the ingress egress aggregate state.<br> <br>  <br> <br> Best regards,<br> <br> Georgios<o:p></o:p></p> <div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"> <hr size=3D"2" width=3D"100%" align=3D"center"> </div> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">Van:</span></b><span style=3D"font-si= ze:10.0pt;font-family:"Tahoma","sans-serif""> Bob Brisc= oe [<a href=3D"mailto:bob.briscoe@bt.com">bob.briscoe@bt.com</a>]<br> <b>Verzonden:</b> vrijdag 16 november 2012 21:14<br> <b>To:</b> Karagiannis, G. (EWI)<br> <b>Cc:</b> <a href=3D"mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>; = <a href=3D"mailto:tsvwg@ietf.org"> tsvwg@ietf.org</a>; <a href=3D"mailto:philip.eardley@bt.com">philip.eardley= @bt.com</a>; <a href=3D"mailto:pcn@ietf.org">pcn@ietf.org</a>; <a href=3D"mailto:rsvp-di= r@ietfa.amsl.com"> rsvp-dir@ietfa.amsl.com</a>; <a href=3D"mailto:sob@harvard.edu">sob@harvard= .edu</a>; <a href=3D"mailto:slblake@petri-meat.com">slblake@petri-meat.com</a>; <a hr= ef=3D"mailto:gorry@erg.abdn.ac.uk"> gorry@erg.abdn.ac.uk</a>; <a href=3D"mailto:jmpolk@cisco.com">jmpolk@cisco.= com</a>; <a href=3D"mailto:anuragb@cisco.com">anuragb@cisco.com</a><br> <b>Onderwerp:</b> RE: Redundant aggregate reservations: draft-ietf-tsvwg-rs= vp-pcn-03<br> </span><br> Georgios,<br> <br> Yes, I apologise for not reviewing earlier. I appreciate you followed the p= rocedure.<br> <br> My problem was that a quick read of tsvwg-rsvp-pcn wasn't enough to underst= and it. So I stayed quiet even though I wasn't so happy about the direction= , because I didn't have enough understanding to feel I could argue.<br> <br> Only in the last week or so, I collected together all the references and re= -read them and their references, and made a concerted effort to understand = what your draft was proposing. I have to say, it was quite a struggle (over= a few days and the write-up took 2 days). <br> <br> However, I admit that it would have been preferable for everyone if I had m= ade this effort earlier.<br> <br> <br> Bob<br> <br> At 13:02 16/11/2012, <a href=3D"mailto:karagian@cs.utwente.nl">karagian@cs.= utwente.nl</a> wrote:<br> <br> <br> <o:p></o:p></p> <p class=3D"MsoNormal">Hi Bob,<br> <br> $B!!(B<br> <br> Thanks for your comments!<br> <br> Regarding your statement: What I meant in my previous email is that our ind= ividual draft that was used as a working basis for this WG draft  was = already using the generic aggregation RSVP (RFC 4860) as the existing signa= ling protocol, see:<br> <br>  <br> <br> <a href=3D"http://tools.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01= .txt">http://tools.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt<= /a> <br> <br>  <br> <br> Moreover, during IETF 81, this individual draft has been presneted, where a= lso the rationale of using (RFC 4860) was also the following slides see pre= sentation slides (slide 5):<br> <br>  <br> <br> <a href=3D"http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf">http://ww= w.ietf.org/proceedings/81/slides/tsvwg-0.pdf</a><br> <br> $B!!(B<br> <br> In particular in slide 4 mentions:<br> <br> "All PCN charter items are fulfilled, except:<br> <br> Submit Encoding and Transport of PCN from Domain Egress to Ingress to the I= ESG for consideration as a Proposed Standard RFC<br> <br> Pairs of PCN edge nodes use ingress-egress-aggregates (IEA):<br> <br> Need a signaling protocol to transport PCN information from PCN-egress-node= to PCN-ingress-node and to maintain ingress-egress-aggregate between each = pair of PCN edge nodes"<br> <br> Furthermore Slide 5 mentions:<br> <br> $B!!(B<br> <br> "IETF QoS signaling protocols to solve problem:<br> <br> Next Steps in Signaling Protocol (NSIS) subset (RFC 5971, RFC 5974, RFC 597= 9)<br> <br> Aggregation of RSVP for IPv4 and IPv6 Reservations (RFC3175)<br> <br> Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations (RFC486= 0)<br> <br> All can be used, but for time being selected RFC 4860 due:<br> <br> possible deployment interest<br> <br> supports RFC 3175 and additional features such as: <br> <br> support of multiple IEAs from same pair of PCN edge nodes <br> <br> support of bandwidth reduction for individual flows (RFC 4495)"<br> <br> $B!!(B<br> <br> Before IETF 81 and during IETF 81 this point has been discussed.<br> <br> The outcome of these discussions is that short after IETF 81, the individua= l draft (draft-karagiannis-pcn-tsvwg-rsvp-pcn-01) <br> <br> become (after small modifications) the draft-ietf-tsvwg-rsvp-pcn-00, which = also was using RFC 4860 as the base signaling protocol.<br> <br> $B!!(B<br> <br> It will be very helpful if the PCN WG chairs (Scott and/or Steve) and the t= svwg WG chairs (Gorry and/or James) could confirm the above statement!<br> <br> $B!!(B<br> <br> So both the PCN WG and tsvwg WG agreed that this specifictaion should use a= s basis the generic RSVP aggregation protocol!<br> <br> $B!!(B<br> <br> $B!!(B<br> <br> $B!!(B<br> <br> In a subsequent email and on a later moment I will also answer to your furt= her remarks!<br> <br> $B!!(B<br> <br> Best regards,<br> <br> Georgios<o:p></o:p></p> <div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"> <hr size=3D"2" width=3D"100%" align=3D"center"> </div> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">Van:</span></b><span style=3D"font-si= ze:10.0pt;font-family:"Tahoma","sans-serif""> Bob Brisc= oe [<a href=3D"mailto:bob.briscoe@bt.com">bob.briscoe@bt.com</a>]<br> <b>Verzonden:</b> donderdag 15 november 2012 14:07<br> <b>To:</b> Karagiannis, G. (EWI); <a href=3D"mailto:anuragb@cisco.com">anur= agb@cisco.com</a><br> <b>Cc:</b> <a href=3D"mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>; = <a href=3D"mailto:anuragb@cisco.com"> anuragb@cisco.com</a>; <a href=3D"mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>= ; <a href=3D"mailto:philip.eardley@bt.com"> philip.eardley@bt.com</a>; PCN IETF list; <a href=3D"mailto:rsvp-dir@ietfa.= amsl.com"> rsvp-dir@ietfa.amsl.com</a><br> <b>Onderwerp:</b> Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-p= cn-03<br> </span><br> Georgios, Anurag,<br> <br> Below is the main point of my review, arguing that aggregate reservations a= re redundant. I'm reviewing as:<br> - a member of the RSVP directorate<br> - one of the early PCN design team<br> - a co-author of draft-lefaucheur-rsvp-ecn-01, on which this draft is based= .<br> <br> I would have missed any decision to use aggregate reservations. Pls point m= e to the relevant discussion (e.g. Subject line / date).<br> <br> I admit I tuned out of much of the later PCN signalling discussion. I found= the whole exercise of abstracting PCN away from specific signalling protoc= ols highly tedious; it meant we couldn't sensibly address important issues = like message reliability, timeliness etc. <br> <br> Nonetheless, here's why I believe RSVP aggregation is redundant:<br> <br> PCN edge-nodes support the concept of an ingress-egress aggregate in their = own internal tables, but they don't need to refer to an aggregate on the wi= re{Note 1}. PCN-ingress and PCN-egress nodes intrinscially know which e2e r= eservations belong to which aggregate by grouping together those e2e reservations with the same next hop or prev= ious hop respectively.<br> <br> {Note 1: except in one case described later - but it doesn't require all th= e other baggage of aggregate reservations}<br> <br> =3D=3DBackground=3D=3D<br> Aggregate reservations [RFC3175, RFC4860] are designed to reduce the state = required on interior nodes. Interior nodes still require state per aggregat= e reservation, but only reservation state, not classification and schedulin= g state [RFC3175, Section 1.4.1 last para].<br> <br> In contrast, as you correctly point out (in Section 2.1.7), PCN requires ab= solutely no reservation-related state on interior nodes.<br> <br> =3D=3DDisadvantages=3D=3D<br> Requiring PCN to use aggregate reservations has the following three disadva= ntages and no advantages:<br> <br> 1) Redundant Processing<br> The PATH message between aggregator and deaggregator in rsvp-pcn-03 (trigge= red by an E2E PathErr message from deaggregator to aggregator) is redundant= , and just doubles the processing required at the PCN-edge-nodes (if this i= sn't obvious, I spell it out separately for PATH & RESV messages below). <br> <br> 2) Reduced Resilience<br> Not only is an aggregate PATH redundant, it actually reduces resilience. Be= cause an aggregate PATH is pinned to interior routers. Therefore, when rout= ing changes, it is more complex and slower to move to the new route. By not= pinning to interior routers, PCN was designed to 'just work' over interior routing changes - with no need f= or any changes to the RSVP PATHs. (But it would still detect overload after= a re-route and terminate or rate-reduce flows if necessary.)<br> <br> 3) Extra Latency<br> A further disadvantage is the extra latency required for the first reservat= ion that sets up an aggregate. This is two ingress-egress round trips minus= the round trip time from egress to destination (or one ingress-egress roun= d trip if it is greater). This will rarely add to latency on heavily used ingress-egress aggregates, but it wi= ll occur frequently on all the 'long-tail' (lightly used) ingress-egress ag= gregates.<br> <br> =3D=3DPATH=3D=3D<br> <br> With RFC 3175 or 4860 aggregate paths, the aggregator forwards the e2e PATH= messages with IP protocol number RSVP-E2E-IGNORE and the deaggregator chan= ges them back to RSVP before forwarding onward. Also the aggregator sends a= n aggregate PATH message, which is processed by each interior node and by the deaggregator.<br> <br> On a path across a PCN region, given interior nodes ignore aggregate PATH m= essages as well, the only PCN nodes that handle aggregate messages are the = aggregator and the deaggregator. The aggregator and deaggregator process al= l the e2e PATH messages anyway, so if we require the aggregator to add up all the e2e PATH messages and fo= rm them into an aggregate PATH message, this is just extra redundant work f= or both PCN-edge-nodes.<br> <br> =3D=3DRESV=3D=3D<br> <br> The deaggregator unicasts e2e RESV messages to the previous RSVP hop, which= is the aggregator. Therefore, if we require the deaggregator to add up all= the RESV messages and form them into an aggregate RESV message, this is ju= st redundant work for both PCN-edge-nodes, because they both already process all the e2e RESV messages anyway, and no= other node uses the aggregate RESV messages.<br> <br> =3D=3DPCN object=3D=3D<br> <br> This raises the question of how the PCN-egress communicates the various mar= king rates (the PCN object) to the PCN-ingress. There are two possibilities= :<br> i) the PCN-egress includes a current PCN object in each e2e RESV that it re= turns to the PCN-ingress. The PCN-ingress strips the PCN object out before = forwarding the RESV back to the previous RSVP hop.<br> ii) the PCN-egress attaches a PCN object to an aggregate reservation, as in= pcn-rsvp-03.<br> <br> Either are possible, because a PCN object carries information about marking= probabilities, and PCN works on the assumption that the marking probabilit= y of an ingress-egress aggregate is the same as the marking probability of = the flows within the aggregate. A PCN object can be contained either in an e2e RESV or an aggregate RESV a= s long as the PCN-ingress can associate an e2e RESV with the correct aggreg= ate (which it can, because it maintains an internal table of mappings betwe= en e2e reservations and their aggregates).<br> <br> Which of the two is best is a question of message timing...<br> <br> * For e2e admission decisions, the PCN object is only needed at the time ea= ch e2e RESV is sent, so option i) makes sense.<br> <br> * For flow rate reduction or flow termination decisions, the deaggregator n= eeds to regularly send PCN objects to the ingress. <br> <br> The PCN-egress is sending regular e2e RESV refresh messages to the PCN-ingr= ess, so a PCN object can be included in each of these. To ensure that PCN o= bjects are sent often enough, I suggest the PCN-egress also maintains a tim= er per ingress-egress aggregate which it resets every time it sends a PCN object for that IEA. If the time= r expires, the PCN-egress sends a PCN object to the PCN-egress even thought= it was not triggered by an e2e RESV refresh. We could require the SESSION = object in this message to refer to either of:<br> a) any one of the e2e SESSIONs in the aggregate, <br> b) the aggregate.<br> <br> In case (a), the message would need to somehow tell the ingress not to forw= ard this RESV refresh to the RSVP previous hop.<br> <br> In case (b) in the PCN-ingress table of mappings between e2e SESSIONs and a= ggregate SESSIONs, it would include an entry for the aggregate that maps to= itself. If the result of the look-up is the same as the input, it knows no= t to forward the RESV refresh further. <br> <br> The wire protocol doesn't need to identify whether the SESSION is an aggreg= ate or not. This is the one case I mentioned at the start {Note 1} where an= aggregate is referred to on the wire.<br> <br> <br> <br> In summary, PCN already reduces reservation state and processing to nothing= on interior nodes. Adding aggregate reservations to PCN requires more proc= essing and state, it unnecessarily pins routes to interior nodes and adds u= nnecessary latency.<br> <br> <br> Bob<br> <br> At 18:23 14/11/2012, <a href=3D"mailto:karagian@cs.utwente.nl">karagian@cs.= utwente.nl</a> wrote:<br> <br> <o:p></o:p></p> <p class=3D"MsoNormal">Hi Bob,<br>  <br> Regarding the generic aggregated RSVP selection, actually the PCN WG agreed= with this selection!<br> This was actually the first step that was needed for this work, and the PCN= WG had no main objections on this selection!<br>  <br> So I do not understand your remark that your comment will have major implic= ations!<br>  <br> Please note that the generic aggregated RSVP is selected since the PCN IEA = are associated with flows that are aggregated at the edges. So a signalling= protocol that supports aggregation of flows at the edges is very suitable = for this purpose! The generic aggregated RSVP is such a signalling protocol!<br>  <br>  <br> Best regards,<br> Georgios<br>  <br>  <br>  <br>  <br> <b>From:</b> Bob Briscoe [<a href=3D"mailto:bob.briscoe@bt.com">mailto:bob.= briscoe@bt.com</a>] <br> <b>Sent:</b> woensdag 14 november 2012 12:57<br> <b>To:</b> Anurag Bhargava (anuragb)<br> <b>Cc:</b> Karagiannis, G. (EWI)<br> <b>Subject:</b> Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br>  <br> Anurag,<br> <br> I have my comments half-written up. I will try to finish them by the end of= today.<br> <br> They should be orthogonal to the PBAC comment below, so if you wanted to st= art altering that area, I don't think it would waste too much time. <br> <br> However, my main comments will concern the use of aggregated reservations (= as I said at the mic), so that could have major implications.<br> <br> <br> Bob<br> <br> At 20:14 13/11/2012, Anurag Bhargava (anuragb) wrote:<br> <br> Hi Bob,<br>  Thanks for the comments. If U have some text that will be great els I= have also started putting some text on the topic U brought up.<br>  May be we can conference after US thanksgiving week and collaborate t= he text and try to move forward.<br> <br>  Please let us know what might be a good time and I can schedule a Web= ex conf.<br> <br> Thx<br> -Anurag<br> <br> From: "<a href=3D"mailto:karagian@cs.utwente.nl">karagian@cs.utwente.n= l</a> " <<a href=3D"mailto:karagian@cs.utwente.nl">karagian@cs.utwe= nte.nl</a> ><br> Date: Saturday, November 10, 2012 8:10 AM<br> To: "<a href=3D"mailto:bob.briscoe@bt.com">bob.briscoe@bt.com</a>"= ; <<a href=3D"mailto:bob.briscoe@bt.com">bob.briscoe@bt.com</a>><br> Cc: "<a href=3D"mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>&qu= ot; <<a href=3D"mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>>,= Anurag Bhargava <<a href=3D"mailto:anuragb@cisco.com">anuragb@cisco.com= </a>>, "<a href=3D"mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>" <<a href=3D"mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>>, "<a hre= f=3D"mailto:philip.eardley@bt.com">philip.eardley@bt.com</a> " <<a = href=3D"mailto:philip.eardley@bt.com">philip.eardley@bt.com</a> ><br> Subject: RE: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br> <br> Hi Bob,<br> <br>  <br> <br> Thanks very much for the comments! I think that they are very useful! <br> <br>  <br> <br> It will be very beneficiary for the fast progress of this draft if you woul= d like to contribute as a co-author to this draft and write this additional= section that describes "that the PCN-ingress can refer flow admission= and <br> termination decisions to a central decision point (using e.g. COPS), which = will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingr= ess could itself be the policy decision point.)"<br> <br>  <br> <br> Best regards,<br> <br> Georgios<br> <br>  <o:p></o:p></p> <div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"> <hr size=3D"2" width=3D"100%" align=3D"center"> </div> <p class=3D"MsoNormal"><b>Van:</b> Bob Briscoe [<a href=3D"mailto:bob.brisc= oe@bt.com">bob.briscoe@bt.com</a>]<br> <b>Verzonden:</b> vrijdag 9 november 2012 16:33<br> <b>To:</b> Karagiannis, G. (EWI)<br> <b>Cc:</b> <a href=3D"mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>; = <a href=3D"mailto:anuragb@cisco.com"> anuragb@cisco.com</a>; <a href=3D"mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>= ; EARDLEY, Phil<br> <b>Onderwerp:</b> Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br> <br> Georgios,<br> <br> I shall post my full review of this draft in the next few days (needs <br> typing up - currently scribbled on a paper copy). This email is <br> solely in response to your answer about on-path vs off-path policy.<br> <br> At 18:55 04/11/2012, <a href=3D"mailto:karagian@cs.utwente.nl">karagian@cs.= utwente.nl</a> wrote:<br> >So in this case an additional signaling protocol will be<br> >needed to be specified that covers the signaling between the <br> >PCN-egress-node and the centralized node<br> >and between PCN-ingress-node and the centralized node.<br> >In PCN we decdided to only focus on the specification of the <br> >signaling protocol that completes the<br> >feedback loop from PCN-egress-node to PCN-ingress-node and to focus <br= > >on the signaling protocol<br> >used between the edge nodes and the centralized node.<br> <br> When I/we originally designed CL-PCN over RSVP (2005), the idea was <br> that it would fit with the policy-based admission control (PBAC) <br> architecture of RFC2753. In this architecture, an Intserv node at the <br> ingress to a domain is the policy enforcement point (PEP), and it <br> refers to a logically centralised 'policy decision point' (PDP) for <br> decisions on which flows to block/terminate, typically using COPS.<br> <br> To make this doc fit the PBAC framework, all we have to do is:<br> * Describe the PCN-ingress only as the PCN-ingress and not as the <br> decision point (find 'decision' throughout doc and fix).<br> * Add a section saying the PCN-ingress can refer flow admission and <br> termination decisions to a central decision point (using e.g. COPS), <br> which will respond to the PCN-ingress as per RFC2753. (Alternatively <br> the PCN-ingress could itself be the policy decision point.)<br> * Refer to this new PBAC section from Section 3.11 giving the <br> admission decision procedure.<br> <br> * Some people might think this means COPS will need new protocol <br> elements to carry PCN marking rates to the policy decision point. But <br> PCN marking rates are irrelevant to the policy decision: the <br> PCN-ingress just uses PCN to determine whether it needs to block or <br> terminate, and it refers to the policy decision point for which flows <br> to block/terminate.<br> <br> * Unfortunately, neither of the two PCN system descriptions [RFC6661, <br> RFC6662] describe a PBAC-based case. The architecture [RFC5559] <br> refers to the PBAC framework [RFC2753] but unfortunately doesn't <br> spell out how it fits. Originally, I referenced PBAC from RFC5559, <br> but just as the PCN w-g was closing I realised that (some?) others in <br> the PCN w-g were working under the assumption that the only way to <br> talk to a centralised policy node was from the egress, possibly <br> without being aware of the contents of RFC2753.<br> <br> I think it's OK to introduce a new architectural arrangement in this <br> RSVP doc, given RFC2753 is specific to the way RSVP works.<br> <br> <br> Bob<br> <br> <br> <br> At 12:28 05/11/2012, <a href=3D"mailto:karagian@cs.utwente.nl">karagian@cs.= utwente.nl</a> wrote:<br> >Hi Ken,<br> ><br> >Thank you very much!<br> >We will try to catch Francois and discuss the last (in line) issue with= him!<br> ><br> >Best regards,<br> >Georgios<br> ><br> >________________________________________<br> >Van: ken carlberg [<a href=3D"mailto:carlberg@g11.org.uk">carlberg@g11.= org.uk</a>]<br> >Verzonden: maandag 5 november 2012 13:23<br> >To: Karagiannis, G. (EWI)<br> >Cc: <a href=3D"mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>; <a href=3D"ma= ilto:anuragb@cisco.com"> anuragb@cisco.com</a><br> >Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03<br> ><br> >Georgios,<br> ><br> > > Georgios: We will try to explain the rationale of why we consider= <br> > that RSVP can only be used for the situation that the<br> > > decision point is collocated with the PCN-ingress-node. The main = <br> > reason of this is that in the case that the<br> > > decision point is collocated with the PCN-ingress-node,the <br> > required signaling protocol used to complete a<br> > > feedback loop from egress to ingress can be an entirely on-path <= br> > protocol, like what RSVP is.<br> > > In the situation that the the decision point is a centralized <br= > > node, then the required signaling protocol<br> > > can be a combination of an on-path and off-path protocol. This is= <br> > because the<br> > > decision point might not be located on the data path! So in this = <br> > case an additional signaling protocol will be<br> > > needed to be specified that covers the signaling between the <br> > PCN-egress-node and the centralized node<br> > > and between PCN-ingress-node and the centralized node.<br> > > In PCN we decdided to only focus on the specification of the <br> > signaling protocol that completes the<br> > > feedback loop from PCN-egress-node to PCN-ingress-node and to <br= > > focus on the signaling protocol<br> > > used between the edge nodes and the centralized node.<br> > > This is also the reason of why PCN WG decided to only focus on <b= r> > the situation that the decision point is<br> > > collocated with the PCN-ingress-node.<br> ><br> >Great, this is helpful, and this is the information that needs to be <b= r> >in the draft.<br> ><br> > >> 6) This comment is just for you to contemplate -- I'm not <br= > > expecting any changes.<br> > >> I noticed that you have a fair number of SHOULD, and some SHO= ULD NOTs.<br> > >> And it seems a lot of this is a carry over from rfc-4860, so = in <br> > a sense you are inheriting an approach that<br> > >> was agreed to from an earlier effort.  But I wonder in t= he back <br> > of my mind, what impact occurs if<br> > >> an implementor doesn't follow the SHOULD?  Does the desi= gn break <br> > in supporting PCN?<br> > >> Again, I want to stress that this isnt a show stopper, but I = <br> > would appreciate it if you gave it some thought.<br> > ><br> > > Georgios: Yes, in several cases the design might break in support= ing PCN.<br> > > This is also the reason of using SHOULD instead of MAY. Do you <b= r> > want us to explain this in more detail in the draft?<br> ><br> >well, actually, I was more curious as to why a number of these cases <b= r> >are SHOULD instead of MUST.  Again, the SHOULD's in your document = <br> >seem to be a carry-over from rfc-4860 (which set the precedent), so <br= > >its a bit unfair for you to explain what was done in an earlier <br> >effort.  I just wanted to make sure you gave some thought to the <= br> >subject.  And if things will break if SHOULD is not followed by an= <br> >implementer/configuration, then maybe you should be more stringent <br> >and change things to MUST.  Perhaps a brief private conversation <= br> >with Francois Le Faucheur will be helpful.<br> ><br> >cheers,<br> ><br> >-ken<br> <br> ________________________________________________________________<br> Bob Briscoe,          &nb= sp;            =          BT Innovate & Design <= br> <br> ________________________________________________________________<br> Bob Briscoe,          &nb= sp;            =          BT Innovate & Design<o= :p></o:p></p> <p class=3D"MsoNormal"><br> ________________________________________________________________<br> Bob Briscoe,          &nb= sp;            =          BT Innovate & Design <= o:p></o:p></p> <p class=3D"MsoNormal"><br> ________________________________________________________________<br> Bob Briscoe,          &nb= sp;            =          BT Innovate & Design <= o:p></o:p></p> <p>________________________________________________________________<br> Bob Briscoe,          &nb= sp;            =          BT Innovate & Design<o= :p></o:p></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </div> </div> </body> </html> --_000_FF1A9612A94D5C4A81ED7DE1039AB80F2ED90D42EXMBX04adutwent_-- From david.black@emc.com Sat Nov 24 14:35:06 2012 Return-Path: <david.black@emc.com> 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 B53D121F8505 for <tsvwg@ietfa.amsl.com>; Sat, 24 Nov 2012 14:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKFOiNEg8+Zu for <tsvwg@ietfa.amsl.com>; Sat, 24 Nov 2012 14:35:05 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id B300421F8503 for <tsvwg@ietf.org>; Sat, 24 Nov 2012 14:35:04 -0800 (PST) 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 qAOMZ3r0016207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tsvwg@ietf.org>; Sat, 24 Nov 2012 17:35:03 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for <tsvwg@ietf.org>; Sat, 24 Nov 2012 17:34:50 -0500 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qAOMYopt029223 for <tsvwg@ietf.org>; Sat, 24 Nov 2012 17:34:50 -0500 Received: from mx15a.corp.emc.com ([169.254.1.120]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Sat, 24 Nov 2012 17:34:49 -0500 From: "Black, David" <david.black@emc.com> To: "tsvwg@ietf.org" <tsvwg@ietf.org> Date: Sat, 24 Nov 2012 17:34:48 -0500 Thread-Topic: Diffserv classes (rfc4594bis): Check on Atlanta "hum" Thread-Index: Ac3Kk+lc4r+wsGOrTG27ykn3TJxxqw== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71284D3FF1A@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] Diffserv classes (rfc4594bis): Check on Atlanta "hum" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 24 Nov 2012 22:35:06 -0000 Hello - this is your new tsvwg co-chair, with <co-chair hat on>. The Atlanta tsvwg minutes are at: http://www.ietf.org/proceedings/85/minutes/minutes-85-tsvwg Many thanks to Ken and Mirja for being the note-takers. I have two action items from the Thursday diffserv-oriented meeting - this message is about the first, the possible update to the Diffserv Classes RFC (RFC 4594). Excerpt from the minutes (slightly edited/corrected): --------------- - (David Black) there is a suggestion that multi-media conferencing was not properly supported when Diffserv Classes were first defined. So, what does the room think about this? Audience "hum" thinks James Polk is correct and that a new more granular class is needed. Particularly, RFCs 4594 and 5127 need some work. Black states that we need to put this on the list and discuss how many more things we need to fix. --------------- Restating - the sense of the room in Atlanta was that interactive media (e.g., multi-media conferencing) needs to be broken out of the existing diffserv media classes into at least one new class. If anyone disagrees with that sense of the room in Atlanta, please speak up now (please review the appropriate portion of the Atlanta minutes first). Caveat: this topic and email are entirely about Diffserv Classes, i.e., revising RFC 4594. If RFC 4594 is revised, RFC 5127 on diffserv class aggregation will need a corresponding update to fit the new classes into its aggregates. This email is *not* about the discussion=20 of diffserv usage for interconnection (e.g., the ITU-T SG12 liaison). That interconnection topic may or may not involve a revision to RFC 5127 (e.g., it could be done in an entirely new document) and will be covered in a separate email thread; please wait for it. If the sense of the room in Atlanta is confirmed, the next steps on Diffserv Classes are that I will work with James to come up with a list of all the things that he's proposing to change in draft-polk-tsvwg-rfc4594-update and ask the list whether each one of them needs attention (single subject/question emails). In particular, this is *not* a call for whether tsvwg should adopt draft-polk-tsvwg-rfc4594-update - the initial steps are to figure out the scope of work that should be done. 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 Sat Nov 24 14:51:39 2012 Return-Path: <david.black@emc.com> 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 BB20E21F84BB for <tsvwg@ietfa.amsl.com>; Sat, 24 Nov 2012 14:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aScljcBU6QOs for <tsvwg@ietfa.amsl.com>; Sat, 24 Nov 2012 14:51:39 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD0C21F84B9 for <tsvwg@ietf.org>; Sat, 24 Nov 2012 14:51:37 -0800 (PST) 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 qAOMpa0Y012216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tsvwg@ietf.org>; Sat, 24 Nov 2012 17:51:36 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for <tsvwg@ietf.org>; Sat, 24 Nov 2012 17:51:20 -0500 Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qAOMpKDc014285 for <tsvwg@ietf.org>; Sat, 24 Nov 2012 17:51:20 -0500 Received: from mx15a.corp.emc.com ([169.254.1.120]) by mxhub04.corp.emc.com ([10.254.141.106]) with mapi; Sat, 24 Nov 2012 17:51:19 -0500 From: "Black, David" <david.black@emc.com> To: "tsvwg@ietf.org" <tsvwg@ietf.org> Date: Sat, 24 Nov 2012 17:51:19 -0500 Thread-Topic: Diffserv for interconnection Thread-Index: Ac3KljebdjQRdxroSiOKNiDbMqMC/A== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71284D3FF1B@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] Diffserv for interconnection X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 24 Nov 2012 22:51:39 -0000 Hello - this is your new tsvwg co-chair again, with <co-chair hat on>. The Atlanta tsvwg minutes are at: http://www.ietf.org/proceedings/85/minutes/minutes-85-tsvwg This message is about my second action item, on use of Diffserv for network interconnection. Excerpt from the minutes (explanation below): --------------- Topic: interconnect liaison with ITU-T - (James Polk) describing set of code points (?) for the interconnection of core providers. =20 - (Gorry Fairhurst) asks if we should make a new set of recommendations for a particular interface.=20 - (David Black) thinks we should. As Chair, he asks the room if we should work on this? The room (by show of hands) indicates yes. So we'll put this on the list (Joel Halpern) thinks we don't need to do anymore at this meeting. We should state "this is an interesting problem, and we should do something about this" --------------- So the immediate question is what was "this" in Joel's comment? The short answer is that it's slide 6 in this set of slides: http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-8.pdf The rationale for doing "this" is also on that slide - it's basically scaling/reuse of configuration, so that a carrier or operator can apply a single diffserv configuration to interconnections with multiple other networks. Also see draft-geib-tsvwg-diffserv-intercon-00 . The item that I recall asking about was whether the IETF should work on a single set of recommended diffserv behavior (PHBs) and codepoints (DSCPs) for use in carrier interconnection? The sense of the room in Atlanta (as noted in the minutes) was that the IETF should work on this, with details of how to do that TBD - in particular there was no assumption about the relationship of this work to RFC 5127 on aggregation of Diffserv Classes (e.g., if undertaken, this new work may or may not be carried out by revising RFC 5127). If anyone disagrees with the sense of the room in Atlanta, now would be a good time to speak up. If the sense of the room in Atlanta is confirmed, the next action is for me to work through the ITU-T SG12 liaison (primarily the draft of y.qosmap) and consult with Ruediger about what makes sense before bringing a proposal for what to do back to this list. 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 Ruediger.Geib@telekom.de Mon Nov 26 00:30:18 2012 Return-Path: <Ruediger.Geib@telekom.de> 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 63A3721F8532 for <tsvwg@ietfa.amsl.com>; Mon, 26 Nov 2012 00:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mm-v8ZocABRg for <tsvwg@ietfa.amsl.com>; Mon, 26 Nov 2012 00:30:17 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 59ECC21F8531 for <tsvwg@ietf.org>; Mon, 26 Nov 2012 00:30:17 -0800 (PST) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 26 Nov 2012 09:30:02 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Mon, 26 Nov 2012 09:30:02 +0100 From: <Ruediger.Geib@telekom.de> To: <david.black@emc.com> Date: Mon, 26 Nov 2012 09:30:00 +0100 Thread-Topic: Diffserv for interconnection Thread-Index: Ac3KljebdjQRdxroSiOKNiDbMqMC/ABF5BIQ Message-ID: <CA7A7C64CC4ADB458B74477EA99DF6F5A2873C30@HE111643.EMEA1.CDS.T-INTERNAL.COM> References: <8D3D17ACE214DC429325B2B98F3AE71284D3FF1B@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71284D3FF1B@MX15A.corp.emc.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: pierre.levis@orange.com, tsvwg@ietf.org, christian.jacquenet@orange.com Subject: Re: [tsvwg] Diffserv for interconnection X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 26 Nov 2012 08:30:18 -0000 David, thanks. I submitted a draft on the issue and I'm also involved in the ITU l= iaision. Yes, to me IETF should pick up the subject of limited and "well enough defi= ned" set of interconnection QoS classes. I've reread RFC5127. If it stays informational, I got no qualms with it. If= a revised version of RFC5127 ist to be put on standards track, some parts of it must = be better explained and possibly rewritten. If it is not touched, some parts o= f what is required in a revised 5127 from my point of view should become part of t= he interconnection work. I'm halfway through http://tools.ietf.org/html/rfc5160 and the authors aske= d how I'd position my proposal with regard it. It is a more abstract document about inter provider QoS agreements. So far I think, RFC5160 and the proposals of= my draft would complement each other. Regards, R=FCdiger -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of B= lack, David Sent: Saturday, November 24, 2012 11:51 PM To: tsvwg@ietf.org Subject: [tsvwg] Diffserv for interconnection Hello - this is your new tsvwg co-chair again, with <co-chair hat on>. The Atlanta tsvwg minutes are at: http://www.ietf.org/proceedings/85/minutes/minutes-85-tsvwg This message is about my second action item, on use of Diffserv for network interconnection. Excerpt from the minutes (explanation below): --------------- Topic: interconnect liaison with ITU-T - (James Polk) describing set of code points (?) for the interconnection of core providers. - (Gorry Fairhurst) asks if we should make a new set of recommendations for a particular interface. - (David Black) thinks we should. As Chair, he asks the room if we should work on this? The room (by show of hands) indicates yes. So we'll put this on the list (Joel Halpern) thinks we don't need to do anymore at this meeting. We should state "this is an interesting problem, and we should do something about this" --------------- So the immediate question is what was "this" in Joel's comment? The short answer is that it's slide 6 in this set of slides: http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-8.pdf The rationale for doing "this" is also on that slide - it's basically scaling/reuse of configuration, so that a carrier or operator can apply a single diffserv configuration to interconnections with multiple other networks. Also see draft-geib-tsvwg-diffserv-intercon-00 . The item that I recall asking about was whether the IETF should work on a single set of recommended diffserv behavior (PHBs) and codepoints (DSCPs) for use in carrier interconnection? The sense of the room in Atlanta (as noted in the minutes) was that the IETF should work on this, with details of how to do that TBD - in particular there was no assumption about the relationship of this work to RFC 5127 on aggregation of Diffserv Classes (e.g., if undertaken, this new work may or may not be carried out by revising RFC 5127). If anyone disagrees with the sense of the room in Atlanta, now would be a good time to speak up. If the sense of the room in Atlanta is confirmed, the next action is for me to work through the ITU-T SG12 liaison (primarily the draft of y.qosmap) and consult with Ruediger about what makes sense before bringing a proposal for what to do back to this list. 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 Ruediger.Geib@telekom.de Mon Nov 26 00:46:58 2012 Return-Path: <Ruediger.Geib@telekom.de> 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 B926E21F8551 for <tsvwg@ietfa.amsl.com>; Mon, 26 Nov 2012 00:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXW3GpUZwDFr for <tsvwg@ietfa.amsl.com>; Mon, 26 Nov 2012 00:46:58 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id D4D3821F8550 for <tsvwg@ietf.org>; Mon, 26 Nov 2012 00:46:57 -0800 (PST) Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 26 Nov 2012 09:46:55 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 26 Nov 2012 09:46:55 +0100 From: <Ruediger.Geib@telekom.de> To: <david.black@emc.com> Date: Mon, 26 Nov 2012 09:46:53 +0100 Thread-Topic: Diffserv classes (rfc4594bis): Check on Atlanta "hum" Thread-Index: Ac3Kk+lc4r+wsGOrTG27ykn3TJxxqwBHImFQ Message-ID: <CA7A7C64CC4ADB458B74477EA99DF6F5A2873C5F@HE111643.EMEA1.CDS.T-INTERNAL.COM> References: <8D3D17ACE214DC429325B2B98F3AE71284D3FF1A@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71284D3FF1A@MX15A.corp.emc.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: tsvwg@ietf.org Subject: Re: [tsvwg] Diffserv classes (rfc4594bis): Check on Atlanta "hum" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 26 Nov 2012 08:46:58 -0000 David, again thanks for a well formulated proposal. After a brief talk with my audio/video QoE experts I agree to differing telecoferencing (or whatever we call it) from streaming in DiffServ standards. I see a need to clarify aggregation of DiffServ classes, if a revised RFC5127 or a revised RFC4594 are put on standards track. I'm having issues with RFC5127. And a side one: terminology may be an issue - we all use "classes" in our exchanges and Brian correctly pointed out that it is not as well defined as major parts of the DiffServ terminology (which, I think, we however hardly use). Regards, R=FCdiger -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of B= lack, David Sent: Saturday, November 24, 2012 11:35 PM To: tsvwg@ietf.org Subject: [tsvwg] Diffserv classes (rfc4594bis): Check on Atlanta "hum" Hello - this is your new tsvwg co-chair, with <co-chair hat on>. The Atlanta tsvwg minutes are at: http://www.ietf.org/proceedings/85/minutes/minutes-85-tsvwg Many thanks to Ken and Mirja for being the note-takers. I have two action items from the Thursday diffserv-oriented meeting - this message is about the first, the possible update to the Diffserv Classes RFC (RFC 4594). Excerpt from the minutes (slightly edited/corrected): --------------- - (David Black) there is a suggestion that multi-media conferencing was not properly supported when Diffserv Classes were first defined. So, what does the room think about this? Audience "hum" thinks James Polk is correct and that a new more granular class is needed. Particularly, RFCs 4594 and 5127 need some work. Black states that we need to put this on the list and discuss how many more things we need to fix. --------------- Restating - the sense of the room in Atlanta was that interactive media (e.g., multi-media conferencing) needs to be broken out of the existing diffserv media classes into at least one new class. If anyone disagrees with that sense of the room in Atlanta, please speak up now (please review the appropriate portion of the Atlanta minutes first). Caveat: this topic and email are entirely about Diffserv Classes, i.e., revising RFC 4594. If RFC 4594 is revised, RFC 5127 on diffserv class aggregation will need a corresponding update to fit the new classes into its aggregates. This email is *not* about the discussion of diffserv usage for interconnection (e.g., the ITU-T SG12 liaison). That interconnection topic may or may not involve a revision to RFC 5127 (e.g., it could be done in an entirely new document) and will be covered in a separate email thread; please wait for it. If the sense of the room in Atlanta is confirmed, the next steps on Diffserv Classes are that I will work with James to come up with a list of all the things that he's proposing to change in draft-polk-tsvwg-rfc4594-update and ask the list whether each one of them needs attention (single subject/question emails). In particular, this is *not* a call for whether tsvwg should adopt draft-polk-tsvwg-rfc4594-update - the initial steps are to figure out the scope of work that should be done. 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 mohamed.boucadair@orange.com Mon Nov 26 02:22:54 2012 Return-Path: <mohamed.boucadair@orange.com> 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 0856A21F86B2 for <tsvwg@ietfa.amsl.com>; Mon, 26 Nov 2012 02:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9O1p9mnz23br for <tsvwg@ietfa.amsl.com>; Mon, 26 Nov 2012 02:22:53 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id DB5FE21F8668 for <tsvwg@ietf.org>; Mon, 26 Nov 2012 02:22:52 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 4A62926427E; Mon, 26 Nov 2012 11:22:51 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 0C7F54C07D; Mon, 26 Nov 2012 11:22:51 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Mon, 26 Nov 2012 11:22:49 +0100 From: <mohamed.boucadair@orange.com> To: "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>, "david.black@emc.com" <david.black@emc.com> Date: Mon, 26 Nov 2012 11:22:48 +0100 Thread-Topic: Diffserv for interconnection Thread-Index: Ac3KljebdjQRdxroSiOKNiDbMqMC/ABF5BIQAAKa+bA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E98722964@PUEXCB1B.nanterre.francetelecom.fr> References: <8D3D17ACE214DC429325B2B98F3AE71284D3FF1B@MX15A.corp.emc.com> <CA7A7C64CC4ADB458B74477EA99DF6F5A2873C30@HE111643.EMEA1.CDS.T-INTERNAL.COM> In-Reply-To: <CA7A7C64CC4ADB458B74477EA99DF6F5A2873C30@HE111643.EMEA1.CDS.T-INTERNAL.COM> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: LEVIS Pierre OLNC/OLPS <pierre.levis@orange.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, JACQUENET Christian OLNC/OLN <christian.jacquenet@orange.com> Subject: Re: [tsvwg] Diffserv for interconnection X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 26 Nov 2012 10:22:54 -0000 Dear Ruediger, Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] De=20 >la part de Ruediger.Geib@telekom.de >Envoy=E9 : lundi 26 novembre 2012 09:30 >=C0 : david.black@emc.com >Cc : LEVIS Pierre OLNC/OLPS; tsvwg@ietf.org; JACQUENET=20 >Christian OLNC/OLN >Objet : Re: [tsvwg] Diffserv for interconnection > >David, > >thanks. I submitted a draft on the issue and I'm also involved=20 >in the ITU liaision. > >Yes, to me IETF should pick up the subject of limited and=20 >"well enough defined" >set of interconnection QoS classes. > >I've reread RFC5127. If it stays informational, I got no=20 >qualms with it. If a revised >version of RFC5127 ist to be put on standards track, some=20 >parts of it must be >better explained and possibly rewritten. If it is not touched,=20 >some parts of what >is required in a revised 5127 from my point of view should=20 >become part of the >interconnection work. > >I'm halfway through http://tools.ietf.org/html/rfc5160 and the=20 >authors asked how I'd >position my proposal with regard it. It is a more abstract=20 >document about >inter provider QoS agreements.=20 Med: FWIW, the rationale we adopted in RFC5160 is as follows: * Network Providers are free to define their own traffic engineering polici= es and their QoS class of services in their domains. * Diffserv is only a means among other to achieve differentiated forwarding * The number and the definition of QoS classes is not universal * Network Providers are not obliged to expose their internal class of servi= ces to external parties * When extending some QoS classes beyond the boundaries of a given domain, = it is required to establish contractual agreements between network provider= s, otherwise the traffic will be handed as BE. * These agreements will be the place where class identification is discusse= d and agreed. * Remarking is likely to be always enforced in both exit border router and = entry border router: local class of services are not advertised outside the= domain. * Providers need a tool to help deciding how to bind one/multiple local QoS= classes with adjacent class of service: hence the concept of meta-QoS-Clas= s. * CoS identifier is not sufficient to provide QoS: additional parameters ar= e to be agreed between network providers. Examples of these parameters are:= constraints on the traffic (eg., tcp-friendly), network resources for the = class / overall traffic using this class, etc. So far I think, RFC5160 and the=20 >proposals of my >draft would complement each other. Med: Agreed. I personally see a value in standardizing a very limited set o= f interconnection classes. In addition to the interconnection class name/id= entifier discussion point, it is important also to have a detailed definiti= on of the class itself (in terms of attributes, target services, traffic co= nditions, etc.). Perhaps, try the http://tools.ietf.org/html/rfc3086#sectio= n-8 ;-)? > >Regards, > >R=FCdiger > > > >-----Original Message----- >From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org]=20 >On Behalf Of Black, David >Sent: Saturday, November 24, 2012 11:51 PM >To: tsvwg@ietf.org >Subject: [tsvwg] Diffserv for interconnection > >Hello - this is your new tsvwg co-chair again, with <co-chair hat on>. > >The Atlanta tsvwg minutes are at: > http://www.ietf.org/proceedings/85/minutes/minutes-85-tsvwg > >This message is about my second action item, on use of Diffserv for >network interconnection. > >Excerpt from the minutes (explanation below): >--------------- >Topic: interconnect liaison with ITU-T >- (James Polk) describing set of code points (?) for the=20 >interconnection > of core providers. >- (Gorry Fairhurst) asks if we should make a new set of=20 >recommendations for > a particular interface. >- (David Black) thinks we should. As Chair, he asks the room=20 >if we should > work on this? The room (by show of hands) indicates yes. > So we'll put this on the list >(Joel Halpern) thinks we don't need to do anymore at this meeting. We > should state "this is an interesting problem, and we should do > something about this" >--------------- > >So the immediate question is what was "this" in Joel's comment? > >The short answer is that it's slide 6 in this set of slides: > http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-8.pdf > >The rationale for doing "this" is also on that slide - it's basically >scaling/reuse of configuration, so that a carrier or operator can apply >a single diffserv configuration to interconnections with multiple other >networks. Also see draft-geib-tsvwg-diffserv-intercon-00 . > >The item that I recall asking about was whether the IETF=20 >should work on a >single set of recommended diffserv behavior (PHBs) and=20 >codepoints (DSCPs) >for use in carrier interconnection? > >The sense of the room in Atlanta (as noted in the minutes) was that the >IETF should work on this, with details of how to do that TBD - in >particular there was no assumption about the relationship of this work >to RFC 5127 on aggregation of Diffserv Classes (e.g., if undertaken, >this new work may or may not be carried out by revising RFC 5127). > >If anyone disagrees with the sense of the room in Atlanta, now would >be a good time to speak up. > >If the sense of the room in Atlanta is confirmed, the next action is >for me to work through the ITU-T SG12 liaison (primarily the draft of >y.qosmap) and consult with Ruediger about what makes sense before >bringing a proposal for what to do back to this list. > >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 david.black@emc.com Mon Nov 26 11:52:37 2012 Return-Path: <david.black@emc.com> 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 6BADB21F8527 for <tsvwg@ietfa.amsl.com>; Mon, 26 Nov 2012 11:52:37 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUHdRur8nB3n for <tsvwg@ietfa.amsl.com>; Mon, 26 Nov 2012 11:52:36 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 64B9621F846E for <tsvwg@ietf.org>; Mon, 26 Nov 2012 11:52:36 -0800 (PST) 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 qAQJqXKL001783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2012 14:52:34 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Mon, 26 Nov 2012 14:52:27 -0500 Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com [10.254.141.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qAQJqQLR031348; Mon, 26 Nov 2012 14:52:26 -0500 Received: from mx15a.corp.emc.com ([169.254.1.120]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Mon, 26 Nov 2012 14:52:26 -0500 From: "Black, David" <david.black@emc.com> To: "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de> Date: Mon, 26 Nov 2012 14:52:24 -0500 Thread-Topic: Diffserv for interconnection and RFC 5127 Thread-Index: Ac3KljebdjQRdxroSiOKNiDbMqMC/ABF5BIQABgLGzA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE71284D400F6@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71284D3FF1B@MX15A.corp.emc.com> <CA7A7C64CC4ADB458B74477EA99DF6F5A2873C30@HE111643.EMEA1.CDS.T-INTERNAL.COM> In-Reply-To: <CA7A7C64CC4ADB458B74477EA99DF6F5A2873C30@HE111643.EMEA1.CDS.T-INTERNAL.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 Cc: "pierre.levis@orange.com" <pierre.levis@orange.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "christian.jacquenet@orange.com" <christian.jacquenet@orange.com> Subject: [tsvwg] Diffserv for interconnection and RFC 5127 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 26 Nov 2012 19:52:37 -0000 Ruediger, <WG co-chair hat on> > thanks. I submitted a draft on the issue and I'm also involved in > the ITU liaision. >=20 > Yes, to me IETF should pick up the subject of limited and "well > enough defined" set of interconnection QoS classes. Thanks - this is a quick response to add clarity on RFC 5127: > I've reread RFC 5127. If it stays informational, I got no qualms > with it. If a revised version of RFC 5127 is to be put on standards > track, some parts of it must be better explained and possibly > rewritten. If it is not touched, some parts of what is required > in a revised 5127 from my point of view should become part of the > interconnection work. All three of the above options (revise RFC 5127 as Informational, revise RFC 5127 as Standards Track, write a new RFC that could be informational or standards track) are possibilities for this proposed Diffserv interconnection work. In addition, the proposed Diffserv Classes work involves both RFC 4594 and RFC 5127 (the aggregations in 5127 would need to be updated to reflect updates to the classes in 4594), but that coupling does not dictate how the Diffserv interconnection work should be done. In particular, a new RFC for Diffserv interconnection in addition to an update to RFC 5127 as part of the Diffserv Classes work is a possible approach. Thanks, --David > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Monday, November 26, 2012 3:30 AM > To: Black, David > Cc: tsvwg@ietf.org; pierre.levis@orange.com; christian.jacquenet@orange.c= om; > sebastien.jobert@orange.com; acmorton@att.com > Subject: RE: Diffserv for interconnection >=20 > David, >=20 > thanks. I submitted a draft on the issue and I'm also involved in the ITU= liaision. >=20 > Yes, to me IETF should pick up the subject of limited and "well enough de= fined" > set of interconnection QoS classes. >=20 > I've reread RFC5127. If it stays informational, I got no qualms with it. = If a revised > version of RFC5127 ist to be put on standards track, some parts of it mus= t be > better explained and possibly rewritten. If it is not touched, some parts= of what > is required in a revised 5127 from my point of view should become part of= the > interconnection work. >=20 > I'm halfway through http://tools.ietf.org/html/rfc5160 and the authors as= ked how I'd > position my proposal with regard it. It is a more abstract document about > inter provider QoS agreements. So far I think, RFC5160 and the proposals = of my > draft would complement each other. >=20 > Regards, >=20 > R=FCdiger >=20 >=20 >=20 > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > Black, David > Sent: Saturday, November 24, 2012 11:51 PM > To: tsvwg@ietf.org > Subject: [tsvwg] Diffserv for interconnection >=20 > Hello - this is your new tsvwg co-chair again, with <co-chair hat on>. >=20 > The Atlanta tsvwg minutes are at: > http://www.ietf.org/proceedings/85/minutes/minutes-85-tsvwg >=20 > This message is about my second action item, on use of Diffserv for > network interconnection. >=20 > Excerpt from the minutes (explanation below): > --------------- > Topic: interconnect liaison with ITU-T > - (James Polk) describing set of code points (?) for the interconnection > of core providers. > - (Gorry Fairhurst) asks if we should make a new set of recommendations f= or > a particular interface. > - (David Black) thinks we should. As Chair, he asks the room if we should > work on this? The room (by show of hands) indicates yes. > So we'll put this on the list > (Joel Halpern) thinks we don't need to do anymore at this meeting. We > should state "this is an interesting problem, and we should do > something about this" > --------------- >=20 > So the immediate question is what was "this" in Joel's comment? >=20 > The short answer is that it's slide 6 in this set of slides: > http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-8.pdf >=20 > The rationale for doing "this" is also on that slide - it's basically > scaling/reuse of configuration, so that a carrier or operator can apply > a single diffserv configuration to interconnections with multiple other > networks. Also see draft-geib-tsvwg-diffserv-intercon-00 . >=20 > The item that I recall asking about was whether the IETF should work on a > single set of recommended diffserv behavior (PHBs) and codepoints (DSCPs) > for use in carrier interconnection? >=20 > The sense of the room in Atlanta (as noted in the minutes) was that the > IETF should work on this, with details of how to do that TBD - in > particular there was no assumption about the relationship of this work > to RFC 5127 on aggregation of Diffserv Classes (e.g., if undertaken, > this new work may or may not be carried out by revising RFC 5127). >=20 > If anyone disagrees with the sense of the room in Atlanta, now would > be a good time to speak up. >=20 > If the sense of the room in Atlanta is confirmed, the next action is > for me to work through the ITU-T SG12 liaison (primarily the draft of > y.qosmap) and consult with Ruediger about what makes sense before > bringing a proposal for what to do back to this list. >=20 > 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 > ---------------------------------------------------- >=20 From sdhesika@cisco.com Tue Nov 27 16:27:52 2012 Return-Path: <sdhesika@cisco.com> 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 A61E121F85A2 for <tsvwg@ietfa.amsl.com>; Tue, 27 Nov 2012 16:27:52 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HljBvJq0ITQl for <tsvwg@ietfa.amsl.com>; Tue, 27 Nov 2012 16:27:52 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id EE68721F85A1 for <tsvwg@ietf.org>; Tue, 27 Nov 2012 16:27:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2164; q=dns/txt; s=iport; t=1354062472; x=1355272072; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=q7Tkor0frZjFSG1nhgEPtKC5avl49TKh4nvth8e1GdY=; b=J3d3rGxnJ4UrL0eGLRvj/UNdyHT9hSKYrVJq1kMQEnr90i+c6uoVXCNH Cfru3KgBkRXi/CFgYPL7S8ocBY6nBwTZapC8Lo28ylbcD3rUjJ/A7Lhvl ghOal9cip7be89EPwDlHyuAq5rVLHXEGGf7Tua9RvNLR9fTuk+/nwPSDo I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkMAAtZtVCtJXG9/2dsb2JhbABFhim4fnsWbAeCHgEBAQQjEUMCDAQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEDgUIAYgEDKx5hFCOFYEiixiDLjJhA5cdjyiCYw2CIA X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="146865382" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 28 Nov 2012 00:27:51 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAS0Rp8V003942 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Nov 2012 00:27:51 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.218]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 18:27:50 -0600 From: "Subha Dhesikan (sdhesika)" <sdhesika@cisco.com> To: "tsvwg@ietf.org" <tsvwg@ietf.org> Thread-Topic: New Version Notification for draft-dhesikan-tsvwg-rtcweb-qos-00.txt Thread-Index: AQHNzP4wldDiDuv9Jkm9Z0MbjGgYi5f+YviA Date: Wed, 28 Nov 2012 00:27:50 +0000 Message-ID: <AAD74A5C56B6A249AA8C0D3B41F86990151B3B1D@xmb-aln-x10.cisco.com> References: <20121128002033.10683.71629.idtracker@ietfa.amsl.com> In-Reply-To: <20121128002033.10683.71629.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.165.186] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Cullen Jennings \(fluffy\)" <fluffy@cisco.com>, "DAN DRUTA \(dd5826@att.com\)" <dd5826@att.com>, "James Polk \(jmpolk\)" <jmpolk@cisco.com>, "Paul Jones \(paulej\)" <paulej@cisco.com> Subject: [tsvwg] FW: New Version Notification for draft-dhesikan-tsvwg-rtcweb-qos-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group <tsvwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg> List-Post: <mailto:tsvwg@ietf.org> List-Help: <mailto:tsvwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Nov 2012 00:27:52 -0000 VGhpcyBkb2N1bWVudCB3YXMgb3JpZ2luYWxseSBzdWJtaXR0ZWQgaW4gUlRDV2ViIFdHIGFuZCB3 YXMgYWRvcHRlZCBhcyBhIFdHIGRvY3VtZW50LiAgVGhlIHRyYW5zcG9ydCBBRCByZXF1ZXN0ZWQg dGhhdCB0aGlzIGJlIG1vdmVkIHRvIFRTVldHLiBUaGVyZWZvcmUsIHRoaXMgZG9jdW1lbnQgaXMg bm93IHN1Ym1pdHRlZCBhcyBhbiBpbmRpdmlkdWFsIHN1Ym1pc3Npb24gdG8gVFNWV0cuIA0KDQpS ZWdhcmRzLA0KU3ViaGENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpT ZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAyNywgMjAxMiA0OjIxIFBNDQpUbzogcGF1bGVqQHBhY2tl dGl6ZXIuY29tDQpDYzogZGQ1ODI2QGF0dC5jb207IEphbWVzIFBvbGsgKGptcG9sayk7IFN1Ymhh IERoZXNpa2FuIChzZGhlc2lrYSkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtZGhlc2lrYW4tdHN2d2ctcnRjd2ViLXFvcy0wMC50eHQNCg0KDQpBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtZGhlc2lrYW4tdHN2d2ctcnRjd2ViLXFvcy0wMC50eHQNCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUGF1bCBKb25lcyBhbmQgcG9zdGVkIHRvIHRo ZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtZGhlc2lrYW4tdHN2d2ctcnRj d2ViLXFvcw0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgRFNDUCBhbmQgb3RoZXIgcGFja2V0IG1h cmtpbmdzIGZvciBSVENXZWIgUW9TDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0xMS0yNw0KV0cgSUQ6 CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDEwDQpVUkw6ICAgICAg ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWRoZXNpa2Fu LXRzdndnLXJ0Y3dlYi1xb3MtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZGhlc2lrYW4tdHN2d2ctcnRjd2ViLXFvcw0KSHRtbGl6 ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kaGVzaWthbi10c3Z3 Zy1ydGN3ZWItcW9zLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBNYW55IG5ldHdvcmtzLCBzdWNoIGFz IHNlcnZpY2UgcHJvdmlkZXIgYW5kIGVudGVycHJpc2UgbmV0d29ya3MsIGNhbg0KICAgcHJvdmlk ZSBwZXIgcGFja2V0IHRyZWF0bWVudHMgYmFzZWQgb24gRGlmZmVyZW50aWF0ZWQgU2VydmljZXMg Q29kZQ0KICAgUG9pbnRzIChEU0NQKSBvbiBhIHBlciBob3AgYmFzaXMuICBUaGlzIGRvY3VtZW50 IHByb3ZpZGVzIHRoZQ0KICAgcmVjb21tZW5kZWQgRFNDUCB2YWx1ZXMgZm9yIGJyb3dzZXJzIHRv IHVzZSBmb3IgdmFyaW91cyBjbGFzc2VzIG9mDQogICB0cmFmZmljLg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K