Re: [PCN] hope changes in PCN drafts will not affect validity assumptions in draft-ietf-tsvwg-rsvp-pcn

Toby Moncaster <toby.moncaster@cl.cam.ac.uk> Sat, 24 March 2012 17:15 UTC

Return-Path: <tm444@hermes.cam.ac.uk>
X-Original-To: pcn@ietfa.amsl.com
Delivered-To: pcn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5265C21F8535 for <pcn@ietfa.amsl.com>; Sat, 24 Mar 2012 10:15:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.203
X-Spam-Level:
X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Vw-Znh4g+Ff for <pcn@ietfa.amsl.com>; Sat, 24 Mar 2012 10:15:21 -0700 (PDT)
Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 77C9F21F852A for <pcn@ietf.org>; Sat, 24 Mar 2012 10:15:21 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from dab-bhx2-nat-blade-1-56.dab.02.net ([82.132.232.188]:58724 helo=[10.92.13.240]) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1SBUYi-0001HX-Da (Exim 4.72) (return-path <tm444@hermes.cam.ac.uk>); Sat, 24 Mar 2012 17:15:20 +0000
References: <FF1A9612A94D5C4A81ED7DE1039AB80F26C25AD1@EXMBX04.ad.utwente.nl> <9510D26531EF184D9017DF24659BB87F331DE0C40F@EMV65-UKRD.domain1.systemhost.net>
In-Reply-To: <9510D26531EF184D9017DF24659BB87F331DE0C40F@EMV65-UKRD.domain1.systemhost.net>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"
Message-Id: <9A4BFF10-7224-4A90-878D-A93B82C965CB@cl.cam.ac.uk>
X-Mailer: iPhone Mail (9B179)
From: Toby Moncaster <toby.moncaster@cl.cam.ac.uk>
Date: Sat, 24 Mar 2012 17:15:12 +0000
To: "<philip.eardley@bt.com>" <philip.eardley@bt.com>
Sender: "T. Moncaster" <tm444@hermes.cam.ac.uk>
Cc: "<pcn@ietf.org>" <pcn@ietf.org>
Subject: Re: [PCN] hope changes in PCN drafts will not affect validity assumptions in draft-ietf-tsvwg-rsvp-pcn
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Mar 2012 17:15:22 -0000

I would certainly assume that, for the purposes of controlling pre-congestion, an iea consists of all PCN traffic between a given Ingress and egress.

If that aggregate is considered as a single flow then in effect flow termination of some of the constituent flows is a form of flow slowing. But PCN has no actual mechanism for flow slowing (except the proposals for leaking the marks to the end systems).



On 24 Mar 2012, at 17:04, <philip.eardley@bt.com> wrote:

> It's Quite a while since I read the edge behavior docs but I don't understand these assumptions. An iea is ask the traffic between two boundary nodes, what's the idea of several? The pcn architecture talks about admission control and flow termination, flow slowing is an interesting idea but seems different to me
> ________________________________________
> From: pcn-bounces@ietf.org [pcn-bounces@ietf.org] On Behalf Of karagian@cs.utwente.nl [karagian@cs.utwente.nl]
> Sent: 24 March 2012 05:19
> To: pcn@ietf.org
> Subject: [PCN] hope changes in PCN drafts will not affect validity assumptions in draft-ietf-tsvwg-rsvp-pcn
> 
> Hi all,
> 
> 
> 
> From what I can recall the edge behavior drafts could proceed with their publication based on the assumption that the draft-ietf-tsvwg-rsvp-pcn will be standardized in tsvwg.
> 
> Due to some changes that are being implemented lately the validity of two main assumptions in the draft-ietf-tsvwg-rsvp-pcn might not hold anymore.
> However, this is not clear to me.
> I hope that the validity of the following two main assumptions considered in draft-ietf-tsvwg-rsvp-pcn are still valid, without breaking the PCN SM and CL edge behavior specifications:
> 
> Assumption 1: More than one IEAs between same pair of PCN edge nodes should be supported, each of them using a different PHB-ID value
> Why?: A requesting individual flow has a higher chance to be admitted to an IEA that is NOT in PCN-admission-state
> How? When IEA supported by a PCN-ingress-node is in PCN-admission state, then based on local policy, requesting e2e RSVP session (individual flow) should be either rejected or mapped to another IEA that is NOT in PCN-admission-state
> 
> Assumption 2: PCN-ingress-node should be able to reduce bandwidth of an individual flow without terminating the flow
> Why?: flows will not be terminated unnecessary and at the same time the IEA bandwidth is reduced to solve the severe congestion
> How?: When for IEA supported by PCN-ingress-node incoming traffic needs to be reduced then:
> based on a local policy and for same IEA, selects a number of e2e RSVP sessions (individual flows) to be either terminated or reserved bandwidth of e2e RSVP sessions (individual flows) is reduced
> 
> If these assumptions are not valid anymore then we might need to do changes in the not yet published PCN drafts!
> 
> Best regards,
> Georgios
> 
> _______________________________________________
> PCN mailing list
> PCN@ietf.org
> https://www.ietf.org/mailman/listinfo/pcn