From pcn-bounces@ietf.org Wed Apr 2 05:56:03 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA24A28C502; Wed, 2 Apr 2008 05:56:03 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BCDC28C4FC for ; Wed, 2 Apr 2008 05:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.486 X-Spam-Level: X-Spam-Status: No, score=-4.486 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqrpflF5CduH for ; Wed, 2 Apr 2008 05:56:02 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2B07128C4D9 for ; Wed, 2 Apr 2008 05:56:02 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6697120F9E; Wed, 2 Apr 2008 14:54:20 +0200 (CEST) X-AuditID: c1b4fb3c-ac898bb00000193b-79-47f381fc4952 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4954C206A7; Wed, 2 Apr 2008 14:54:20 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 14:54:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 14:54:19 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AciUwKp6sDFsHzDSSPWPGftVEMz2ig== From: "Lars Westberg" To: X-OriginalArrivalTime: 02 Apr 2008 12:54:19.0986 (UTC) FILETIME=[AAC70320:01C894C0] X-Brightmail-Tracker: AAAAAA== Subject: [PCN] (no subject) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0955277633==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0955277633== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C894C0.AA5A182F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C894C0.AA5A182F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, From the PCN architecture draft that I have read and from the discussions that I have followed I see that PCN is currently only supporting the trunk aggregation model, where ingress-egreess-aggregated states are used. Thus each ingress and egress will use per each ingress - egress set one aggregated state. In am concerned about the scalabillity to large networks. This is due to the N^2 trunk mesh of trunks, where N represents the number of edges in a network. I think it would be good if PCN could support the HOSE model, where no aggregation states are used to model a bandwidth limit. Therefore, I would recommend to look into PCN -extention for HOSE type scenario. comments? -lasse ------_=_NextPart_001_01C894C0.AA5A182F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,
From the PCN architecture draft = that I have read and from the discussions that I have followed I see = that PCN is currently only supporting the trunk aggregation model, where = ingress-egreess-aggregated states are used. Thus each ingress and egress = will use per each ingress - egress set one aggregated state.

In am concerned about the = scalabillity to large networks. This is due to the
N^2 trunk mesh of trunks, where = N represents the number of edges in a network.

I think it would be good if PCN = could support the HOSE model, where no aggregation states are used to = model a bandwidth limit.  Therefore, I would recommend to look into = PCN -extention for HOSE type scenario.

comments?

-lasse

------_=_NextPart_001_01C894C0.AA5A182F-- --===============0955277633== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0955277633==-- From pcn-bounces@ietf.org Wed Apr 2 10:07:37 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54C713A6D28; Wed, 2 Apr 2008 10:07:37 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9B483A6C95 for ; Wed, 2 Apr 2008 10:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.824 X-Spam-Level: X-Spam-Status: No, score=0.824 tagged_above=-999 required=5 tests=[AWL=1.327, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTvxbQR8wpLs for ; Wed, 2 Apr 2008 10:07:26 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id C626928C4CD for ; Wed, 2 Apr 2008 10:06:59 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m32H6sKc000530; Wed, 2 Apr 2008 19:06:57 +0200 (MEST) From: "Georgios Karagiannis" To: "'Lars Westberg'" , References: Date: Wed, 2 Apr 2008 19:06:43 +0200 Message-ID: <003501c894e3$efdb68c0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciUwKp6sDFsHzDSSPWPGftVEMz2igAIvgwQ X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 02 Apr 2008 19:06:57 +0200 (MEST) Subject: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated) model? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0478392066==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0478392066== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01C894F4.B36438C0" This is a multi-part message in MIME format. ------=_NextPart_000_0036_01C894F4.B36438C0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Lars I would like to rephrase the subject title of your email that you sent this morning? Do you agree with the subject title? Best regards, Georgios _____ From: Lars Westberg [mailto:lars.westberg@ericsson.com] Sent: woensdag 2 april 2008 14:54 To: pcn@ietf.org Cc: Georgios Karagiannis Subject: Hi, From the PCN architecture draft that I have read and from the discussions that I have followed I see that PCN is currently only supporting the trunk aggregation model, where ingress-egreess-aggregated states are used. Thus each ingress and egress will use per each ingress - egress set one aggregated state. In am concerned about the scalabillity to large networks. This is due to the N^2 trunk mesh of trunks, where N represents the number of edges in a network. I think it would be good if PCN could support the HOSE model, where no aggregation states are used to model a bandwidth limit. Therefore, I would recommend to look into PCN -extention for HOSE type scenario. comments? -lasse ------=_NextPart_000_0036_01C894F4.B36438C0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Lars
 
I would like to rephrase the subject = title of your=20 email that you sent this morning?
Do you agree with the subject=20 title?
 
Best regards,
Georgios
 

From: Lars Westberg=20 [mailto:lars.westberg@ericsson.com]
Sent: woensdag 2 april = 2008=20 14:54
To: pcn@ietf.org
Cc: Georgios=20 Karagiannis
Subject:

Hi,
From the PCN architecture draft that I have read and from the = discussions that I have followed I see that PCN is currently only = supporting=20 the trunk aggregation model, where ingress-egreess-aggregated states = are used.=20 Thus each ingress and egress will use per each ingress - egress set = one=20 aggregated state.

In am concerned about the = scalabillity to=20 large networks. This is due to the
N^2 trunk mesh of trunks, where N represents the number of = edges in a=20 network.

I think it would be good if PCN = could=20 support the HOSE model, where no aggregation states are used to model = a=20 bandwidth limit.  Therefore, I would recommend to look into PCN=20 -extention for HOSE type scenario.

comments?

-lasse =

------=_NextPart_000_0036_01C894F4.B36438C0-- --===============0478392066== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0478392066==-- From pcn-bounces@ietf.org Wed Apr 2 14:13:46 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 702513A6A55; Wed, 2 Apr 2008 14:13:46 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCCD13A695B for ; Wed, 2 Apr 2008 14:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtVsP+fyo308 for ; Wed, 2 Apr 2008 14:13:45 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C00CF3A6A55 for ; Wed, 2 Apr 2008 14:13:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,595,1199682000"; d="scan'208";a="3927619" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 02 Apr 2008 17:13:46 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m32LDkIN026599; Wed, 2 Apr 2008 17:13:46 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m32LDjeH020850; Wed, 2 Apr 2008 21:13:45 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 17:13:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 17:13:45 -0400 Message-ID: In-Reply-To: <1206983895.3561.12.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Consensus questions: Q4, Q5, and Q6 Thread-Index: AciTU3ayZ7guPiZ1SqKD4srHNZ5TvQBsfeLw From: "Anna Charny (acharny)" To: "Steven Blake" , "pcn" X-OriginalArrivalTime: 02 Apr 2008 21:13:45.0993 (UTC) FILETIME=[6FE8CF90:01C89506] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2249; t=1207170826; x=1208034826; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20 |Subject:=20RE=3A=20[PCN]=20Consensus=20questions=3A=20Q4,= 20Q5,=20and=20Q6 |Sender:=20 |To:=20=22Steven=20Blake=22=20,= 20=22pcn=22=20; bh=oAQ2B0GHPvbjMto7TlTruszxnnZi4zW/OXKto8xY7yU=; b=FCWO8r5MEGQzwzUKgmBTXqO9FCLiZJ5A+qtVl5S83D0czgljQFLUBhKrvq Z1GYlqTqoLOzPXi2yW6K79MoajmAF0qpLiI9VOnRkkjdlrt98oUC2bs3F79A /588jVTWoh; Authentication-Results: rtp-dkim-2; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hello Steven and all, Please see below: > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Steven Blake > Sent: Monday, March 31, 2008 1:18 PM > To: pcn > Subject: [PCN] Consensus questions: Q4, Q5, and Q6 > > Here are the remaining three questions that were taken during the IETF > 71 meeting: > > Q4: Should the standards-track PCN scheme require (as a MUST implement > feature) that interior PCN routers support Excess-Rate marking, > according to the particular method of handling already marked > packets and drops described in Anna Charny's presentation? > http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf Yes > > Q5: Should the standards-track PCN scheme require (as a MUST implement > feature) that interior PCN routers support Threshold marking (in > addition to Excess-Rate marking), according to the > particular method > described in Philip Eardley's presentation on Tuesday? > http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf No, in my opinion. It would put an undue burden on the implementation that wants to do both admission and termination using excess rate marking only. I would be much happier with a SHOULD. > > Q6: If presented with sufficient evidence in a timely fashion, would > the PCN wg entertain the option of modifying the interior router > Excess-Rate marking behavior for the standards-track PCN > scheme (as > described in question 4)? > > According to the draft meeting minutes, Q4 was accepted 8-0 > (my notes have it as 6-0), Q5 was accepted 6-1, and Q6 was > accepted 2-0. > Abstained. Depends on the nature of the evidence. Thanks, Anna > Please send comments to the list during the next few days. > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Apr 2 22:18:15 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2FD03A6B37; Wed, 2 Apr 2008 22:18:15 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 032593A6B37 for ; Wed, 2 Apr 2008 22:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.348 X-Spam-Level: X-Spam-Status: No, score=-4.348 tagged_above=-999 required=5 tests=[AWL=1.901, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5CNpvb370Xp for ; Wed, 2 Apr 2008 22:18:14 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C687F3A6831 for ; Wed, 2 Apr 2008 22:18:13 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id ACFD120A99 for ; Thu, 3 Apr 2008 07:16:06 +0200 (CEST) X-AuditID: c1b4fb3c-af89ebb00000193b-19-47f468167407 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 91706203F3 for ; Thu, 3 Apr 2008 07:16:06 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 07:16:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 07:16:05 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Why is PCN only supporting trunk (ingress-egresss-aggregated) model? Thread-Index: AciVSdFGZ3scO5PmRhKfzH6dBkS3dA== From: "Lars Westberg" To: X-OriginalArrivalTime: 03 Apr 2008 05:16:05.0927 (UTC) FILETIME=[D1744B70:01C89549] X-Brightmail-Tracker: AAAAAA== Subject: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated) model? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2079654287==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============2079654287== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89549.D13330AE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89549.D13330AE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 From the PCN architecture draft that I have read and from the discussions that I have followed I see that PCN is currently only supporting the trunk aggregation model, where ingress-egreess-aggregated states are used. Thus each ingress and egress will use per each ingress - egress set one aggregated state. In am concerned about the scalabillity to large networks. This is due to the=20 N^2 trunk mesh of trunks, where N represents the number of edges in a network.=20 I think it would be good if PCN could support the HOSE model, where no aggregation states are used to model a bandwidth limit. Therefore, I would recommend to look into PCN -extention for HOSE type scenario. comments?=20 -lasse=20 ------_=_NextPart_001_01C89549.D13330AE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why is PCN only supporting trunk (ingress-egresss-aggregated) = model?

Hi,
From the PCN architecture = draft that I have read and from the discussions that I have followed I = see that PCN is currently only supporting the trunk aggregation model, = where ingress-egreess-aggregated states are used. Thus each ingress and = egress will use per each ingress - egress set one aggregated = state.

In am concerned about the = scalabillity to large networks. This is due to the
N^2 trunk mesh of trunks, = where N represents the number of edges in a network.
I think it would be good if PCN = could support the HOSE model, where no aggregation states are used to = model a bandwidth limit. Therefore, I would recommend to look into PCN = -extention for HOSE type scenario.

comments?
-lasse=20

------_=_NextPart_001_01C89549.D13330AE-- --===============2079654287== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============2079654287==-- From pcn-bounces@ietf.org Thu Apr 3 00:51:23 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 134643A6B37; Thu, 3 Apr 2008 00:51:23 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0963A69AE for ; Thu, 3 Apr 2008 00:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_ASCII0=1.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtvfyEMJBO-p for ; Thu, 3 Apr 2008 00:51:16 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 7B66B3A6C7B for ; Thu, 3 Apr 2008 00:51:16 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 08:51:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 08:51:16 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B346E7@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? Thread-Index: AciVSdFGZ3scO5PmRhKfzH6dBkS3dAAFEgxQ From: To: , X-OriginalArrivalTime: 03 Apr 2008 07:51:17.0970 (UTC) FILETIME=[7FDD4B20:01C8955F] Subject: Re: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0424116162==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0424116162== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8955F.7F254512" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8955F.7F254512 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lasse To check: the hose model would mean that the admission decision is made at each ingress node, regardless of what egress the traffic is destined to. So, a PCN hose model would involve each ingress getting congestion reports from every egress (for traffic from that ingress) and recording them as a collected (aggregated) value of pre-congestion.=20 As far as I know, no-one has looked at this - I don't think we should delay current progress by looking at it, since it seems to me a significant change to the conceptual model. But it looks to me like an extension that could easily be done with the pcn technology described in the architecture draft.=20 phil =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars Westberg Sent: 03 April 2008 06:16 To: pcn@ietf.org Subject: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? =20 Hi, From the PCN architecture draft that I have read and from the discussions that I have followed I see that PCN is currently only supporting the trunk aggregation model, where ingress-egreess-aggregated states are used. Thus each ingress and egress will use per each ingress - egress set one aggregated state. In am concerned about the scalabillity to large networks. This is due to the N^2 trunk mesh of trunks, where N represents the number of edges in a network.=20 I think it would be good if PCN could support the HOSE model, where no aggregation states are used to model a bandwidth limit. Therefore, I would recommend to look into PCN -extention for HOSE type scenario. comments?=20 -lasse=20 ------_=_NextPart_001_01C8955F.7F254512 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why is PCN only supporting trunk (ingress-egresss-aggregated) = model?

Lasse

To check: the hose model would mean = that the admission decision is made at each ingress node, regardless of what = egress the traffic is destined to. So, a PCN hose model would involve each = ingress getting congestion reports from every egress (for traffic from that = ingress) and recording them as a collected (aggregated) value of pre-congestion. =

As far as I know, no-one has looked = at this – I don’t think we should delay current progress by = looking at it, since it seems to me a significant change to the conceptual model. = But it looks to me like an extension that could easily be done with the pcn = technology described in the architecture draft.

phil

 

-----Original Message-----
From: = pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = Behalf Of Lars Westberg
Sent: 03 April 2008 = 06:16
To: pcn@ietf.org
Subject: [PCN] Why is PCN = only supporting trunk (ingress-egresss-aggregated)model?

 

Hi,
From the PCN architecture draft that I have read and from the discussions = that I have followed I see that PCN is currently only supporting the trunk = aggregation model, where ingress-egreess-aggregated states are used. Thus each = ingress and egress will use per each ingress - egress set one aggregated = state.

In am concerned about the scalabillity to large networks. = This is due to the
N^2 trunk mesh of trunks, where N represents the number of edges in a = network.
I think it would be good if PCN could support the HOSE model, where no aggregation states are used to model a bandwidth limit. Therefore, I = would recommend to look into PCN -extention for HOSE type = scenario.

comments?
-lasse

=00 ------_=_NextPart_001_01C8955F.7F254512-- --===============0424116162== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0424116162==-- From pcn-bounces@ietf.org Thu Apr 3 07:53:30 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 332F428C6CF; Thu, 3 Apr 2008 07:53:30 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3791C28C649 for ; Thu, 3 Apr 2008 07:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.981 X-Spam-Level: X-Spam-Status: No, score=-4.981 tagged_above=-999 required=5 tests=[AWL=1.267, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNeRzTa5frMQ for ; Thu, 3 Apr 2008 07:53:20 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6101A28C6CF for ; Thu, 3 Apr 2008 07:53:20 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1CABA21E56; Thu, 3 Apr 2008 16:50:43 +0200 (CEST) X-AuditID: c1b4fb3c-b009fbb00000193b-ad-47f4eec28deb Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E39C52088A; Thu, 3 Apr 2008 16:50:42 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 16:50:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 16:50:40 +0200 Message-ID: In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B346E7@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? Thread-Index: AciVSdFGZ3scO5PmRhKfzH6dBkS3dAAFEgxQAA48TiA= References: <75A199C5D243C741BF3D3F1EBCEF9BA503B346E7@E03MVZ1-UKDY.domain1.systemhost.net> From: "Lars Westberg" To: , X-OriginalArrivalTime: 03 Apr 2008 14:50:42.0433 (UTC) FILETIME=[170D9F10:01C8959A] X-Brightmail-Tracker: AAAAAA== Subject: Re: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0622142946==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0622142946== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8959A.161B252A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8959A.161B252A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Phil =20 The major problem is that the egress will notice the congestion if a single marking scheme is used but I think it may be a problem to calculate the excess rate.=20 May be you can check it more in detail. =20 =20 One of the reason is of cources that we are thinking of deplyment scenario where the number of edges are very large and I am worried that the trunk-approach will impose a limitations in the network design.=20 =20 -Lasse ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: den 3 april 2008 09:51 To: Lars Westberg; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? Lasse To check: the hose model would mean that the admission decision is made at each ingress node, regardless of what egress the traffic is destined to. So, a PCN hose model would involve each ingress getting congestion reports from every egress (for traffic from that ingress) and recording them as a collected (aggregated) value of pre-congestion.=20 As far as I know, no-one has looked at this - I don't think we should delay current progress by looking at it, since it seems to me a significant change to the conceptual model. But it looks to me like an extension that could easily be done with the pcn technology described in the architecture draft.=20 phil =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars Westberg Sent: 03 April 2008 06:16 To: pcn@ietf.org Subject: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? =20 Hi, From the PCN architecture draft that I have read and from the discussions that I have followed I see that PCN is currently only supporting the trunk aggregation model, where ingress-egreess-aggregated states are used. Thus each ingress and egress will use per each ingress - egress set one aggregated state. In am concerned about the scalabillity to large networks. This is due to the N^2 trunk mesh of trunks, where N represents the number of edges in a network.=20 I think it would be good if PCN could support the HOSE model, where no aggregation states are used to model a bandwidth limit. Therefore, I would recommend to look into PCN -extention for HOSE type scenario. comments?=20 -lasse=20 ------_=_NextPart_001_01C8959A.161B252A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why is PCN only supporting trunk = (ingress-egresss-aggregated) model?
Hi Phil
 
The = major problem is=20 that the egress will notice the congestion if a single marking = scheme=20 is used but I think it may be a problem to calculate the excess rate.=20
May be = you can check=20 it more in detail.  
 
One of = the reason is=20 of cources that we are thinking of deplyment scenario where the = number of=20 edges are very large and I am worried that the trunk-approach=20 will impose a limitations in the network=20 design. 
 
-Lasse

From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: den 3 april 2008=20 09:51
To: Lars Westberg; pcn@ietf.org
Subject: RE: = [PCN] Why=20 is PCN only supporting trunk=20 (ingress-egresss-aggregated)model?

Lasse

To check: the = hose=20 model would mean that the admission decision is made at each ingress = node,=20 regardless of what egress the traffic is destined to. So, a PCN hose = model would=20 involve each ingress getting congestion reports from every egress (for = traffic=20 from that ingress) and recording them as a collected (aggregated) value = of=20 pre-congestion.

As far as I = know,=20 no-one has looked at this – I don’t think we should delay = current progress by=20 looking at it, since it seems to me a significant change to the = conceptual=20 model. But it looks to me like an extension that could easily be done = with the=20 pcn technology described in the architecture draft.

phil

 

-----Original=20 Message-----
From:=20 pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars = Westberg
Sent: 03 April 2008 = 06:16
To: pcn@ietf.org
Subject: [PCN] Why is PCN only = supporting=20 trunk (ingress-egresss-aggregated)model?

 

Hi,
From the PCN = architecture=20 draft that I have read and from the discussions that I have followed I = see that=20 PCN is currently only supporting the trunk aggregation model, where=20 ingress-egreess-aggregated states are used. Thus each ingress and egress = will=20 use per each ingress - egress set one aggregated = state.

In am concerned = about the=20 scalabillity to large networks. This is due to = the
N^2 trunk mesh of = trunks,=20 where N represents the number of edges in a network. =
I think it would = be good if=20 PCN could support the HOSE model, where no aggregation states are used = to model=20 a bandwidth limit. Therefore, I would recommend to look into PCN = -extention for=20 HOSE type scenario.

comments?=20
-lasse=20

------_=_NextPart_001_01C8959A.161B252A-- --===============0622142946== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0622142946==-- From pcn-bounces@ietf.org Thu Apr 3 08:28:44 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD5D828C61D; Thu, 3 Apr 2008 08:28:44 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C524928C61D for ; Thu, 3 Apr 2008 08:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQKsRD0Ubfme for ; Thu, 3 Apr 2008 08:28:33 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 5F1993A6B42 for ; Thu, 3 Apr 2008 08:28:33 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 03 Apr 2008 08:28:37 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m33FSbk2000943; Thu, 3 Apr 2008 08:28:37 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m33FSZrK014222; Thu, 3 Apr 2008 15:28:36 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 11:28:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 11:28:27 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? Thread-Index: AciVSdFGZ3scO5PmRhKfzH6dBkS3dAAFEgxQAA48TiAAAfZwMA== From: "Anna Charny (acharny)" To: "Lars Westberg" , , X-OriginalArrivalTime: 03 Apr 2008 15:28:28.0601 (UTC) FILETIME=[5DCB6A90:01C8959F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14430; t=1207236517; x=1208100517; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20 |Subject:=20RE=3A=20[PCN]=20Why=20is=20PCN=20only=20support ing=20trunk(ingress-egresss-aggregated)model? |Sender:=20; bh=1M2Wr44EZMa6h77zRZe61SB57F38hYhxymSYcnRtyHI=; b=BUy83fXakEa9Z1EFyiv8yGyVf9jh833VDt2HFlIgf/if63RZMXAoCAtdhw D5FraLwrdZfzn2d3JsGqFK3zoieZEBeKf0MmSOzFdyAnclwhOaeNYhlwEZLf EDYkTaUs6m; Authentication-Results: sj-dkim-4; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0539803853==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0539803853== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8959F.5D95C4AB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8959F.5D95C4AB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lars,=20 =20 Would it not be the case that if you do not have congestion estimates per ingress-egress pair, you cannot accurately know flows to which egresses you need to stop admission trigger termination for.=20 =20 I was under the impression that the reason the trunk mode is needed is precisely because we do not really=20 know how to make the hose model work accurately. But perhaps I am missing exactly what you have in mind? =20 Thank you, Anna=20 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars Westberg Sent: Thursday, April 03, 2008 10:51 AM To: philip.eardley@bt.com; pcn@ietf.org Subject: Re: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? =09 =09 =09 Hi Phil =20 The major problem is that the egress will notice the congestion if a single marking scheme is used but I think it may be a problem to calculate the excess rate.=20 May be you can check it more in detail. =20 =20 One of the reason is of cources that we are thinking of deplyment scenario where the number of edges are very large and I am worried that the trunk-approach will impose a limitations in the network design.=20 =20 -Lasse ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: den 3 april 2008 09:51 To: Lars Westberg; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? =09 =09 Lasse To check: the hose model would mean that the admission decision is made at each ingress node, regardless of what egress the traffic is destined to. So, a PCN hose model would involve each ingress getting congestion reports from every egress (for traffic from that ingress) and recording them as a collected (aggregated) value of pre-congestion.=20 As far as I know, no-one has looked at this - I don't think we should delay current progress by looking at it, since it seems to me a significant change to the conceptual model. But it looks to me like an extension that could easily be done with the pcn technology described in the architecture draft.=20 phil =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars Westberg Sent: 03 April 2008 06:16 To: pcn@ietf.org Subject: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? =20 Hi, From the PCN architecture draft that I have read and from the discussions that I have followed I see that PCN is currently only supporting the trunk aggregation model, where ingress-egreess-aggregated states are used. Thus each ingress and egress will use per each ingress - egress set one aggregated state. In am concerned about the scalabillity to large networks. This is due to the N^2 trunk mesh of trunks, where N represents the number of edges in a network.=20 I think it would be good if PCN could support the HOSE model, where no aggregation states are used to model a bandwidth limit. Therefore, I would recommend to look into PCN -extention for HOSE type scenario. comments?=20 -lasse=20 ------_=_NextPart_001_01C8959F.5D95C4AB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why is PCN only supporting trunk = (ingress-egresss-aggregated) model?
Lars,
 
Would it not be the case that if you do not = have congestion=20 estimates per ingress-egress pair, you cannot accurately know flows to = which=20 egresses you need to stop admission trigger termination for.=20
 
I was under the impression that th= e reason the trunk mode is needed is precisely because&n= bsp;we do not really 
know how = to make the=20 hose model work accurately.  But perhaps I am missing exactly what = you have=20 in mind?
 
Thank you,
Anna

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of Lars=20 Westberg
Sent: Thursday, April 03, 2008 10:51 = AM
To:=20 philip.eardley@bt.com; pcn@ietf.org
Subject: Re: [PCN] Why = is PCN=20 only supporting = trunk(ingress-egresss-aggregated)model?

Hi Phil
 
The = major problem is=20 that the egress will notice the congestion if a single = marking=20 scheme is used but I think it may be a problem to calculate the excess = rate.=20
May be = you can check=20 it more in detail.  
 
One of = the reason is=20 of cources that we are thinking of deplyment scenario where the = number of=20 edges are very large and I am worried that the trunk-approach=20 will impose a limitations in the network=20 design. 
 
-Lasse

From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: den 3 april 2008=20 09:51
To: Lars Westberg; pcn@ietf.org
Subject: RE: = [PCN]=20 Why is PCN only supporting trunk=20 (ingress-egresss-aggregated)model?

Lasse

To check: = the hose=20 model would mean that the admission decision is made at each ingress = node,=20 regardless of what egress the traffic is destined to. So, a PCN hose = model=20 would involve each ingress getting congestion reports from every = egress (for=20 traffic from that ingress) and recording them as a collected = (aggregated)=20 value of pre-congestion.

As far as I = know,=20 no-one has looked at this – I don’t think we should delay = current progress by=20 looking at it, since it seems to me a significant change to the = conceptual=20 model. But it looks to me like an extension that could easily be done = with the=20 pcn technology described in the architecture draft.

phil

 

-----Original=20 Message-----
From:=20 pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars = Westberg
Sent: 03 April 2008 = 06:16
To: pcn@ietf.org
Subject: [PCN] Why is PCN only = supporting=20 trunk (ingress-egresss-aggregated)model?

 

Hi,
From the PCN = architecture=20 draft that I have read and from the discussions that I have followed I = see=20 that PCN is currently only supporting the trunk aggregation model, = where=20 ingress-egreess-aggregated states are used. Thus each ingress and = egress will=20 use per each ingress - egress set one aggregated = state.

In am concerned = about the=20 scalabillity to large networks. This is due to = the
N^2 trunk mesh = of trunks,=20 where N represents the number of edges in a network. =
I think it would = be good=20 if PCN could support the HOSE model, where no aggregation states are = used to=20 model a bandwidth limit. Therefore, I would recommend to look into PCN = -extention for HOSE type scenario.

comments?=20
-lasse=20

------_=_NextPart_001_01C8959F.5D95C4AB-- --===============0539803853== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0539803853==-- From pcn-bounces@ietf.org Thu Apr 3 08:31:27 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 993F63A6C16; Thu, 3 Apr 2008 08:31:27 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBBF03A6B48 for ; Thu, 3 Apr 2008 08:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_ASCII0=1.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mwb0+UFMjUMl for ; Thu, 3 Apr 2008 08:31:18 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id EB80B28C6C8 for ; Thu, 3 Apr 2008 08:30:29 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 16:30:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 16:30:30 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B346F6@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? Thread-Index: AciVSdFGZ3scO5PmRhKfzH6dBkS3dAAFEgxQAA48TiAAAdWMQA== From: To: , X-OriginalArrivalTime: 03 Apr 2008 15:30:31.0742 (UTC) FILETIME=[A7313DE0:01C8959F] Subject: Re: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0160919789==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0160919789== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8959F.A6B152B2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8959F.A6B152B2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi lasse =20 My answer was only about admission ctrl. Actually I'm not sure I get your scalability worry - after all, in the pcn architecture doc If the number of edges is really too high for the ingress to keep track of the pre-congestion level for all the egresses, then it seems very likely that there'll be no current comms between the ingress & many of the egresses, and hence no need to track that pre-congestion level =20 On the subject of flow termination ctrl my instinct is that scalability is (even?) less of a concern. If it really is, then you could go for terminating marked flows or a subset, as in michael's EMFT =20 phil -----Original Message----- From: Lars Westberg [mailto:lars.westberg@ericsson.com]=20 Sent: 03 April 2008 15:51 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? =20 Hi Phil =20 The major problem is that the egress will notice the congestion if a single marking scheme is used but I think it may be a problem to calculate the excess rate.=20 May be you can check it more in detail. =20 =20 One of the reason is of cources that we are thinking of deplyment scenario where the number of edges are very large and I am worried that the trunk-approach will impose a limitations in the network design.=20 =20 -Lasse =20 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: den 3 april 2008 09:51 To: Lars Westberg; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? Lasse To check: the hose model would mean that the admission decision is made at each ingress node, regardless of what egress the traffic is destined to. So, a PCN hose model would involve each ingress getting congestion reports from every egress (for traffic from that ingress) and recording them as a collected (aggregated) value of pre-congestion.=20 As far as I know, no-one has looked at this - I don't think we should delay current progress by looking at it, since it seems to me a significant change to the conceptual model. But it looks to me like an extension that could easily be done with the pcn technology described in the architecture draft.=20 phil =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars Westberg Sent: 03 April 2008 06:16 To: pcn@ietf.org Subject: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? =20 Hi, From the PCN architecture draft that I have read and from the discussions that I have followed I see that PCN is currently only supporting the trunk aggregation model, where ingress-egreess-aggregated states are used. Thus each ingress and egress will use per each ingress - egress set one aggregated state. In am concerned about the scalabillity to large networks. This is due to the N^2 trunk mesh of trunks, where N represents the number of edges in a network.=20 I think it would be good if PCN could support the HOSE model, where no aggregation states are used to model a bandwidth limit. Therefore, I would recommend to look into PCN -extention for HOSE type scenario. comments?=20 -lasse=20 ------_=_NextPart_001_01C8959F.A6B152B2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why is PCN only supporting trunk (ingress-egresss-aggregated) = model?

Hi lasse

 

My answer was only about admission = ctrl. Actually I’m not sure I get your scalability worry – after all, in = the pcn architecture doc If the number of edges is really too high for the = ingress to keep track of the pre-congestion level for all the egresses, then it seems = very likely that there’ll be no current comms between the ingress & = many of the egresses, and hence no need to track that pre-congestion = level

 

On the subject of flow termination = ctrl my instinct is that scalability is (even?) less of a concern. If it really = is, then you could go for terminating marked flows or a subset, as in = michael’s EMFT

 

phil

-----Original Message-----
From: Lars Westberg [mailto:lars.westberg@ericsson.com]
Sent: 03 April 2008 15:51
To: = Eardley,PL,Philip,CXR9 R; pcn@ietf.org
Subject: RE: [PCN] Why is = PCN only supporting trunk (ingress-egresss-aggregated)model?

 

Hi Phil

 

The major problem is that the = egress will notice the congestion if a single marking scheme is used but I = think it may be a problem to calculate the excess rate.

May be you can check it more in = detail.  

 

One of the reason is of cources = that we are thinking of deplyment scenario where the number of edges are = very large and I am worried that the trunk-approach will impose a limitations in the network design. 

 

-Lasse

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: den 3 april 2008 = 09:51
To: Lars Westberg; = pcn@ietf.org
Subject: RE: [PCN] Why is = PCN only supporting trunk (ingress-egresss-aggregated)model?

Lasse

To check: the hose model would mean = that the admission decision is made at each ingress node, regardless of what = egress the traffic is destined to. So, a PCN hose model would involve each = ingress getting congestion reports from every egress (for traffic from that = ingress) and recording them as a collected (aggregated) value of pre-congestion. =

As far as I know, no-one has looked = at this – I don’t think we should delay current progress by = looking at it, since it seems to me a significant change to the conceptual model. = But it looks to me like an extension that could easily be done with the pcn = technology described in the architecture draft.

phil

 

-----Original Message-----
From: = pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = Behalf Of Lars Westberg
Sent: 03 April 2008 = 06:16
To: pcn@ietf.org
Subject: [PCN] Why is PCN = only supporting trunk (ingress-egresss-aggregated)model?

 

Hi,
From the PCN architecture draft that I have read and from the discussions = that I have followed I see that PCN is currently only supporting the trunk = aggregation model, where ingress-egreess-aggregated states are used. Thus each = ingress and egress will use per each ingress - egress set one aggregated = state.

In am concerned about the scalabillity to large networks. = This is due to the
N^2 trunk mesh of trunks, where N represents the number of edges in a = network.
I think it would be good if PCN could support the HOSE model, where no aggregation states are used to model a bandwidth limit. Therefore, I = would recommend to look into PCN -extention for HOSE type = scenario.

comments?
-lasse

=00 ------_=_NextPart_001_01C8959F.A6B152B2-- --===============0160919789== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0160919789==-- From pcn-bounces@ietf.org Fri Apr 4 00:58:48 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2BDD28C439; Fri, 4 Apr 2008 00:58:48 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D33B328C6E2 for ; Fri, 4 Apr 2008 00:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.635 X-Spam-Level: X-Spam-Status: No, score=0.635 tagged_above=-999 required=5 tests=[AWL=1.138, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXsa8unixX-R for ; Fri, 4 Apr 2008 00:58:40 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 194C43A690F for ; Fri, 4 Apr 2008 00:58:39 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m347wIJC008992; Fri, 4 Apr 2008 09:58:39 +0200 (MEST) From: "Georgios Karagiannis" To: "'Anna Charny \(acharny\)'" , "'Lars Westberg'" , , References: Date: Fri, 4 Apr 2008 09:58:16 +0200 Message-ID: <001b01c89629$b1a9cd20$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AciVSdFGZ3scO5PmRhKfzH6dBkS3dAAFEgxQAA48TiAAAfZwMAAiXhUg X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 04 Apr 2008 09:58:41 +0200 (MEST) Subject: Re: [PCN] Why is PCN only supportingtrunk(ingress-egresss-aggregated)model? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1985421019==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1985421019== Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C8963A.75329D20" This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C8963A.75329D20 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Anna What Lars I think means is that we go forward using the trunk (ingress-egress-aggregate) model, but it should also be possible to work on an experimental RFC that supports the HOSE model Furthermore, the HOSE model works accurately if: * the egress is able to have information of the flows that were affected by the congestion * the egress is able to calculate the excess rate caused by the congestion * the egress is able to select flows that were affected by the congestion * the egress is able to know the previous ingress hop. By using the features that are currently described in LC-PCN for ECMP solution and by using per PHB aggregated states at the edges, instead of ingress-egress-aggregated states at the edges then the HOSE model can work accurately. Best regards, Georgios _____ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Anna Charny (acharny) Sent: donderdag 3 april 2008 17:28 To: Lars Westberg; philip.eardley@bt.com; pcn@ietf.org Subject: Re: [PCN] Why is PCN only supportingtrunk(ingress-egresss-aggregated)model? Lars, Would it not be the case that if you do not have congestion estimates per ingress-egress pair, you cannot accurately know flows to which egresses you need to stop admission trigger termination for. I was under the impression that the reason the trunk mode is needed is precisely because we do not really know how to make the hose model work accurately. But perhaps I am missing exactly what you have in mind? Thank you, Anna _____ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars Westberg Sent: Thursday, April 03, 2008 10:51 AM To: philip.eardley@bt.com; pcn@ietf.org Subject: Re: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? Hi Phil The major problem is that the egress will notice the congestion if a single marking scheme is used but I think it may be a problem to calculate the excess rate. May be you can check it more in detail. One of the reason is of cources that we are thinking of deplyment scenario where the number of edges are very large and I am worried that the trunk-approach will impose a limitations in the network design. -Lasse _____ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: den 3 april 2008 09:51 To: Lars Westberg; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? Lasse To check: the hose model would mean that the admission decision is made at each ingress node, regardless of what egress the traffic is destined to. So, a PCN hose model would involve each ingress getting congestion reports from every egress (for traffic from that ingress) and recording them as a collected (aggregated) value of pre-congestion. As far as I know, no-one has looked at this - I don't think we should delay current progress by looking at it, since it seems to me a significant change to the conceptual model. But it looks to me like an extension that could easily be done with the pcn technology described in the architecture draft. phil -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars Westberg Sent: 03 April 2008 06:16 To: pcn@ietf.org Subject: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? Hi, From the PCN architecture draft that I have read and from the discussions that I have followed I see that PCN is currently only supporting the trunk aggregation model, where ingress-egreess-aggregated states are used. Thus each ingress and egress will use per each ingress - egress set one aggregated state. In am concerned about the scalabillity to large networks. This is due to the N^2 trunk mesh of trunks, where N represents the number of edges in a network. I think it would be good if PCN could support the HOSE model, where no aggregation states are used to model a bandwidth limit. Therefore, I would recommend to look into PCN -extention for HOSE type scenario. comments? -lasse ------=_NextPart_000_001C_01C8963A.75329D20 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Why is PCN only supporting trunk = (ingress-egresss-aggregated) model?
Hi Anna
 
What Lars I think means is that we go forward = using the=20 trunk (ingress-egress-aggregate) model, but
it should also be possible to work on an = experimental RFC=20 that supports the HOSE model
 
Furthermore, the HOSE model works accurately=20 if:
* the egress is able to have information of the = flows that=20 were affected by the congestion
* the egress is able to calculate the excess = rate caused by=20 the congestion
* the egress is able to select flows that were = affected by=20 the congestion
* the egress is able to know the previous = ingress=20 hop.
 
By using the features that are currently = described in=20 LC-PCN for ECMP solution and by using per PHB aggregated states at the = edges,=20
instead of ingress-egress-aggregated states at = the edges=20 then the HOSE model can work accurately.
 
Best regards,
Georgios
 
 
 

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of Anna Charny=20 (acharny)
Sent: donderdag 3 april 2008 17:28
To: = Lars=20 Westberg; philip.eardley@bt.com; pcn@ietf.org
Subject: Re: = [PCN] Why=20 is PCN only=20 supportingtrunk(ingress-egresss-aggregated)model?

Lars,
 
Would it not be the case that if you do not = have=20 congestion estimates per ingress-egress pair, you cannot accurately = know flows=20 to which egresses you need to stop admission trigger termination for.=20
 
I was under the impression that th= e reason the trunk mode is needed is precisely because&n= bsp;we do not really 
know = how to make the=20 hose model work accurately.  But perhaps I am missing exactly = what you=20 have in mind?
 
Thank = you,
Anna

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of Lars=20 Westberg
Sent: Thursday, April 03, 2008 10:51 = AM
To:=20 philip.eardley@bt.com; pcn@ietf.org
Subject: Re: [PCN] Why = is PCN=20 only supporting = trunk(ingress-egresss-aggregated)model?

Hi Phil
 
The major problem is that the egress will = notice=20 the congestion if a single marking scheme is used but I = think it=20 may be a problem to calculate the excess rate.=20
May be you can check it more in detail.=20  
 
One of the reason is of cources that we = are=20 thinking of deplyment scenario where the number of edges are = very large=20 and I am worried that the trunk-approach will impose a = limitations=20 in the network = design. 
 
-Lasse

From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: den 3 april 2008=20 09:51
To: Lars Westberg; pcn@ietf.org
Subject: = RE: [PCN]=20 Why is PCN only supporting trunk=20 (ingress-egresss-aggregated)model?

Lasse

To check: = the hose=20 model would mean that the admission decision is made at each ingress = node,=20 regardless of what egress the traffic is destined to. So, a PCN hose = model=20 would involve each ingress getting congestion reports from every = egress (for=20 traffic from that ingress) and recording them as a collected = (aggregated)=20 value of pre-congestion.

As far as = I know,=20 no-one has looked at this – I don’t think we should = delay current progress=20 by looking at it, since it seems to me a significant change to the=20 conceptual model. But it looks to me like an extension that could = easily be=20 done with the pcn technology described in the architecture draft.=20

phil

 

-----Original=20 Message-----
From:=20 pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars = Westberg
Sent: 03 April 2008 = 06:16
To: pcn@ietf.org
Subject: [PCN] Why is PCN = only=20 supporting trunk = (ingress-egresss-aggregated)model?

 

Hi,
From the PCN=20 architecture draft that I have read and from the discussions that I = have=20 followed I see that PCN is currently only supporting the trunk = aggregation=20 model, where ingress-egreess-aggregated states are used. Thus each = ingress=20 and egress will use per each ingress - egress set one aggregated=20 state.

In am = concerned about=20 the scalabillity to large networks. This is due to=20 the
N^2 trunk mesh = of=20 trunks, where N represents the number of edges in a = network.=20
I think it = would be good=20 if PCN could support the HOSE model, where no aggregation states are = used to=20 model a bandwidth limit. Therefore, I would recommend to look into = PCN=20 -extention for HOSE type scenario.

comments?=20
-lasse=20

------=_NextPart_000_001C_01C8963A.75329D20-- --===============1985421019== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1985421019==-- From pcn-bounces@ietf.org Fri Apr 4 01:16:10 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A479F28C2A9; Fri, 4 Apr 2008 01:16:10 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D4483A6D02 for ; Fri, 4 Apr 2008 01:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.793 X-Spam-Level: X-Spam-Status: No, score=0.793 tagged_above=-999 required=5 tests=[AWL=0.696, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5jffzayuLdJ for ; Fri, 4 Apr 2008 01:15:57 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 243C628C62A for ; Fri, 4 Apr 2008 01:15:18 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m348FEKE010368; Fri, 4 Apr 2008 10:15:21 +0200 (MEST) From: "Georgios Karagiannis" To: , , References: <75A199C5D243C741BF3D3F1EBCEF9BA503B346F6@E03MVZ1-UKDY.domain1.systemhost.net> Date: Fri, 4 Apr 2008 10:15:09 +0200 Message-ID: <003101c8962c$04f48400$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B346F6@E03MVZ1-UKDY.domain1.systemhost.net> Thread-Index: AciVSdFGZ3scO5PmRhKfzH6dBkS3dAAFEgxQAA48TiAAAdWMQAAi8oyA X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 04 Apr 2008 10:15:22 +0200 (MEST) Subject: Re: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0519887951==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0519887951== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01C8963C.C87D5400" This is a multi-part message in MIME format. ------=_NextPart_000_0032_01C8963C.C87D5400 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Phil The scalability problem with the trunk model mentioned by Lars is the following. Suppose that a network uses 200 ingress/egress edges. In the worst case the edges will have to maintain the following number of states: Trunk model (max number of state per PHB at edges) ---------------- Max. number of ingress-egress-aggregated states at each ingress: (N-1) = 199 Max. number of ingress-egress-aggregated states at each egress: (N-1)^2 = 39601 HOSE model (max. number of states per PHB at edges) -------------- Max. number of per PHB states (instead of ingress-egress-aggregates) at each ingress: (N-1) = 199 Max. number of per PHB states at each egress: (N-1) = 199 Regarding flow termination using EMFT, as it was already emphasized during the IETF meeting, EMFT is too slow and it will not able to solve the flow termination accurately. By using the features that are currently described in LC-PCN for ECMP solution and by using per PHB aggregated states at the edges, instead of ingress-egress-aggregated states at the edges then the HOSE model can work accurately. Best regards, Georgios _____ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: donderdag 3 april 2008 17:31 To: lars.westberg@ericsson.com; pcn@ietf.org Subject: Re: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? Hi lasse My answer was only about admission ctrl. Actually I'm not sure I get your scalability worry - after all, in the pcn architecture doc If the number of edges is really too high for the ingress to keep track of the pre-congestion level for all the egresses, then it seems very likely that there'll be no current comms between the ingress & many of the egresses, and hence no need to track that pre-congestion level On the subject of flow termination ctrl my instinct is that scalability is (even?) less of a concern. If it really is, then you could go for terminating marked flows or a subset, as in michael's EMFT phil -----Original Message----- From: Lars Westberg [mailto:lars.westberg@ericsson.com] Sent: 03 April 2008 15:51 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? Hi Phil The major problem is that the egress will notice the congestion if a single marking scheme is used but I think it may be a problem to calculate the excess rate. May be you can check it more in detail. One of the reason is of cources that we are thinking of deplyment scenario where the number of edges are very large and I am worried that the trunk-approach will impose a limitations in the network design. -Lasse _____ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: den 3 april 2008 09:51 To: Lars Westberg; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? Lasse To check: the hose model would mean that the admission decision is made at each ingress node, regardless of what egress the traffic is destined to. So, a PCN hose model would involve each ingress getting congestion reports from every egress (for traffic from that ingress) and recording them as a collected (aggregated) value of pre-congestion. As far as I know, no-one has looked at this - I don't think we should delay current progress by looking at it, since it seems to me a significant change to the conceptual model. But it looks to me like an extension that could easily be done with the pcn technology described in the architecture draft. phil -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars Westberg Sent: 03 April 2008 06:16 To: pcn@ietf.org Subject: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? Hi, From the PCN architecture draft that I have read and from the discussions that I have followed I see that PCN is currently only supporting the trunk aggregation model, where ingress-egreess-aggregated states are used. Thus each ingress and egress will use per each ingress - egress set one aggregated state. In am concerned about the scalabillity to large networks. This is due to the N^2 trunk mesh of trunks, where N represents the number of edges in a network. I think it would be good if PCN could support the HOSE model, where no aggregation states are used to model a bandwidth limit. Therefore, I would recommend to look into PCN -extention for HOSE type scenario. comments? -lasse ------=_NextPart_000_0032_01C8963C.C87D5400 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Why is PCN only supporting trunk = (ingress-egresss-aggregated) model?
Hi Phil
 
The scalability problem with the trunk model = mentioned by=20 Lars is the following.
Suppose that a network uses 200 ingress/egress=20 edges.
 
In the worst case the edges will have to = maintain the=20 following number of states:
 
Trunk model (max number of state per PHB at=20 edges)
----------------
Max. number of ingress-egress-aggregated states = at each=20 ingress: (N-1) =3D 199
Max. number of ingress-egress-aggregated states = at each=20 egress: (N-1)^2 =3D  39601
 
 
HOSE model (max. number of states per PHB at=20 edges)
--------------
Max. number of per PHB states = (instead of=20 ingress-egress-aggregates) at each ingress: (N-1) = =3D 199
Max. number of per PHB states at each egress: = (N-1)=20 =3D  199
 
Regarding flow termination using EMFT, as it was already = emphasized during=20 the IETF meeting,
EMFT=20 is too slow and it will not able to solve the flow termination=20 accurately.
 
By using the features that are currently = described in=20 LC-PCN for ECMP solution and by using per PHB aggregated states at the = edges,=20
instead of ingress-egress-aggregated states at = the edges=20 then the HOSE model can work accurately.
 
 
Best=20 regards,
Georgios
 
 

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of=20 philip.eardley@bt.com
Sent: donderdag 3 april 2008=20 17:31
To: lars.westberg@ericsson.com;=20 pcn@ietf.org
Subject: Re: [PCN] Why is PCN only supporting=20 trunk(ingress-egresss-aggregated)model?

Hi=20 lasse

 

My answer = was only=20 about admission ctrl. Actually I’m not sure I get your = scalability worry –=20 after all, in the pcn architecture doc If the number of edges is = really too=20 high for the ingress to keep track of the pre-congestion level for all = the=20 egresses, then it seems very likely that there’ll be no current = comms between=20 the ingress & many of the egresses, and hence no need to track = that=20 pre-congestion level

 

On the = subject of=20 flow termination ctrl my instinct is that scalability is (even?) less = of a=20 concern. If it really is, then you could go for terminating marked = flows or a=20 subset, as in michael’s EMFT

 

phil

-----Original=20 Message-----
From: = Lars=20 Westberg [mailto:lars.westberg@ericsson.com]
Sent: 03 April=20 2008 15:51
To: Eardley,PL,Philip,CXR9 R;=20 pcn@ietf.org
Subject: RE:=20 [PCN] Why is PCN only supporting trunk=20 (ingress-egresss-aggregated)model?

 

Hi=20 Phil

 

The major = problem is=20 that the egress will notice the congestion if a single = marking=20 scheme is used but I think it may be a problem to calculate the excess = rate.=20

May be you = can check=20 it more in detail.  

 

One of the = reason is=20 of cources that we are thinking of deplyment scenario where the = number of=20 edges are very large and I am worried that the trunk-approach=20 will impose a limitations in the network = design. 

 

-Lasse

 

From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: den 3 april 2008 = 09:51
To: Lars Westberg;=20 pcn@ietf.org
Subject: RE:=20 [PCN] Why is PCN only supporting trunk=20 (ingress-egresss-aggregated)model?

Lasse

To check: = the hose=20 model would mean that the admission decision is made at each ingress = node,=20 regardless of what egress the traffic is destined to. So, a PCN hose = model=20 would involve each ingress getting congestion reports from every = egress (for=20 traffic from that ingress) and recording them as a collected = (aggregated)=20 value of pre-congestion.

As far as I = know,=20 no-one has looked at this – I don’t think we should delay = current progress by=20 looking at it, since it seems to me a significant change to the = conceptual=20 model. But it looks to me like an extension that could easily be done = with the=20 pcn technology described in the architecture draft.

phil

 

-----Original=20 Message-----
From:=20 pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars = Westberg
Sent: 03 April 2008 = 06:16
To: pcn@ietf.org
Subject: [PCN] Why is PCN only = supporting=20 trunk (ingress-egresss-aggregated)model?

 

Hi,
From the PCN = architecture=20 draft that I have read and from the discussions that I have followed I = see=20 that PCN is currently only supporting the trunk aggregation model, = where=20 ingress-egreess-aggregated states are used. Thus each ingress and = egress will=20 use per each ingress - egress set one aggregated = state.

In am concerned = about the=20 scalabillity to large networks. This is due to = the
N^2 trunk mesh = of trunks,=20 where N represents the number of edges in a network. =
I think it would = be good=20 if PCN could support the HOSE model, where no aggregation states are = used to=20 model a bandwidth limit. Therefore, I would recommend to look into PCN = -extention for HOSE type scenario.

comments?=20
-lasse=20

------=_NextPart_000_0032_01C8963C.C87D5400-- --===============0519887951== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0519887951==-- From pcn-bounces@ietf.org Fri Apr 4 01:23:06 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B53128C709; Fri, 4 Apr 2008 01:23:06 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FDE628C6FC for ; Fri, 4 Apr 2008 01:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_ASCII0=1.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EpMKLyuFbu7 for ; Fri, 4 Apr 2008 01:22:56 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id A456128C743 for ; Fri, 4 Apr 2008 01:21:55 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 09:21:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 09:21:59 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B346FF@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <003101c8962c$04f48400$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? Thread-Index: AciVSdFGZ3scO5PmRhKfzH6dBkS3dAAFEgxQAA48TiAAAdWMQAAi8oyAAACdtgA= From: To: , , X-OriginalArrivalTime: 04 Apr 2008 08:21:59.0932 (UTC) FILETIME=[F42C23C0:01C8962C] Subject: Re: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0778050366==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0778050366== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8962C.F3BC9952" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8962C.F3BC9952 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Without responding to the detail of your msg, I think the important point made by you & lasse is that you have in mind how to extent PCn to other deployment models. This is good news - however we should focus on finishing our current work before we concentrate on extensions. =20 -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: 04 April 2008 09:15 To: Eardley,PL,Philip,CXR9 R; lars.westberg@ericsson.com; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? =20 Hi Phil =20 The scalability problem with the trunk model mentioned by Lars is the following. Suppose that a network uses 200 ingress/egress edges. =20 In the worst case the edges will have to maintain the following number of states: =20 Trunk model (max number of state per PHB at edges) ---------------- Max. number of ingress-egress-aggregated states at each ingress: (N-1) = =3D 199 Max. number of ingress-egress-aggregated states at each egress: (N-1)^2 =3D 39601 =20 =20 HOSE model (max. number of states per PHB at edges) -------------- Max. number of per PHB states (instead of ingress-egress-aggregates) at each ingress: (N-1) =3D 199 Max. number of per PHB states at each egress: (N-1) =3D 199 =20 Regarding flow termination using EMFT, as it was already emphasized during the IETF meeting,=20 EMFT is too slow and it will not able to solve the flow termination accurately. =20 By using the features that are currently described in LC-PCN for ECMP solution and by using per PHB aggregated states at the edges,=20 instead of ingress-egress-aggregated states at the edges then the HOSE model can work accurately. =20 =20 Best regards, Georgios =20 =20 =20 =09 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: donderdag 3 april 2008 17:31 To: lars.westberg@ericsson.com; pcn@ietf.org Subject: Re: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? Hi lasse =20 My answer was only about admission ctrl. Actually I'm not sure I get your scalability worry - after all, in the pcn architecture doc If the number of edges is really too high for the ingress to keep track of the pre-congestion level for all the egresses, then it seems very likely that there'll be no current comms between the ingress & many of the egresses, and hence no need to track that pre-congestion level =20 On the subject of flow termination ctrl my instinct is that scalability is (even?) less of a concern. If it really is, then you could go for terminating marked flows or a subset, as in michael's EMFT =20 phil -----Original Message----- From: Lars Westberg [mailto:lars.westberg@ericsson.com]=20 Sent: 03 April 2008 15:51 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? =20 Hi Phil =20 The major problem is that the egress will notice the congestion if a single marking scheme is used but I think it may be a problem to calculate the excess rate.=20 May be you can check it more in detail. =20 =20 One of the reason is of cources that we are thinking of deplyment scenario where the number of edges are very large and I am worried that the trunk-approach will impose a limitations in the network design.=20 =20 -Lasse =20 =09 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: den 3 april 2008 09:51 To: Lars Westberg; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? Lasse To check: the hose model would mean that the admission decision is made at each ingress node, regardless of what egress the traffic is destined to. So, a PCN hose model would involve each ingress getting congestion reports from every egress (for traffic from that ingress) and recording them as a collected (aggregated) value of pre-congestion.=20 As far as I know, no-one has looked at this - I don't think we should delay current progress by looking at it, since it seems to me a significant change to the conceptual model. But it looks to me like an extension that could easily be done with the pcn technology described in the architecture draft.=20 phil =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars Westberg Sent: 03 April 2008 06:16 To: pcn@ietf.org Subject: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? =20 Hi, From the PCN architecture draft that I have read and from the discussions that I have followed I see that PCN is currently only supporting the trunk aggregation model, where ingress-egreess-aggregated states are used. Thus each ingress and egress will use per each ingress - egress set one aggregated state. In am concerned about the scalabillity to large networks. This is due to the N^2 trunk mesh of trunks, where N represents the number of edges in a network.=20 I think it would be good if PCN could support the HOSE model, where no aggregation states are used to model a bandwidth limit. Therefore, I would recommend to look into PCN -extention for HOSE type scenario. comments?=20 -lasse=20 ------_=_NextPart_001_01C8962C.F3BC9952 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why is PCN only supporting trunk (ingress-egresss-aggregated) = model?

Without responding to the detail of = your msg, I think the important point made by you & lasse is that you have in = mind how to extent PCn to other deployment models. This is good news – = however we should focus on finishing our current work before we concentrate on extensions.

 

-----Original Message-----
From: Georgios = Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 04 April 2008 = 09:15
To: = Eardley,PL,Philip,CXR9 R; lars.westberg@ericsson.com; pcn@ietf.org
Subject: RE: [PCN] Why is = PCN only supporting trunk(ingress-egresss-aggregated)model?

 

Hi Phil

 

The scalability problem with the = trunk model mentioned by Lars is the following.

Suppose that a network uses 200 ingress/egress edges.

 

In the worst case the edges will = have to maintain the following number of states:

 

Trunk model (max number of state = per PHB at edges)

----------------

Max. number of = ingress-egress-aggregated states at each ingress: (N-1) =3D 199

Max. number of = ingress-egress-aggregated states at each egress: (N-1)^2 =3D  39601

 

 

HOSE model (max. number of states = per PHB at edges)

--------------

Max. number of per = PHB states (instead of ingress-egress-aggregates) at each ingress: (N-1) = =3D 199

Max. number of per PHB states at = each egress: (N-1) =3D  199

 

Regarding flow termination using EMFT, as it was already emphasized = during the IETF meeting,

EMFT is too slow and it will not = able to solve the flow termination accurately.

 

By using the features that are = currently described in LC-PCN for ECMP solution and by using per PHB aggregated = states at the edges,

instead of = ingress-egress-aggregated states at the edges then the HOSE model can work = accurately.

 

 

Best regards,

Georgios

 

 

 

From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: donderdag 3 april = 2008 17:31
To: = lars.westberg@ericsson.com; pcn@ietf.org
Subject: Re: [PCN] Why is = PCN only supporting trunk(ingress-egresss-aggregated)model?

Hi lasse

 

My answer was only about admission = ctrl. Actually I’m not sure I get your scalability worry – after = all, in the pcn architecture doc If the number of edges is really too high for = the ingress to keep track of the pre-congestion level for all the egresses, = then it seems very likely that there’ll be no current comms between the = ingress & many of the egresses, and hence no need to track that = pre-congestion level

 

On the subject of flow termination = ctrl my instinct is that scalability is (even?) less of a concern. If it really = is, then you could go for terminating marked flows or a subset, as in michael’s EMFT

 

phil

-----Original Message-----
From: Lars Westberg [mailto:lars.westberg@ericsson.com]
Sent: 03 April 2008 = 15:51
To: = Eardley,PL,Philip,CXR9 R; pcn@ietf.org
Subject: RE: [PCN] Why is = PCN only supporting trunk (ingress-egresss-aggregated)model?

 

Hi Phil

 

The major problem is that the = egress will notice the congestion if a single marking scheme is used but I = think it may be a problem to calculate the excess rate.

May be you can check it more in = detail.  

 

One of the reason is of cources = that we are thinking of deplyment scenario where the number of edges are = very large and I am worried that the trunk-approach will impose a limitations in the network design. 

 

-Lasse

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: den 3 april 2008 = 09:51
To: Lars Westberg; = pcn@ietf.org
Subject: RE: [PCN] Why is = PCN only supporting trunk (ingress-egresss-aggregated)model?

Lasse

To check: the hose model would mean = that the admission decision is made at each ingress node, regardless of what = egress the traffic is destined to. So, a PCN hose model would involve each = ingress getting congestion reports from every egress (for traffic from that = ingress) and recording them as a collected (aggregated) value of pre-congestion. =

As far as I know, no-one has looked = at this – I don’t think we should delay current progress by = looking at it, since it seems to me a significant change to the conceptual model. = But it looks to me like an extension that could easily be done with the pcn = technology described in the architecture draft.

phil

 

-----Original Message-----
From: = pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = Behalf Of Lars Westberg
Sent: 03 April 2008 = 06:16
To: pcn@ietf.org
Subject: [PCN] Why is PCN = only supporting trunk (ingress-egresss-aggregated)model?

 

Hi,
From the PCN architecture draft that I have read and from the discussions = that I have followed I see that PCN is currently only supporting the trunk = aggregation model, where ingress-egreess-aggregated states are used. Thus each = ingress and egress will use per each ingress - egress set one aggregated = state.

In am concerned about the scalabillity to large networks. = This is due to the
N^2 trunk mesh of trunks, where N represents the number of edges in a = network.
I think it would be good if PCN could support the HOSE model, where no aggregation states are used to model a bandwidth limit. Therefore, I = would recommend to look into PCN -extention for HOSE type = scenario.

comments?
-lasse

=00 ------_=_NextPart_001_01C8962C.F3BC9952-- --===============0778050366== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0778050366==-- From pcn-bounces@ietf.org Fri Apr 4 01:50:57 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B7DE28C15A; Fri, 4 Apr 2008 01:50:57 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B4313A694E for ; Fri, 4 Apr 2008 01:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gr0ryn75f6+Y for ; Fri, 4 Apr 2008 01:50:54 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id BC2D63A6878 for ; Fri, 4 Apr 2008 01:50:17 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Fri, 4 Apr 2008 10:50:18 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 10:50:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 10:51:58 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C010BC6D7@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB6465153C513F@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Single DSCP for Admission and Flow Termination Marking Thread-Index: AciSmam/Ae1M4lI9Ra60kF9c/KnbMQDk6Syw References: <9671A92C3C8B5744BC97F855F7CB6465153C513F@zcarhxm1.corp.nortel.com> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 04 Apr 2008 08:50:17.0698 (UTC) FILETIME=[E81EAC20:01C89630] Cc: pcn@ietf.org Subject: Re: [PCN] Single DSCP for Admission and Flow Termination Marking X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0873142571==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0873142571== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89630.E7E71232" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89630.E7E71232 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Joe, =20 congratulations, smart engineering. =20 Some initial thoughts: =20 - a PCN policer counts all packets belonging to the EF-admit DSCP. After = the lower threshold is passed, a certain type is remarked, after the = upper=20 has been passed, all are remarked. - you mention probing, but I'm not sure we should call it that. We are = in=20 agreement, that the RSVP path message must be sent anyway. What=20 we talk about is an encoding option at the ingress and a specific=20 marking behaviour at the core. =20 Two questions: - is it possible to realise your proposal with a token bucket policer? I = guess=20 not, because the policer counts all packets of a certain DSCP, but it=20 modifies only part of all. This seems to resemble the behaviour of a=20 hyrachical policer. Which doesn't have to be bad - its just that = hyrachical=20 schedulers aren't a commodity in backbone routers these days. - the ingress must mark RSVP refresh messages differently than initial=20 messages. I may be wrong, but RSVP refreshes don't look different than = initial set up messages. The only difference is, that a node registers = state=20 has been set up already. The differentiation is required to avoid an = admission=20 stop to result in a termination. =20 Then let's come to one of my favorite subjects, MPLS interoperability. = Too bad,=20 that doesn't work. You can optimistically squeeze one EXP codepoint from = the MPLS bunch. So there (and I guess for Ethernet too), an SM proposal=20 will be it. That's bad in these networks and shouldn't avoid smarter = solutions=20 in the IP network. =20 However the friends of MPLS shouldn't be left without a PCN solution. I=20 currently can't imagine, how single marking could be downpropagated to = an=20 IP packet following the above coding scheme in a reasonable way.=20 Especially if your backbone works with pen ultimate hop popping of = labels. So in the MPLS case, probably a different solution is required. =20 =20 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Jozef Babiarz Sent: Sunday, March 30, 2008 9:10 PM To: pcn@ietf.org Subject: [PCN] Single DSCP for Admission and Flow Termination Marking =09 =09 I was thinking about the encoding and tunneling problem for PCN and I = think there may be a method by which a single DSCP and the ECN field can = be used to signal both admission control and flow termination using ECN = bits. Would like others to think about this and point out any issues = that I may have missed. The proposed approach can use the EF-admit DSCP for PCN. =09 My assumptions: The EF-admit DSCP is used for end-to-end admission control as proposed = by Fred Baker and the PCN wg also reuses this DSCP for PCN based = admission control and flow termination function for edge-to-edge. Should = note that I believe this can also be used for end-to-end PCN based = admission and termination but this is currently out of scope so I will = not discuss. Proposed encoding: A packet that is market with EF-admit DSCP means that it is admission = control with that ECN bits be used in the following way: ECN =3D 00, means that packet is not-PCN-capable and that admission = control is done some other way. Interior nodes remark ECN =3D "01" packets to "11" if traffic rate is = above PCN-lower-rate. Interior nodes remark ECN =3D "10" packets to "11" if traffic rate is = above PCN-upper-rate.=20 How it works: For PCN based admission control this approach requires that "probe" = packet be sent at flow setup to determine if a new flow can be admitted. = Example of a probe packet is a RSVP Path message sent from = ingress-edge-node to egress-edge-node. The RSVP Path packet is market = with EF-admit DSCP and has its ECN bits set to "01". Interior nodes = meter EF-admit packets against the PCN-lower-rate and the result of the = meter is passed to the marker where the marker remarks "01" packet to = "11" if PCN-lower-rate was exceeded. The metering and marking behavior = is the so called "threshold marking" as defined in CL or 3sm drafts for = admission control. For PCN based flow termination, once a flow is admitted, = ingress-edge-node marks admitted PCN traffic with ECN bits to "10". = Interior nodes meter EF-admit packets against PCN-upper-rate and the = results of the meter is passed to the marker where the maker remarks = "10" packets to "11" based on "excess-rate marking" with or without = marking frequency reduction.=20 The egress-edge-node knows if the "11" market packet is a probe or it = belongs to an admitted flow therefore it can interpret what the marking = means.=20 =09 This sounds simple, so what have I missed?=20 This approach works with tunneling, as ECN CE state is copied from = outer to inner IP header on de-encapsulation. I believe that this marking also satisfies guidelines in RFC4774. Are there any conditions where this marking approach will not work? =09 One final note: If PCN wg decides to reuse the EF-admit DSCP for PCN than we need to = ask Fred Baker to add a statement in to his draft that the ECN bits in = the IP header are used for other function and that RFC3168 does not = apply to EF-admit DSCP as per guidance in RFC4774. =09 Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 =09 ------_=_NextPart_001_01C89630.E7E71232 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Single DSCP for Admission and Flow Termination = Marking
Hi Joe,
 
congratulations, smart = engineering.
 
Some initial thoughts:
 
- a PCN policer counts all packets = belonging to=20 the EF-admit DSCP. After 
  the lower threshold is passed, a = certain type=20 is remarked, after the upper
  has been passed, all are=20 remarked.
- you mention probing, but I'm not sure we = should call it=20 that. We are in
  agreement, that the RSVP path = message must be=20 sent anyway. What
  we talk about is an=20 encoding option at the ingress and a specific =
  marking behaviour at the = core.
 
Two questions:
- is it possible to realise your proposal with = a token=20 bucket policer? I guess
  not, because the policer counts all = packets of a=20 certain DSCP, but it
  modifies only part of all.=20 This seems to resemble the behaviour of a =
  hyrachical policer. Which = doesn't have to=20 be bad - its just that hyrachical
  schedulers aren't a commodity in = backbone routers=20 these days.
- the ingress must mark RSVP refresh = messages=20 differently than initial
  messages. I may be wrong, but RSVP = refreshes don't=20 look different than
  initial set up messages. The only = difference is,=20 that a node registers state
  has been set up already. The = differentiation is=20 required to avoid an admission
  stop to result in a = termination.
 
Then let's come to one of my favorite subjects, = MPLS=20 interoperability. Too bad,
that doesn't work. You can optimistically = squeeze one EXP=20 codepoint from
the MPLS bunch. So there (and I guess for = Ethernet too), an=20 SM proposal
will be it. That's bad in these networks and = shouldn't=20 avoid smarter solutions
in the IP network.
 
However the friends of MPLS shouldn't be left = without a PCN=20 solution. I
currently can't imagine, how single marking = could be=20 downpropagated to an
IP packet following the above coding scheme in = a reasonable=20 way.
Especially if your backbone works with pen = ultimate hop=20 popping of labels.
So in the MPLS case, probably a different = solution is=20 required.
 
 

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of Jozef=20 Babiarz
Sent: Sunday, March 30, 2008 9:10 PM
To:=20 pcn@ietf.org
Subject: [PCN] Single DSCP for Admission and = Flow=20 Termination Marking

I=20 was thinking about the encoding and tunneling problem for PCN and I = think=20 there may be a method by which a single DSCP and the ECN field can be = used to=20 signal both admission control and flow termination using ECN bits. = Would like=20 others to think about this and point out any issues that I may have=20 missed.

The proposed approach can use = the EF-admit DSCP=20 for PCN.

My=20 assumptions:

The = EF-admit DSCP is used=20 for end-to-end admission control as proposed by Fred Baker and the PCN = wg also=20 reuses this DSCP for PCN based admission control and flow termination = function=20 for edge-to-edge. Should note that I believe this can also be used for = end-to-end PCN based admission and termination but this is currently = out of=20 scope so I will not discuss.

Proposed encoding:

A packet that is market with EF-admit DSCP means = that it is=20 admission control with that ECN bits be used in the following=20 way:

ECN =3D = 00, means that=20 packet is not-PCN-capable and that admission control is done some = other=20 way.

Interior nodes=20 remark ECN = =3D =9301=94 = packets to =9311=94 if=20 traffic rate is above PCN-lower-rate.

Interior nodes remark ECN = =3D =9310=94 = packets to =9311=94 if=20 traffic rate is above PCN-upper-rate.

How it=20 works:

For PCN = based admission=20 control this approach requires that =93probe=94 packet be sent at flow = setup to=20 determine if a new flow can be admitted. Example of a probe=20 packet = is a RSVP Path message sent from ingress-edge-node to egress-edge-node. The = RSVP Path=20 packet is market with EF-admit DSCP and has its ECN bits set=20 to =9301=94. = Interior nodes=20 meter EF-admit packets against the PCN-lower-rate and the result of = the meter=20 is passed to the marker where the marker remarks =9301=94 = packet=20 to =9311=94 if = PCN-lower-rate=20 was exceeded. The metering and marking behavior is the so=20 called = =93threshold marking=94 as defined in CL or 3sm drafts for admission=20 control.

For PCN based flow termination, once = a flow is=20 admitted, ingress-edge-node marks admitted PCN = traffic with ECN bits to =9310=94. Interior nodes=20 meter EF-admit packets against PCN-upper-rate=20 and the results of the meter is passed to the = marker = where the maker=20 remarks = =9310=94 packets to =9311=94 based on =93excess-rate marking=94 with or without marking frequency=20 reduction. =

The egress-edge-node = knows if the =9311=94 market = packet is = a probe or=20 it belongs to an admitted flow therefore it = can interpret what the marking means.

This sounds simple, so what have I missed?

This=20 approach = works with tunneling, as ECN CE = state is copied=20 from outer to inner IP header on de-encapsulation.

I=20 believe = that=20 this marking also satisfies guidelines in = RFC4774.

Are there any = conditions where=20 this marking approach will not = work?

One final note:

If=20 PCN wg decides to reuse the EF-admit DSCP for PCN than we need=20 to ask Fred Baker to add a statement in to his draft=20 that the ECN bits in the IP header are used for other = function and=20 that RFC3168 does not apply to EF-admit DSCP as per guidance in=20 RFC4774.

Regards,=20 Joe

email:babiarz@nortel.com

Telephone:613-763-6098

------_=_NextPart_001_01C89630.E7E71232-- --===============0873142571== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0873142571==-- From pcn-bounces@ietf.org Fri Apr 4 02:01:36 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91E703A6DDE; Fri, 4 Apr 2008 02:01:36 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7503A687C for ; Fri, 4 Apr 2008 02:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.068 X-Spam-Level: X-Spam-Status: No, score=-1.068 tagged_above=-999 required=5 tests=[AWL=-1.270, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, MIME_ASCII0=1.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkvBGMdjuiTx for ; Fri, 4 Apr 2008 02:01:25 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 526143A68B7 for ; Fri, 4 Apr 2008 02:01:19 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 10:01:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 10:01:22 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34700@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB6465153C513F@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Single DSCP for Admission and Flow Termination Marking Thread-Index: AciSmam/Ae1M4lI9Ra60kF9c/KnbMQDmI68A From: To: , X-OriginalArrivalTime: 04 Apr 2008 09:01:23.0607 (UTC) FILETIME=[75085270:01C89632] Subject: Re: [PCN] Single DSCP for Admission and Flow Termination Marking X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1694027691==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1694027691== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89632.74724F4A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89632.74724F4A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joe quick question - in terms of ECN compatibility - is this achieved by tunnelling over the pcn-domain?=20 Thanks Phil.=20 =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Jozef Babiarz Sent: 30 March 2008 20:10 To: pcn@ietf.org Subject: [PCN] Single DSCP for Admission and Flow Termination Marking =20 I was thinking about the encoding and tunneling problem for PCN and I think there may be a method by which a single DSCP and the ECN field can be used to signal both admission control and flow termination using ECN bits. Would like others to think about this and point out any issues that I may have missed. The proposed approach can use the EF-admit DSCP for PCN. My assumptions: The EF-admit DSCP is used for end-to-end admission control as proposed by Fred Baker and the PCN wg also reuses this DSCP for PCN based admission control and flow termination function for edge-to-edge. Should note that I believe this can also be used for end-to-end PCN based admission and termination but this is currently out of scope so I will not discuss. Proposed encoding: A packet that is market with EF-admit DSCP means that it is admission control with that ECN bits be used in the following way: ECN =3D 00, means that packet is not-PCN-capable and that admission control is done some other way. Interior nodes remark ECN =3D "01" packets to "11" if traffic rate is above PCN-lower-rate. Interior nodes remark ECN =3D "10" packets to "11" if traffic rate is above PCN-upper-rate.=20 How it works: For PCN based admission control this approach requires that "probe" packet be sent at flow setup to determine if a new flow can be admitted. Example of a probe packet is a RSVP Path message sent from ingress-edge-node to egress-edge-node. The RSVP Path packet is market with EF-admit DSCP and has its ECN bits set to "01". Interior nodes meter EF-admit packets against the PCN-lower-rate and the result of the meter is passed to the marker where the marker remarks "01" packet to "11" if PCN-lower-rate was exceeded. The metering and marking behavior is the so called "threshold marking" as defined in CL or 3sm drafts for admission control. For PCN based flow termination, once a flow is admitted, ingress-edge-node marks admitted PCN traffic with ECN bits to "10". Interior nodes meter EF-admit packets against PCN-upper-rate and the results of the meter is passed to the marker where the maker remarks "10" packets to "11" based on "excess-rate marking" with or without marking frequency reduction.=20 The egress-edge-node knows if the "11" market packet is a probe or it belongs to an admitted flow therefore it can interpret what the marking means.=20 This sounds simple, so what have I missed?=20 This approach works with tunneling, as ECN CE state is copied from outer to inner IP header on de-encapsulation. I believe that this marking also satisfies guidelines in RFC4774. Are there any conditions where this marking approach will not work? One final note: If PCN wg decides to reuse the EF-admit DSCP for PCN than we need to ask Fred Baker to add a statement in to his draft that the ECN bits in the IP header are used for other function and that RFC3168 does not apply to EF-admit DSCP as per guidance in RFC4774. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 ------_=_NextPart_001_01C89632.74724F4A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Single DSCP for Admission and Flow Termination Marking

Joe

quick question – in terms of = ECN compatibility – is this achieved by tunnelling over the = pcn-domain?

Thanks

Phil.

 

-----Original Message-----
From: = pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = Behalf Of Jozef Babiarz
Sent: 30 March 2008 = 20:10
To: pcn@ietf.org
Subject: [PCN] Single = DSCP for Admission and Flow Termination Marking

 

I was thinking about the encoding and tunneling problem for PCN = and I think there may be a method by which a single DSCP and the ECN field can = be used to signal both admission control and flow termination using ECN = bits. Would like others to think about this and point out any issues that I = may have missed.

The proposed approach = can use the EF-admit DSCP for PCN.

My assumptions:

The EF-admit DSCP is used for end-to-end admission control as = proposed by Fred Baker and the PCN wg also reuses this DSCP for PCN based = admission control and flow termination function for edge-to-edge. Should note that = I believe this can also be used for end-to-end PCN based admission and termination but this is currently out of scope so I will not = discuss.

Proposed encoding:

A packet that is market with EF-admit DSCP means that it is = admission control with that ECN bits be used in the following = way:

ECN =3D 00, means that packet is not-PCN-capable and that = admission control is done some other way.

Interior nodes remark ECN =3D “01” packets to “11” if traffic rate is above = PCN-lower-rate.

Interior nodes remark ECN =3D = “10” packets to “11” if traffic rate is above PCN-upper-rate. =

How it works:

For PCN based admission control this approach requires that “probe” packet be sent at flow setup to determine if a new = flow can be admitted. Example of a probe packet = is a RSVP Path message sent from ingress-edge-node to egress-edge-node. The = RSVP Path packet is market with EF-admit DSCP and has its ECN bits set = to “01”. Interior nodes meter = EF-admit packets against the PCN-lower-rate and the result of the meter is passed = to the marker where the marker remarks = “01” packet to “11” if PCN-lower-rate was exceeded. = The metering and marking behavior is the so called “threshold marking” as defined in CL or 3sm drafts for admission = control.

For PCN based flow termination, once a flow is admitted, ingress-edge-node marks admitted PCN traffic with ECN bits to = “10”. Interior nodes meter EF-admit packets against PCN-upper-rate = and the results of the meter is passed to the = marker where the maker remarks “10” packets to “11” based = on “excess-rate marking” with or = without marking frequency reduction. =

The egress-edge-node knows if the “11” market packet is a probe or = it belongs to an admitted flow therefore it can interpret what the marking means.

This sounds simple, so what have I missed?

This approach works with tunneling, as ECN CE state is copied from outer to inner IP header on de-encapsulation.

I believe that this marking = also satisfies guidelines in = RFC4774.

Are there any conditions where this marking approach will not = work?

One final = note:

If PCN wg decides to reuse the EF-admit DSCP for = PCN than we need to ask Fred Baker to add a = statement in to his draft that the ECN bits in the IP header are used for other = function and that RFC3168 does not apply to EF-admit DSCP as per guidance in = RFC4774.

Regards, = Joe

email:babiarz@nortel.com

Telephone:613-763-6098

=00 ------_=_NextPart_001_01C89632.74724F4A-- --===============1694027691== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1694027691==-- From pcn-bounces@ietf.org Fri Apr 4 02:06:54 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6EF73A6E13; Fri, 4 Apr 2008 02:06:54 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6056D3A69F7 for ; Fri, 4 Apr 2008 02:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.715 X-Spam-Level: X-Spam-Status: No, score=0.715 tagged_above=-999 required=5 tests=[AWL=0.618, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L31EXlGi-pq5 for ; Fri, 4 Apr 2008 02:06:40 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 246E528C290 for ; Fri, 4 Apr 2008 02:06:34 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m3496UC8021627; Fri, 4 Apr 2008 11:06:37 +0200 (MEST) From: "Georgios Karagiannis" To: , , References: <003101c8962c$04f48400$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B346FF@E03MVZ1-UKDY.domain1.systemhost.net> Date: Fri, 4 Apr 2008 11:06:25 +0200 Message-ID: <004601c89633$2e92a4c0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B346FF@E03MVZ1-UKDY.domain1.systemhost.net> Thread-Index: AciVSdFGZ3scO5PmRhKfzH6dBkS3dAAFEgxQAA48TiAAAdWMQAAi8oyAAACdtgAAAUHRcA== X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 04 Apr 2008 11:06:39 +0200 (MEST) Subject: Re: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0959137007==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0959137007== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C89643.F21B74C0" This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C89643.F21B74C0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Phil What Lars I think means is that we go forward using the trunk (ingress-egress-aggregate) model, but it should also be possible to work on an experimental RFC that supports the HOSE model. What I wanted to say is that we sould be able to work on LC-PCN as being an experimental RFC that provides and supports the HOSE model. Please note that LC-PCN can provide these HOSE features. However, in order to do that the interior/core node should be able to support the following features: * possibility to do not preferentially drop PCN_marked packets. Note that PCN_Affected_marking encoded packets can be dropped. * use the N proportion between marked excess rate and measured excess rate * provide PCN_Affected_marking encoding and allow to implement the features that are required for PCN_Affedcted_Marking. Best regards, Georgios _____ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: vrijdag 4 april 2008 10:22 To: karagian@cs.utwente.nl; lars.westberg@ericsson.com; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? Without responding to the detail of your msg, I think the important point made by you & lasse is that you have in mind how to extent PCn to other deployment models. This is good news - however we should focus on finishing our current work before we concentrate on extensions. -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] Sent: 04 April 2008 09:15 To: Eardley,PL,Philip,CXR9 R; lars.westberg@ericsson.com; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? Hi Phil The scalability problem with the trunk model mentioned by Lars is the following. Suppose that a network uses 200 ingress/egress edges. In the worst case the edges will have to maintain the following number of states: Trunk model (max number of state per PHB at edges) ---------------- Max. number of ingress-egress-aggregated states at each ingress: (N-1) = 199 Max. number of ingress-egress-aggregated states at each egress: (N-1)^2 = 39601 HOSE model (max. number of states per PHB at edges) -------------- Max. number of per PHB states (instead of ingress-egress-aggregates) at each ingress: (N-1) = 199 Max. number of per PHB states at each egress: (N-1) = 199 Regarding flow termination using EMFT, as it was already emphasized during the IETF meeting, EMFT is too slow and it will not able to solve the flow termination accurately. By using the features that are currently described in LC-PCN for ECMP solution and by using per PHB aggregated states at the edges, instead of ingress-egress-aggregated states at the edges then the HOSE model can work accurately. Best regards, Georgios _____ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: donderdag 3 april 2008 17:31 To: lars.westberg@ericsson.com; pcn@ietf.org Subject: Re: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? Hi lasse My answer was only about admission ctrl. Actually I'm not sure I get your scalability worry - after all, in the pcn architecture doc If the number of edges is really too high for the ingress to keep track of the pre-congestion level for all the egresses, then it seems very likely that there'll be no current comms between the ingress & many of the egresses, and hence no need to track that pre-congestion level On the subject of flow termination ctrl my instinct is that scalability is (even?) less of a concern. If it really is, then you could go for terminating marked flows or a subset, as in michael's EMFT phil -----Original Message----- From: Lars Westberg [mailto:lars.westberg@ericsson.com] Sent: 03 April 2008 15:51 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? Hi Phil The major problem is that the egress will notice the congestion if a single marking scheme is used but I think it may be a problem to calculate the excess rate. May be you can check it more in detail. One of the reason is of cources that we are thinking of deplyment scenario where the number of edges are very large and I am worried that the trunk-approach will impose a limitations in the network design. -Lasse _____ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: den 3 april 2008 09:51 To: Lars Westberg; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? Lasse To check: the hose model would mean that the admission decision is made at each ingress node, regardless of what egress the traffic is destined to. So, a PCN hose model would involve each ingress getting congestion reports from every egress (for traffic from that ingress) and recording them as a collected (aggregated) value of pre-congestion. As far as I know, no-one has looked at this - I don't think we should delay current progress by looking at it, since it seems to me a significant change to the conceptual model. But it looks to me like an extension that could easily be done with the pcn technology described in the architecture draft. phil -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars Westberg Sent: 03 April 2008 06:16 To: pcn@ietf.org Subject: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? Hi, From the PCN architecture draft that I have read and from the discussions that I have followed I see that PCN is currently only supporting the trunk aggregation model, where ingress-egreess-aggregated states are used. Thus each ingress and egress will use per each ingress - egress set one aggregated state. In am concerned about the scalabillity to large networks. This is due to the N^2 trunk mesh of trunks, where N represents the number of edges in a network. I think it would be good if PCN could support the HOSE model, where no aggregation states are used to model a bandwidth limit. Therefore, I would recommend to look into PCN -extention for HOSE type scenario. comments? -lasse ------=_NextPart_000_0047_01C89643.F21B74C0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Why is PCN only supporting trunk = (ingress-egresss-aggregated) model?
Hi Phil
 
What Lars I think means is that we go forward = using the=20 trunk (ingress-egress-aggregate) model, but
it should also be possible to work on an = experimental=20 RFC that supports the HOSE model.
 
What I = wanted to say=20 is that we sould be able to work on LC-PCN as being an experimental RFC=20
that = provides and=20 supports the HOSE model. Please note that LC-PCN can provide these HOSE=20 features.
 
However, = in order to=20 do that the interior/core node  should be able to support the=20 following features:
 
* possibility to do not preferentially drop = PCN_marked=20 packets. Note that PCN_Affected_marking encoded
   packets can be = dropped.
 
* use the N proportion between marked excess = rate and=20 measured excess rate
 
* provide PCN_Affected_marking encoding and = allow to=20 implement the features that
  are required for=20 PCN_Affedcted_Marking.
 
Best=20 regards,
Georgios
 
 
 

From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: vrijdag 4 april 2008=20 10:22
To: karagian@cs.utwente.nl; = lars.westberg@ericsson.com;=20 pcn@ietf.org
Subject: RE: [PCN] Why is PCN only supporting=20 trunk(ingress-egresss-aggregated)model?

Without = responding to=20 the detail of your msg, I think the important point made by you & = lasse is=20 that you have in mind how to extent PCn to other deployment models. = This is=20 good news – however we should focus on finishing our current = work before we=20 concentrate on extensions.

 

-----Original=20 Message-----
From: = Georgios=20 Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 04 April 2008 = 09:15
To: Eardley,PL,Philip,CXR9 R;=20 lars.westberg@ericsson.com; pcn@ietf.org
Subject: RE: [PCN] Why is PCN = only=20 supporting trunk(ingress-egresss-aggregated)model?

 

Hi=20 Phil

 

The = scalability=20 problem with the trunk model mentioned by Lars is the=20 following.

Suppose = that a=20 network uses 200 ingress/egress edges.

 

In the = worst case the=20 edges will have to maintain the following number of = states:

 

Trunk model = (max=20 number of state per PHB at edges)

----------------

Max. number = of=20 ingress-egress-aggregated states at each ingress: (N-1)=20 =3D 199

Max. number = of=20 ingress-egress-aggregated states at each egress: (N-1)^2 =3D=20  39601

 

 

HOSE model = (max.=20 number of states per PHB at edges)

--------------

Max. = number of=20 per PHB states (instead of ingress-egress-aggregates) at each = ingress:=20 (N-1) =3D 199

Max. number = of per=20 PHB states at each egress: (N-1) =3D  199

 

Regarding flow = termination=20 using EMFT, as it was already emphasized during the IETF meeting,=20

EMFT is too = slow and=20 it will not able to solve the flow termination = accurately.

 

By using = the features=20 that are currently described in LC-PCN for ECMP solution and by using = per PHB=20 aggregated states at the edges,

instead of=20 ingress-egress-aggregated states at the edges then the HOSE model can = work=20 accurately.

 

 

Best=20 regards,

Georgios

 

 

 

From: pcn-bounces@ietf.org = [mailto:pcn-bounces@ietf.org] On Behalf=20 Of philip.eardley@bt.com
Sent: donderdag 3 april 2008=20 17:31
To:=20 lars.westberg@ericsson.com; pcn@ietf.org
Subject: Re: [PCN] Why is PCN = only=20 supporting trunk(ingress-egresss-aggregated)model?

Hi=20 lasse

 

My answer = was only=20 about admission ctrl. Actually I’m not sure I get your = scalability worry –=20 after all, in the pcn architecture doc If the number of edges is = really too=20 high for the ingress to keep track of the pre-congestion level for = all the=20 egresses, then it seems very likely that there’ll be no = current comms=20 between the ingress & many of the egresses, and hence no need to = track=20 that pre-congestion level

 

On the = subject of=20 flow termination ctrl my instinct is that scalability is (even?) = less of a=20 concern. If it really is, then you could go for terminating marked = flows or=20 a subset, as in michael’s EMFT

 

phil

-----Original=20 Message-----
From: Lars=20 Westberg [mailto:lars.westberg@ericsson.com]
Sent: 03 April 2008 = 15:51
To: Eardley,PL,Philip,CXR9 R; = pcn@ietf.org
Subject: RE:=20 [PCN] Why is PCN only supporting trunk=20 (ingress-egresss-aggregated)model?

 

Hi=20 Phil

 

The major = problem=20 is that the egress will notice the congestion if a single = marking=20 scheme is used but I think it may be a problem to calculate the = excess rate.=20

May be = you can=20 check it more in detail.  

 

One of = the reason=20 is of cources that we are thinking of deplyment scenario where = the=20 number of edges are very large and I am worried that the = trunk-approach=20 will impose a limitations in the network=20 design. 

 

-Lasse

 

From: = philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: den 3 april 2008=20 09:51
To: Lars = Westberg;=20 pcn@ietf.org
Subject: RE:=20 [PCN] Why is PCN only supporting trunk=20 (ingress-egresss-aggregated)model?

Lasse

To check: = the hose=20 model would mean that the admission decision is made at each ingress = node,=20 regardless of what egress the traffic is destined to. So, a PCN hose = model=20 would involve each ingress getting congestion reports from every = egress (for=20 traffic from that ingress) and recording them as a collected = (aggregated)=20 value of pre-congestion.

As far as = I know,=20 no-one has looked at this – I don’t think we should = delay current progress=20 by looking at it, since it seems to me a significant change to the=20 conceptual model. But it looks to me like an extension that could = easily be=20 done with the pcn technology described in the architecture draft.=20

phil

 

-----Original=20 Message-----
From:=20 pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars = Westberg
Sent: 03 April 2008 = 06:16
To: pcn@ietf.org
Subject: [PCN] Why is PCN = only=20 supporting trunk = (ingress-egresss-aggregated)model?

 

Hi,
From the PCN=20 architecture draft that I have read and from the discussions that I = have=20 followed I see that PCN is currently only supporting the trunk = aggregation=20 model, where ingress-egreess-aggregated states are used. Thus each = ingress=20 and egress will use per each ingress - egress set one aggregated=20 state.

In am = concerned about=20 the scalabillity to large networks. This is due to=20 the
N^2 trunk mesh = of=20 trunks, where N represents the number of edges in a = network.=20
I think it = would be good=20 if PCN could support the HOSE model, where no aggregation states are = used to=20 model a bandwidth limit. Therefore, I would recommend to look into = PCN=20 -extention for HOSE type scenario.

comments?=20
-lasse=20

------=_NextPart_000_0047_01C89643.F21B74C0-- --===============0959137007== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0959137007==-- From pcn-bounces@ietf.org Fri Apr 4 02:12:26 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC613A69E4; Fri, 4 Apr 2008 02:12:26 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 731B228C3AE for ; Fri, 4 Apr 2008 02:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.757 X-Spam-Level: X-Spam-Status: No, score=-2.757 tagged_above=-999 required=5 tests=[AWL=0.842, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AoI5R8NOuIE for ; Fri, 4 Apr 2008 02:12:23 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 1429528C2F4 for ; Fri, 4 Apr 2008 02:12:22 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 10:12:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 10:12:26 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34702@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <1206983895.3561.12.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Consensus questions: Q4, Q5, and Q6 Thread-Index: AciTU3PfKdKyo6JXRKq11Ro9bcTEBAC1vLGg From: To: , X-OriginalArrivalTime: 04 Apr 2008 09:12:27.0597 (UTC) FILETIME=[00CD27D0:01C89634] Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Steven Blake > Sent: 31 March 2008 18:18 > To: pcn > Subject: [PCN] Consensus questions: Q4, Q5, and Q6 > > Here are the remaining three questions that were taken during the IETF > 71 meeting: > > Q4: Should the standards-track PCN scheme require (as a MUST implement > feature) that interior PCN routers support Excess-Rate marking, > according to the particular method of handling already marked > packets and drops described in Anna Charny's presentation? > http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf yes > > Q5: Should the standards-track PCN scheme require (as a MUST implement > feature) that interior PCN routers support Threshold marking (in > addition to Excess-Rate marking), according to the particular method > described in Philip Eardley's presentation on Tuesday? > http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf yes. I believe that, with a single DSCP (two encoding states, ie not precongested & precongested), it is likely that operators will want to do admission ctrl alone, but with the accuracy achieved by threshold marking (rather than excess rate marking). If it isn't a MUST, then we have configuration complexity of ensuring that all routers are enabled like this. I don't know if there's some other alternative. Perhaps "PCN" have the two MUSTs whereas "PCN lite" would have one MUST (excess rate). Don't know whether this is a good or bad idea. > > Q6: If presented with sufficient evidence in a timely fashion, would > the PCN wg entertain the option of modifying the interior router > Excess-Rate marking behavior for the standards-track PCN scheme (as > described in question 4)? Yes, although it obviously depends what the evidence is! to me 'timely fashion' means before the 00 dublin draft deadline and 'evidence' means a set of simulations with comparisons with at least CL. In the meantime, we should proceed on the assumption that this evidence isn't forthcoming (that was how I understood the discussion in Philadelphia). > > According to the draft meeting minutes, Q4 was accepted 8-0 (my notes > have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0. > > Please send comments to the list during the next few days. > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Apr 4 02:23:29 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEC1A28C0E5; Fri, 4 Apr 2008 02:23:29 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03733A6866 for ; Fri, 4 Apr 2008 02:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_ASCII0=1.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WX4J5wI6jp0 for ; Fri, 4 Apr 2008 02:23:17 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 89F433A67F1 for ; Fri, 4 Apr 2008 02:23:16 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 10:23:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 10:23:19 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34703@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <004601c89633$2e92a4c0$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? Thread-Index: AciVSdFGZ3scO5PmRhKfzH6dBkS3dAAFEgxQAA48TiAAAdWMQAAi8oyAAACdtgAAAUHRcAAAoibA From: To: , , X-OriginalArrivalTime: 04 Apr 2008 09:23:20.0461 (UTC) FILETIME=[85F04BD0:01C89635] Subject: Re: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1257117172==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1257117172== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89635.855625DA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89635.855625DA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I really strongly disagree that we should work on the hose model now. The WG is making slower progress than it should because we keep losing our focus.=20 =20 The hose model hasn't been in our PCN discussions for the last 3 or 4 years. I'm unconvinced it's a good thing to work on even in the future. The normal diffserv architecture (adm ctrl at ingress whatever flow's destination) seems to cover this, and its focussed overload problem was one of the motivations for PCN - and its per ingress-egress pair architecture.=20 Of course, once the PCN work is done ie the current charter is finished, then we can look at what to do next. That surely is the right time to think about extending pcn to other architectures - and having the discussion about whether the hose model is a good thing to do. =20 As regards what features you'd like on the interior nodes, these are points under discussion that having nothing to do with the hose model. They were after all discussed before this recent hose discussion.=20 =20 Phil/=20 =20 -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: 04 April 2008 10:06 To: Eardley,PL,Philip,CXR9 R; lars.westberg@ericsson.com; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? =20 Hi Phil =20 What Lars I think means is that we go forward using the trunk (ingress-egress-aggregate) model, but=20 it should also be possible to work on an experimental RFC that supports the HOSE model. =20 What I wanted to say is that we sould be able to work on LC-PCN as being an experimental RFC=20 that provides and supports the HOSE model. Please note that LC-PCN can provide these HOSE features. =20 However, in order to do that the interior/core node should be able to support the following features: =20 * possibility to do not preferentially drop PCN_marked packets. Note that PCN_Affected_marking encoded=20 packets can be dropped. =20 * use the N proportion between marked excess rate and measured excess rate =20 * provide PCN_Affected_marking encoding and allow to implement the features that=20 are required for PCN_Affedcted_Marking. =20 Best regards, Georgios =20 =20 =20 =20 =09 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: vrijdag 4 april 2008 10:22 To: karagian@cs.utwente.nl; lars.westberg@ericsson.com; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? Without responding to the detail of your msg, I think the important point made by you & lasse is that you have in mind how to extent PCn to other deployment models. This is good news - however we should focus on finishing our current work before we concentrate on extensions. =20 -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: 04 April 2008 09:15 To: Eardley,PL,Philip,CXR9 R; lars.westberg@ericsson.com; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? =20 Hi Phil =20 The scalability problem with the trunk model mentioned by Lars is the following. Suppose that a network uses 200 ingress/egress edges. =20 In the worst case the edges will have to maintain the following number of states: =20 Trunk model (max number of state per PHB at edges) ---------------- Max. number of ingress-egress-aggregated states at each ingress: (N-1) =3D 199 Max. number of ingress-egress-aggregated states at each egress: (N-1)^2 =3D 39601 =20 =20 HOSE model (max. number of states per PHB at edges) -------------- Max. number of per PHB states (instead of ingress-egress-aggregates) at each ingress: (N-1) =3D 199 Max. number of per PHB states at each egress: (N-1) =3D 199 =20 Regarding flow termination using EMFT, as it was already emphasized during the IETF meeting,=20 EMFT is too slow and it will not able to solve the flow termination accurately. =20 By using the features that are currently described in LC-PCN for ECMP solution and by using per PHB aggregated states at the edges,=20 instead of ingress-egress-aggregated states at the edges then the HOSE model can work accurately. =20 =20 Best regards, Georgios =20 =20 =20 =09 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: donderdag 3 april 2008 17:31 To: lars.westberg@ericsson.com; pcn@ietf.org Subject: Re: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? Hi lasse =20 My answer was only about admission ctrl. Actually I'm not sure I get your scalability worry - after all, in the pcn architecture doc If the number of edges is really too high for the ingress to keep track of the pre-congestion level for all the egresses, then it seems very likely that there'll be no current comms between the ingress & many of the egresses, and hence no need to track that pre-congestion level =20 On the subject of flow termination ctrl my instinct is that scalability is (even?) less of a concern. If it really is, then you could go for terminating marked flows or a subset, as in michael's EMFT =20 phil -----Original Message----- From: Lars Westberg [mailto:lars.westberg@ericsson.com]=20 Sent: 03 April 2008 15:51 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? =20 Hi Phil =20 The major problem is that the egress will notice the congestion if a single marking scheme is used but I think it may be a problem to calculate the excess rate.=20 May be you can check it more in detail. =20 =20 One of the reason is of cources that we are thinking of deplyment scenario where the number of edges are very large and I am worried that the trunk-approach will impose a limitations in the network design.=20 =20 -Lasse =20 =09 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: den 3 april 2008 09:51 To: Lars Westberg; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? Lasse To check: the hose model would mean that the admission decision is made at each ingress node, regardless of what egress the traffic is destined to. So, a PCN hose model would involve each ingress getting congestion reports from every egress (for traffic from that ingress) and recording them as a collected (aggregated) value of pre-congestion.=20 As far as I know, no-one has looked at this - I don't think we should delay current progress by looking at it, since it seems to me a significant change to the conceptual model. But it looks to me like an extension that could easily be done with the pcn technology described in the architecture draft.=20 phil =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars Westberg Sent: 03 April 2008 06:16 To: pcn@ietf.org Subject: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? =20 Hi, From the PCN architecture draft that I have read and from the discussions that I have followed I see that PCN is currently only supporting the trunk aggregation model, where ingress-egreess-aggregated states are used. Thus each ingress and egress will use per each ingress - egress set one aggregated state. In am concerned about the scalabillity to large networks. This is due to the N^2 trunk mesh of trunks, where N represents the number of edges in a network.=20 I think it would be good if PCN could support the HOSE model, where no aggregation states are used to model a bandwidth limit. Therefore, I would recommend to look into PCN -extention for HOSE type scenario. comments?=20 -lasse=20 ------_=_NextPart_001_01C89635.855625DA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why is PCN only supporting trunk (ingress-egresss-aggregated) = model?

I really strongly disagree that we = should work on the hose model now. The WG is making slower progress than it should = because we keep losing our focus.

 

The hose model hasn’t been in = our PCN discussions for the last 3 or 4 years. I’m unconvinced = it’s a good thing to work on even in the future. The normal diffserv = architecture (adm ctrl at ingress whatever flow’s destination) seems to cover this, = and its focussed overload problem was one of the motivations for PCN – and = its per ingress-egress pair architecture.

Of course, once the PCN work is = done ie the current charter is finished, then we can look at what to do next. = That surely is the right time to think about extending pcn to other architectures = – and having the discussion about whether the hose model is a good thing = to do.

 

As regards what features = you’d like on the interior nodes, these are points under discussion that having = nothing to do with the hose model. They were after all discussed before this recent = hose discussion.

 

Phil/

 

-----Original Message-----
From: Georgios = Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 04 April 2008 = 10:06
To: = Eardley,PL,Philip,CXR9 R; lars.westberg@ericsson.com; pcn@ietf.org
Subject: RE: [PCN] Why is = PCN only supporting trunk(ingress-egresss-aggregated)model?

 

Hi Phil

 

What Lars I think means is that we = go forward using the trunk (ingress-egress-aggregate) model, but =

it should also be possible to work = on an experimental RFC that supports the HOSE model.

 

What I wanted to say is that we = sould be able to work on LC-PCN as being an experimental RFC

that provides and supports the HOSE = model. Please note that LC-PCN can provide these HOSE = features.

 

However, in order to do that the interior/core node  should be able to support the = following features:

 

* possibility to do not = preferentially drop PCN_marked packets. Note that PCN_Affected_marking encoded =

   packets can be = dropped.

 

* use the N proportion between = marked excess rate and measured excess rate

 

* provide PCN_Affected_marking = encoding and allow to implement the features that

  are required for PCN_Affedcted_Marking.

 

Best regards,

Georgios

 

 

 

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: vrijdag 4 april = 2008 10:22
To: = karagian@cs.utwente.nl; lars.westberg@ericsson.com; pcn@ietf.org
Subject: RE: [PCN] Why is = PCN only supporting trunk(ingress-egresss-aggregated)model?

Without responding to the detail of = your msg, I think the important point made by you & lasse is that you = have in mind how to extent PCn to other deployment models. This is good news = – however we should focus on finishing our current work before we = concentrate on extensions.

 

-----Original Message-----
From: Georgios = Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 04 April 2008 = 09:15
To: = Eardley,PL,Philip,CXR9 R; lars.westberg@ericsson.com; pcn@ietf.org
Subject: RE: [PCN] Why is = PCN only supporting trunk(ingress-egresss-aggregated)model?

 

Hi Phil

 

The scalability problem with the = trunk model mentioned by Lars is the following.

Suppose that a network uses 200 ingress/egress edges.

 

In the worst case the edges will = have to maintain the following number of states:

 

Trunk model (max number of state = per PHB at edges)

----------------

Max. number of = ingress-egress-aggregated states at each ingress: (N-1) =3D 199

Max. number of = ingress-egress-aggregated states at each egress: (N-1)^2 =3D  39601

 

 

HOSE model (max. number of states = per PHB at edges)

--------------

Max. number of per = PHB states (instead of ingress-egress-aggregates) at each ingress: (N-1) = =3D 199

Max. number of per PHB states at = each egress: (N-1) =3D  199

 

Regarding flow termination using EMFT, as it was already emphasized = during the IETF meeting,

EMFT is too slow and it will not = able to solve the flow termination accurately.

 

By using the features that are = currently described in LC-PCN for ECMP solution and by using per PHB aggregated = states at the edges,

instead of = ingress-egress-aggregated states at the edges then the HOSE model can work = accurately.

 

 

Best regards,

Georgios

 

 

 

From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: donderdag 3 april = 2008 17:31
To: = lars.westberg@ericsson.com; pcn@ietf.org
Subject: Re: [PCN] Why is = PCN only supporting trunk(ingress-egresss-aggregated)model?

Hi lasse

 

My answer was only about admission = ctrl. Actually I’m not sure I get your scalability worry – after = all, in the pcn architecture doc If the number of edges is really too high for = the ingress to keep track of the pre-congestion level for all the egresses, = then it seems very likely that there’ll be no current comms between the = ingress & many of the egresses, and hence no need to track that = pre-congestion level

 

On the subject of flow termination = ctrl my instinct is that scalability is (even?) less of a concern. If it really = is, then you could go for terminating marked flows or a subset, as in michael’s EMFT

 

phil

-----Original Message-----
From: Lars Westberg [mailto:lars.westberg@ericsson.com]
Sent: 03 April 2008 = 15:51
To: = Eardley,PL,Philip,CXR9 R; pcn@ietf.org
Subject: RE: [PCN] Why is = PCN only supporting trunk (ingress-egresss-aggregated)model?

 

Hi Phil

 

The major problem is that the = egress will notice the congestion if a single marking scheme is used but I think = it may be a problem to calculate the excess rate.

May be you can check it more in = detail.  

 

One of the reason is of cources = that we are thinking of deplyment scenario where the number of edges are = very large and I am worried that the trunk-approach will impose a limitations in the network design. 

 

-Lasse

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: den 3 april 2008 = 09:51
To: Lars Westberg; = pcn@ietf.org
Subject: RE: [PCN] Why is = PCN only supporting trunk (ingress-egresss-aggregated)model?

Lasse

To check: the hose model would mean = that the admission decision is made at each ingress node, regardless of what = egress the traffic is destined to. So, a PCN hose model would involve each = ingress getting congestion reports from every egress (for traffic from that = ingress) and recording them as a collected (aggregated) value of pre-congestion. =

As far as I know, no-one has looked = at this – I don’t think we should delay current progress by = looking at it, since it seems to me a significant change to the conceptual model. = But it looks to me like an extension that could easily be done with the pcn = technology described in the architecture draft.

phil

 

-----Original Message-----
From: = pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = Behalf Of Lars Westberg
Sent: 03 April 2008 = 06:16
To: pcn@ietf.org
Subject: [PCN] Why is PCN = only supporting trunk (ingress-egresss-aggregated)model?

 

Hi,
From the PCN architecture draft that I have read and from the discussions = that I have followed I see that PCN is currently only supporting the trunk = aggregation model, where ingress-egreess-aggregated states are used. Thus each = ingress and egress will use per each ingress - egress set one aggregated = state.

In am concerned about the scalabillity to large networks. = This is due to the
N^2 trunk mesh of trunks, where N represents the number of edges in a = network.
I think it would be good if PCN could support the HOSE model, where no = aggregation states are used to model a bandwidth limit. Therefore, I would recommend = to look into PCN -extention for HOSE type scenario.

comments?
-lasse

=00 ------_=_NextPart_001_01C89635.855625DA-- --===============1257117172== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1257117172==-- From pcn-bounces@ietf.org Fri Apr 4 03:08:55 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 074C93A6B33; Fri, 4 Apr 2008 03:08:55 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6040B3A690F for ; Fri, 4 Apr 2008 03:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.273 X-Spam-Level: * X-Spam-Status: No, score=1.273 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFUAsw5Ko-g8 for ; Fri, 4 Apr 2008 03:08:41 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id B6C873A6B33 for ; Fri, 4 Apr 2008 03:08:40 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m34A8Zup026309; Fri, 4 Apr 2008 12:08:42 +0200 (MEST) From: "Georgios Karagiannis" To: , , References: <004601c89633$2e92a4c0$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B34703@E03MVZ1-UKDY.domain1.systemhost.net> Date: Fri, 4 Apr 2008 12:08:29 +0200 Message-ID: <006501c8963b$da6777f0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34703@E03MVZ1-UKDY.domain1.systemhost.net> Thread-Index: AciVSdFGZ3scO5PmRhKfzH6dBkS3dAAFEgxQAA48TiAAAdWMQAAi8oyAAACdtgAAAUHRcAAAoibAAAGMweA= X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 04 Apr 2008 12:08:44 +0200 (MEST) Subject: Re: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2042630968==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============2042630968== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0066_01C8964C.9DF047F0" This is a multi-part message in MIME format. ------=_NextPart_000_0066_01C8964C.9DF047F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Phil Please note that HOSE model is not out of the scope of the PCN charter. The PCN charter is not in favour of the trunk (pipe) or the HOSE model. Therefore, I do not think that PCN rechartering is needed for this purpose. Of course we can all work on the short term to finalise the standard PCN solution. However, what I would like to see now (in the short term) is that the interior/core router should provide the possibilities and features to use the HOSE model. Note that the following features when supported can provide solutions to two issues. Solution to the HOSE model and to the ECMP problem. I think therefore, that these features are really providing an added value to both SM and CL-PHB schemes. The required features in the interior/core are: * possibility to do not preferentially drop PCN_marked packets. Note that PCN_Affected_marking encoded packets can be dropped. * use the N proportion between marked excess rate and measured excess rate * provide PCN_Affected_marking encoding and allow to implement the features that are required for PCN_Affedcted_Marking. Best regards, Georgios _____ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: vrijdag 4 april 2008 11:23 To: karagian@cs.utwente.nl; lars.westberg@ericsson.com; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? I really strongly disagree that we should work on the hose model now. The WG is making slower progress than it should because we keep losing our focus. The hose model hasn't been in our PCN discussions for the last 3 or 4 years. I'm unconvinced it's a good thing to work on even in the future. The normal diffserv architecture (adm ctrl at ingress whatever flow's destination) seems to cover this, and its focussed overload problem was one of the motivations for PCN - and its per ingress-egress pair architecture. Of course, once the PCN work is done ie the current charter is finished, then we can look at what to do next. That surely is the right time to think about extending pcn to other architectures - and having the discussion about whether the hose model is a good thing to do. As regards what features you'd like on the interior nodes, these are points under discussion that having nothing to do with the hose model. They were after all discussed before this recent hose discussion. Phil/ -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] Sent: 04 April 2008 10:06 To: Eardley,PL,Philip,CXR9 R; lars.westberg@ericsson.com; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? Hi Phil What Lars I think means is that we go forward using the trunk (ingress-egress-aggregate) model, but it should also be possible to work on an experimental RFC that supports the HOSE model. What I wanted to say is that we sould be able to work on LC-PCN as being an experimental RFC that provides and supports the HOSE model. Please note that LC-PCN can provide these HOSE features. However, in order to do that the interior/core node should be able to support the following features: * possibility to do not preferentially drop PCN_marked packets. Note that PCN_Affected_marking encoded packets can be dropped. * use the N proportion between marked excess rate and measured excess rate * provide PCN_Affected_marking encoding and allow to implement the features that are required for PCN_Affedcted_Marking. Best regards, Georgios _____ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: vrijdag 4 april 2008 10:22 To: karagian@cs.utwente.nl; lars.westberg@ericsson.com; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? Without responding to the detail of your msg, I think the important point made by you & lasse is that you have in mind how to extent PCn to other deployment models. This is good news - however we should focus on finishing our current work before we concentrate on extensions. -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] Sent: 04 April 2008 09:15 To: Eardley,PL,Philip,CXR9 R; lars.westberg@ericsson.com; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? Hi Phil The scalability problem with the trunk model mentioned by Lars is the following. Suppose that a network uses 200 ingress/egress edges. In the worst case the edges will have to maintain the following number of states: Trunk model (max number of state per PHB at edges) ---------------- Max. number of ingress-egress-aggregated states at each ingress: (N-1) = 199 Max. number of ingress-egress-aggregated states at each egress: (N-1)^2 = 39601 HOSE model (max. number of states per PHB at edges) -------------- Max. number of per PHB states (instead of ingress-egress-aggregates) at each ingress: (N-1) = 199 Max. number of per PHB states at each egress: (N-1) = 199 Regarding flow termination using EMFT, as it was already emphasized during the IETF meeting, EMFT is too slow and it will not able to solve the flow termination accurately. By using the features that are currently described in LC-PCN for ECMP solution and by using per PHB aggregated states at the edges, instead of ingress-egress-aggregated states at the edges then the HOSE model can work accurately. Best regards, Georgios _____ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: donderdag 3 april 2008 17:31 To: lars.westberg@ericsson.com; pcn@ietf.org Subject: Re: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? Hi lasse My answer was only about admission ctrl. Actually I'm not sure I get your scalability worry - after all, in the pcn architecture doc If the number of edges is really too high for the ingress to keep track of the pre-congestion level for all the egresses, then it seems very likely that there'll be no current comms between the ingress & many of the egresses, and hence no need to track that pre-congestion level On the subject of flow termination ctrl my instinct is that scalability is (even?) less of a concern. If it really is, then you could go for terminating marked flows or a subset, as in michael's EMFT phil -----Original Message----- From: Lars Westberg [mailto:lars.westberg@ericsson.com] Sent: 03 April 2008 15:51 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? Hi Phil The major problem is that the egress will notice the congestion if a single marking scheme is used but I think it may be a problem to calculate the excess rate. May be you can check it more in detail. One of the reason is of cources that we are thinking of deplyment scenario where the number of edges are very large and I am worried that the trunk-approach will impose a limitations in the network design. -Lasse _____ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: den 3 april 2008 09:51 To: Lars Westberg; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? Lasse To check: the hose model would mean that the admission decision is made at each ingress node, regardless of what egress the traffic is destined to. So, a PCN hose model would involve each ingress getting congestion reports from every egress (for traffic from that ingress) and recording them as a collected (aggregated) value of pre-congestion. As far as I know, no-one has looked at this - I don't think we should delay current progress by looking at it, since it seems to me a significant change to the conceptual model. But it looks to me like an extension that could easily be done with the pcn technology described in the architecture draft. phil -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars Westberg Sent: 03 April 2008 06:16 To: pcn@ietf.org Subject: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? Hi, From the PCN architecture draft that I have read and from the discussions that I have followed I see that PCN is currently only supporting the trunk aggregation model, where ingress-egreess-aggregated states are used. Thus each ingress and egress will use per each ingress - egress set one aggregated state. In am concerned about the scalabillity to large networks. This is due to the N^2 trunk mesh of trunks, where N represents the number of edges in a network. I think it would be good if PCN could support the HOSE model, where no aggregation states are used to model a bandwidth limit. Therefore, I would recommend to look into PCN -extention for HOSE type scenario. comments? -lasse ------=_NextPart_000_0066_01C8964C.9DF047F0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Why is PCN only supporting trunk = (ingress-egresss-aggregated) model?
Hi Phil
 
Please note that HOSE model is not out of the = scope of the=20 PCN charter. The PCN charter is
not in favour of the trunk (pipe) or the HOSE = model.=20 Therefore, I do not think that
PCN rechartering is needed for this=20 purpose.
 
Of course we can all work on the short term to = finalise the=20 standard PCN solution.
 
However, what I would like to see now (in = the short=20 term)
is that the interior/core router should provide = the=20 possibilities and features to use the HOSE model.
 
Note that the following features when supported = can provide=20 solutions to two issues. Solution to the HOSE model
and to the ECMP problem.
I think therefore, that these features are = really providing=20 an added value to both SM and CL-PHB schemes.
 
The required features in the interior/core=20 are:
 
 * possibility to do not preferentially = drop=20 PCN_marked packets. Note that PCN_Affected_marking encoded

   = packets=20 can be dropped.

 

* use the N = proportion=20 between marked excess rate and measured excess rate

 

* provide=20 PCN_Affected_marking encoding and allow to implement the features that=20

  are = required for=20 PCN_Affedcted_Marking.

 

Best regards,

Georgios

 

 
 
 
 
 

From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: vrijdag 4 april 2008=20 11:23
To: karagian@cs.utwente.nl; = lars.westberg@ericsson.com;=20 pcn@ietf.org
Subject: RE: [PCN] Why is PCN only supporting=20 trunk(ingress-egresss-aggregated)model?

I really = strongly=20 disagree that we should work on the hose model now. The WG is making = slower=20 progress than it should because we keep losing our focus. =

 

The hose = model hasn’t=20 been in our PCN discussions for the last 3 or 4 years. I’m = unconvinced it’s a=20 good thing to work on even in the future. The normal diffserv = architecture=20 (adm ctrl at ingress whatever flow’s destination) seems to cover = this, and its=20 focussed overload problem was one of the motivations for PCN – = and its per=20 ingress-egress pair architecture.

Of course, = once the=20 PCN work is done ie the current charter is finished, then we can look = at what=20 to do next. That surely is the right time to think about extending pcn = to=20 other architectures – and having the discussion about whether = the hose model=20 is a good thing to do.

 

As regards = what=20 features you’d like on the interior nodes, these are points = under discussion=20 that having nothing to do with the hose model. They were after all = discussed=20 before this recent hose discussion.

 

Phil/=20

 

-----Original=20 Message-----
From: = Georgios=20 Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 04 April 2008 = 10:06
To: Eardley,PL,Philip,CXR9 R;=20 lars.westberg@ericsson.com; pcn@ietf.org
Subject: RE: [PCN] Why is PCN = only=20 supporting trunk(ingress-egresss-aggregated)model?

 

Hi=20 Phil

 

What Lars I = think=20 means is that we go forward using the trunk (ingress-egress-aggregate) = model,=20 but

it should = also be=20 possible to work on an experimental RFC that supports the HOSE=20 model.

 

What I = wanted to say=20 is that we sould be able to work on LC-PCN as being an experimental = RFC=20

that = provides and=20 supports the HOSE model. Please note that LC-PCN can provide these = HOSE=20 features.

 

However, in = order to=20 do that the interior/core node  should be able to support = the=20 following features:

 

* = possibility to do=20 not preferentially drop PCN_marked packets. Note that = PCN_Affected_marking=20 encoded

   packets=20 can be dropped.

 

* use the N = proportion between marked excess rate and measured excess=20 rate

 

* provide=20 PCN_Affected_marking encoding and allow to implement the features that =

  are = required=20 for PCN_Affedcted_Marking.

 

Best=20 regards,

Georgios

 

 

 

 

From: = philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: vrijdag 4 april 2008=20 10:22
To:=20 karagian@cs.utwente.nl; lars.westberg@ericsson.com; = pcn@ietf.org
Subject: RE: [PCN] Why is PCN = only=20 supporting trunk(ingress-egresss-aggregated)model?

Without = responding=20 to the detail of your msg, I think the important point made by you = &=20 lasse is that you have in mind how to extent PCn to other deployment = models.=20 This is good news – however we should focus on finishing our = current work=20 before we concentrate on extensions.

 

-----Original=20 Message-----
From: Georgios=20 Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 04 April 2008 = 09:15
To: Eardley,PL,Philip,CXR9 R; = lars.westberg@ericsson.com; pcn@ietf.org
Subject: RE: [PCN] Why is PCN = only=20 supporting trunk(ingress-egresss-aggregated)model?

 

Hi=20 Phil

 

The = scalability=20 problem with the trunk model mentioned by Lars is the=20 following.

Suppose = that a=20 network uses 200 ingress/egress edges.

 

In the = worst case=20 the edges will have to maintain the following number of=20 states:

 

Trunk = model (max=20 number of state per PHB at edges)

----------------

Max. = number of=20 ingress-egress-aggregated states at each ingress: (N-1)=20 =3D 199

Max. = number of=20 ingress-egress-aggregated states at each egress: (N-1)^2 =3D=20  39601

 

 

HOSE = model (max.=20 number of states per PHB at edges)

--------------

Max. = number of=20 per PHB states (instead of ingress-egress-aggregates) at each = ingress:=20 (N-1) =3D 199

Max. = number of per=20 PHB states at each egress: (N-1) = =3D  199

 

Regarding flow = termination=20 using EMFT, as it was already emphasized during the IETF meeting,=20

EMFT is = too slow=20 and it will not able to solve the flow termination=20 accurately.

 

By using = the=20 features that are currently described in LC-PCN for ECMP solution = and by=20 using per PHB aggregated states at the edges,

instead = of=20 ingress-egress-aggregated states at the edges then the HOSE model = can work=20 accurately.

 

 

Best=20 regards,

Georgios

 

 

 

From: = pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf=20 Of philip.eardley@bt.com
Sent: donderdag 3 april = 2008=20 17:31
To:=20 lars.westberg@ericsson.com; pcn@ietf.org
Subject: Re: [PCN] Why is = PCN only=20 supporting = trunk(ingress-egresss-aggregated)model?

Hi=20 lasse

 

My = answer was=20 only about admission ctrl. Actually I’m not sure I get your = scalability=20 worry – after all, in the pcn architecture doc If the number = of edges is=20 really too high for the ingress to keep track of the = pre-congestion level=20 for all the egresses, then it seems very likely that = there’ll be no=20 current comms between the ingress & many of the egresses, and = hence no=20 need to track that pre-congestion level

 

On the = subject of=20 flow termination ctrl my instinct is that scalability is (even?) = less of a=20 concern. If it really is, then you could go for terminating marked = flows=20 or a subset, as in michael’s EMFT

 

phil

-----Original=20 Message-----
From: Lars=20 Westberg [mailto:lars.westberg@ericsson.com]
Sent: 03 April 2008 = 15:51
To: Eardley,PL,Philip,CXR9 = R;=20 pcn@ietf.org
Subject: RE:=20 [PCN] Why is PCN only supporting trunk=20 (ingress-egresss-aggregated)model?

 

Hi=20 Phil

 

The = major problem=20 is that the egress will notice the congestion if = a single=20 marking scheme is used but I think it may be a problem to = calculate the=20 excess rate.

May be = you can=20 check it more in detail.  

 

One of = the reason=20 is of cources that we are thinking of deplyment scenario = where the=20 number of edges are very large and I am worried that the=20 trunk-approach will impose a limitations in the network=20 design. 

 

-Lasse

 

From: = philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: den 3 april 2008=20 09:51
To: Lars = Westberg;=20 pcn@ietf.org
Subject: RE:=20 [PCN] Why is PCN only supporting trunk=20 (ingress-egresss-aggregated)model?

Lasse

To = check: the=20 hose model would mean that the admission decision is made at each = ingress=20 node, regardless of what egress the traffic is destined to. So, a = PCN hose=20 model would involve each ingress getting congestion reports from = every=20 egress (for traffic from that ingress) and recording them as a = collected=20 (aggregated) value of pre-congestion.

As far = as I know,=20 no-one has looked at this – I don’t think we should = delay current progress=20 by looking at it, since it seems to me a significant change to the = conceptual model. But it looks to me like an extension that could = easily=20 be done with the pcn technology described in the architecture = draft.=20

phil

 

-----Original=20 Message-----
From:=20 pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars=20 Westberg
Sent: = 03 April=20 2008 06:16
To:=20 pcn@ietf.org
Subject:=20 [PCN] Why is PCN only supporting trunk=20 (ingress-egresss-aggregated)model?

 

Hi,
From the PCN = architecture draft that I have read and from the discussions that = I have=20 followed I see that PCN is currently only supporting the trunk = aggregation=20 model, where ingress-egreess-aggregated states are used. Thus each = ingress=20 and egress will use per each ingress - egress set one aggregated=20 state.

In am = concerned about=20 the scalabillity to large networks. This is due to=20 the
N^2 trunk = mesh of=20 trunks, where N represents the number of edges in a = network.=20
I think it = would be=20 good if PCN could support the HOSE model, where no aggregation = states are=20 used to model a bandwidth limit. Therefore, I would recommend to = look into=20 PCN -extention for HOSE type scenario.

comments?=20
-lasse=20 =

= ------=_NextPart_000_0066_01C8964C.9DF047F0-- --===============2042630968== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============2042630968==-- From pcn-bounces@ietf.org Fri Apr 4 03:34:05 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BFA13A6A02; Fri, 4 Apr 2008 03:34:05 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 680A23A6A02 for ; Fri, 4 Apr 2008 03:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.166 X-Spam-Level: X-Spam-Status: No, score=-1.166 tagged_above=-999 required=5 tests=[AWL=-0.908, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_ASCII0=1.5, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBfc9xx5ZdIw for ; Fri, 4 Apr 2008 03:33:48 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 4CF5C3A63EC for ; Fri, 4 Apr 2008 03:33:46 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 11:33:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 11:33:50 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34707@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <006501c8963b$da6777f0$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? Thread-Index: AciVSdFGZ3scO5PmRhKfzH6dBkS3dAAFEgxQAA48TiAAAdWMQAAi8oyAAACdtgAAAUHRcAAAoibAAAGMweAAAS9TYA== From: To: , , X-OriginalArrivalTime: 04 Apr 2008 10:33:51.0509 (UTC) FILETIME=[5FD6FC50:01C8963F] Subject: Re: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0081463391==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0081463391== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8963F.5F2ADD82" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8963F.5F2ADD82 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Excellent, let's continue having these discussions about the interior node's behaviour without referring to the hose model.=20 =20 -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: 04 April 2008 11:08 To: Eardley,PL,Philip,CXR9 R; lars.westberg@ericsson.com; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? =20 Hi Phil =20 Please note that HOSE model is not out of the scope of the PCN charter. The PCN charter is=20 not in favour of the trunk (pipe) or the HOSE model. Therefore, I do not think that=20 PCN rechartering is needed for this purpose. =20 Of course we can all work on the short term to finalise the standard PCN solution. =20 However, what I would like to see now (in the short term) is that the interior/core router should provide the possibilities and features to use the HOSE model. =20 Note that the following features when supported can provide solutions to two issues. Solution to the HOSE model=20 and to the ECMP problem. I think therefore, that these features are really providing an added value to both SM and CL-PHB schemes. =20 The required features in the interior/core are: =20 * possibility to do not preferentially drop PCN_marked packets. Note that PCN_Affected_marking encoded=20 packets can be dropped. =20 * use the N proportion between marked excess rate and measured excess rate =20 * provide PCN_Affected_marking encoding and allow to implement the features that=20 are required for PCN_Affedcted_Marking. =20 Best regards, Georgios =20 =20 =20 =20 =20 =20 =20 =09 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: vrijdag 4 april 2008 11:23 To: karagian@cs.utwente.nl; lars.westberg@ericsson.com; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? I really strongly disagree that we should work on the hose model now. The WG is making slower progress than it should because we keep losing our focus.=20 =20 The hose model hasn't been in our PCN discussions for the last 3 or 4 years. I'm unconvinced it's a good thing to work on even in the future. The normal diffserv architecture (adm ctrl at ingress whatever flow's destination) seems to cover this, and its focussed overload problem was one of the motivations for PCN - and its per ingress-egress pair architecture.=20 Of course, once the PCN work is done ie the current charter is finished, then we can look at what to do next. That surely is the right time to think about extending pcn to other architectures - and having the discussion about whether the hose model is a good thing to do. =20 As regards what features you'd like on the interior nodes, these are points under discussion that having nothing to do with the hose model. They were after all discussed before this recent hose discussion. =20 Phil/=20 =20 -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: 04 April 2008 10:06 To: Eardley,PL,Philip,CXR9 R; lars.westberg@ericsson.com; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? =20 Hi Phil =20 What Lars I think means is that we go forward using the trunk (ingress-egress-aggregate) model, but=20 it should also be possible to work on an experimental RFC that supports the HOSE model. =20 What I wanted to say is that we sould be able to work on LC-PCN as being an experimental RFC=20 that provides and supports the HOSE model. Please note that LC-PCN can provide these HOSE features. =20 However, in order to do that the interior/core node should be able to support the following features: =20 * possibility to do not preferentially drop PCN_marked packets. Note that PCN_Affected_marking encoded=20 packets can be dropped. =20 * use the N proportion between marked excess rate and measured excess rate =20 * provide PCN_Affected_marking encoding and allow to implement the features that=20 are required for PCN_Affedcted_Marking. =20 Best regards, Georgios =20 =20 =20 =20 =09 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: vrijdag 4 april 2008 10:22 To: karagian@cs.utwente.nl; lars.westberg@ericsson.com; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? Without responding to the detail of your msg, I think the important point made by you & lasse is that you have in mind how to extent PCn to other deployment models. This is good news - however we should focus on finishing our current work before we concentrate on extensions. =20 -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: 04 April 2008 09:15 To: Eardley,PL,Philip,CXR9 R; lars.westberg@ericsson.com; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? =20 Hi Phil =20 The scalability problem with the trunk model mentioned by Lars is the following. Suppose that a network uses 200 ingress/egress edges. =20 In the worst case the edges will have to maintain the following number of states: =20 Trunk model (max number of state per PHB at edges) ---------------- Max. number of ingress-egress-aggregated states at each ingress: (N-1) =3D 199 Max. number of ingress-egress-aggregated states at each egress: (N-1)^2 =3D 39601 =20 =20 HOSE model (max. number of states per PHB at edges) -------------- Max. number of per PHB states (instead of ingress-egress-aggregates) at each ingress: (N-1) =3D 199 Max. number of per PHB states at each egress: (N-1) =3D 199 =20 Regarding flow termination using EMFT, as it was already emphasized during the IETF meeting,=20 EMFT is too slow and it will not able to solve the flow termination accurately. =20 By using the features that are currently described in LC-PCN for ECMP solution and by using per PHB aggregated states at the edges,=20 instead of ingress-egress-aggregated states at the edges then the HOSE model can work accurately. =20 =20 Best regards, Georgios =20 =20 =20 =09 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: donderdag 3 april 2008 17:31 To: lars.westberg@ericsson.com; pcn@ietf.org Subject: Re: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? Hi lasse =20 My answer was only about admission ctrl. Actually I'm not sure I get your scalability worry - after all, in the pcn architecture doc If the number of edges is really too high for the ingress to keep track of the pre-congestion level for all the egresses, then it seems very likely that there'll be no current comms between the ingress & many of the egresses, and hence no need to track that pre-congestion level =20 On the subject of flow termination ctrl my instinct is that scalability is (even?) less of a concern. If it really is, then you could go for terminating marked flows or a subset, as in michael's EMFT =20 phil -----Original Message----- From: Lars Westberg [mailto:lars.westberg@ericsson.com]=20 Sent: 03 April 2008 15:51 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? =20 Hi Phil =20 The major problem is that the egress will notice the congestion if a single marking scheme is used but I think it may be a problem to calculate the excess rate.=20 May be you can check it more in detail. =20 =20 One of the reason is of cources that we are thinking of deplyment scenario where the number of edges are very large and I am worried that the trunk-approach will impose a limitations in the network design.=20 =20 -Lasse =20 =09 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: den 3 april 2008 09:51 To: Lars Westberg; pcn@ietf.org Subject: RE: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? Lasse To check: the hose model would mean that the admission decision is made at each ingress node, regardless of what egress the traffic is destined to. So, a PCN hose model would involve each ingress getting congestion reports from every egress (for traffic from that ingress) and recording them as a collected (aggregated) value of pre-congestion.=20 As far as I know, no-one has looked at this - I don't think we should delay current progress by looking at it, since it seems to me a significant change to the conceptual model. But it looks to me like an extension that could easily be done with the pcn technology described in the architecture draft.=20 phil =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars Westberg Sent: 03 April 2008 06:16 To: pcn@ietf.org Subject: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated)model? =20 Hi, From the PCN architecture draft that I have read and from the discussions that I have followed I see that PCN is currently only supporting the trunk aggregation model, where ingress-egreess-aggregated states are used. Thus each ingress and egress will use per each ingress - egress set one aggregated state. In am concerned about the scalabillity to large networks. This is due to the N^2 trunk mesh of trunks, where N represents the number of edges in a network.=20 I think it would be good if PCN could support the HOSE model, where no aggregation states are used to model a bandwidth limit. Therefore, I would recommend to look into PCN -extention for HOSE type scenario. comments?=20 -lasse=20 ------_=_NextPart_001_01C8963F.5F2ADD82 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why is PCN only supporting trunk (ingress-egresss-aggregated) = model?

Excellent, let’s continue = having these discussions about the interior node’s behaviour without = referring to the hose model.

 

-----Original Message-----
From: Georgios = Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 04 April 2008 = 11:08
To: = Eardley,PL,Philip,CXR9 R; lars.westberg@ericsson.com; pcn@ietf.org
Subject: RE: [PCN] Why is = PCN only supporting trunk(ingress-egresss-aggregated)model?

 

Hi Phil

 

Please note that HOSE model is not = out of the scope of the PCN charter. The PCN charter is

not in favour of the trunk (pipe) = or the HOSE model. Therefore, I do not think that

PCN rechartering is needed for this purpose.

 

Of course we can all work on the = short term to finalise the standard PCN solution.

 

However, what I would like to = see now (in the short term)

is that the interior/core router = should provide the possibilities and features to use the HOSE = model.

 

Note that the following features = when supported can provide solutions to two issues. Solution to the HOSE = model

and to the ECMP = problem.

I think therefore, that these = features are really providing an added value to both SM and CL-PHB = schemes.

 

The required features in the = interior/core are:

 

 * possibility to do not preferentially drop PCN_marked packets. Note that PCN_Affected_marking = encoded

   packets can be = dropped.

 

* use the N proportion between = marked excess rate and measured excess rate

 

* provide PCN_Affected_marking = encoding and allow to implement the features that

  are required for PCN_Affedcted_Marking.

 

Best regards,

Georgios

 

 

 

 

 

 

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: vrijdag 4 april = 2008 11:23
To: = karagian@cs.utwente.nl; lars.westberg@ericsson.com; pcn@ietf.org
Subject: RE: [PCN] Why is = PCN only supporting trunk(ingress-egresss-aggregated)model?

I really strongly disagree that we = should work on the hose model now. The WG is making slower progress than it = should because we keep losing our focus.

 

The hose model hasn’t been in = our PCN discussions for the last 3 or 4 years. I’m unconvinced = it’s a good thing to work on even in the future. The normal diffserv = architecture (adm ctrl at ingress whatever flow’s destination) seems to cover this, = and its focussed overload problem was one of the motivations for PCN – and = its per ingress-egress pair architecture.

Of course, once the PCN work is = done ie the current charter is finished, then we can look at what to do next. = That surely is the right time to think about extending pcn to other = architectures – and having the discussion about whether the hose model is a good = thing to do.

 

As regards what features = you’d like on the interior nodes, these are points under discussion that having = nothing to do with the hose model. They were after all discussed before this recent = hose discussion.

 

Phil/

 

-----Original Message-----
From: Georgios = Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 04 April 2008 = 10:06
To: = Eardley,PL,Philip,CXR9 R; lars.westberg@ericsson.com; pcn@ietf.org
Subject: RE: [PCN] Why is = PCN only supporting trunk(ingress-egresss-aggregated)model?

 

Hi Phil

 

What Lars I think means is that we = go forward using the trunk (ingress-egress-aggregate) model, but =

it should also be possible to work = on an experimental RFC that supports the HOSE model.

 

What I wanted to say is that we = sould be able to work on LC-PCN as being an experimental RFC

that provides and supports the HOSE = model. Please note that LC-PCN can provide these HOSE = features.

 

However, in order to do that the interior/core node  should be able to support the = following features:

 

* possibility to do not = preferentially drop PCN_marked packets. Note that PCN_Affected_marking encoded =

   packets can be = dropped.

 

* use the N proportion between = marked excess rate and measured excess rate

 

* provide PCN_Affected_marking = encoding and allow to implement the features that

  are required for PCN_Affedcted_Marking.

 

Best regards,

Georgios

 

 

 

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: vrijdag 4 april = 2008 10:22
To: = karagian@cs.utwente.nl; lars.westberg@ericsson.com; pcn@ietf.org
Subject: RE: [PCN] Why is = PCN only supporting trunk(ingress-egresss-aggregated)model?

Without responding to the detail of = your msg, I think the important point made by you & lasse is that you = have in mind how to extent PCn to other deployment models. This is good news = – however we should focus on finishing our current work before we = concentrate on extensions.

 

-----Original Message-----
From: Georgios = Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 04 April 2008 = 09:15
To: = Eardley,PL,Philip,CXR9 R; lars.westberg@ericsson.com; pcn@ietf.org
Subject: RE: [PCN] Why is = PCN only supporting trunk(ingress-egresss-aggregated)model?

 

Hi Phil

 

The scalability problem with the = trunk model mentioned by Lars is the following.

Suppose that a network uses 200 ingress/egress edges.

 

In the worst case the edges will = have to maintain the following number of states:

 

Trunk model (max number of state = per PHB at edges)

----------------

Max. number of = ingress-egress-aggregated states at each ingress: (N-1) =3D 199

Max. number of = ingress-egress-aggregated states at each egress: (N-1)^2 =3D  39601

 

 

HOSE model (max. number of states = per PHB at edges)

--------------

Max. number of per = PHB states (instead of ingress-egress-aggregates) at each ingress: (N-1) = =3D 199

Max. number of per PHB states at = each egress: (N-1) =3D  199

 

Regarding flow termination using EMFT, as it was already emphasized = during the IETF meeting,

EMFT is too slow and it will not = able to solve the flow termination accurately.

 

By using the features that are = currently described in LC-PCN for ECMP solution and by using per PHB aggregated = states at the edges,

instead of = ingress-egress-aggregated states at the edges then the HOSE model can work = accurately.

 

 

Best regards,

Georgios

 

 

 

From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: donderdag 3 april = 2008 17:31
To: = lars.westberg@ericsson.com; pcn@ietf.org
Subject: Re: [PCN] Why is = PCN only supporting trunk(ingress-egresss-aggregated)model?

Hi lasse

 

My answer was only about admission = ctrl. Actually I’m not sure I get your scalability worry – after = all, in the pcn architecture doc If the number of edges is really too high for = the ingress to keep track of the pre-congestion level for all the egresses, = then it seems very likely that there’ll be no current comms between the = ingress & many of the egresses, and hence no need to track that = pre-congestion level

 

On the subject of flow termination = ctrl my instinct is that scalability is (even?) less of a concern. If it really = is, then you could go for terminating marked flows or a subset, as in michael’s EMFT

 

phil

-----Original Message-----
From: Lars Westberg [mailto:lars.westberg@ericsson.com]
Sent: 03 April 2008 = 15:51
To: = Eardley,PL,Philip,CXR9 R; pcn@ietf.org
Subject: RE: [PCN] Why is = PCN only supporting trunk (ingress-egresss-aggregated)model?

 

Hi Phil

 

The major problem is that the = egress will notice the congestion if a single marking scheme is used but I = think it may be a problem to calculate the excess rate.

May be you can check it more in = detail.  

 

One of the reason is of cources = that we are thinking of deplyment scenario where the number of edges are = very large and I am worried that the trunk-approach will impose a limitations in the network design. 

 

-Lasse

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: den 3 april 2008 = 09:51
To: Lars Westberg; = pcn@ietf.org
Subject: RE: [PCN] Why is = PCN only supporting trunk (ingress-egresss-aggregated)model?

Lasse

To check: the hose model would mean = that the admission decision is made at each ingress node, regardless of what = egress the traffic is destined to. So, a PCN hose model would involve each = ingress getting congestion reports from every egress (for traffic from that = ingress) and recording them as a collected (aggregated) value of pre-congestion. =

As far as I know, no-one has looked = at this – I don’t think we should delay current progress by = looking at it, since it seems to me a significant change to the conceptual model. = But it looks to me like an extension that could easily be done with the pcn = technology described in the architecture draft.

phil

 

-----Original Message-----
From: = pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = Behalf Of Lars Westberg
Sent: 03 April 2008 = 06:16
To: pcn@ietf.org
Subject: [PCN] Why is PCN = only supporting trunk (ingress-egresss-aggregated)model?

 

Hi,
From the PCN architecture draft that I have read and from the discussions = that I have followed I see that PCN is currently only supporting the trunk = aggregation model, where ingress-egreess-aggregated states are used. Thus each = ingress and egress will use per each ingress - egress set one aggregated = state.

In am concerned about the scalabillity to large networks. = This is due to the
N^2 trunk mesh of trunks, where N represents the number of edges in a = network.
I think it would be good if PCN could support the HOSE model, where no aggregation states are used to model a bandwidth limit. Therefore, I = would recommend to look into PCN -extention for HOSE type = scenario.

comments?
-lasse

=00 ------_=_NextPart_001_01C8963F.5F2ADD82-- --===============0081463391== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0081463391==-- From pcn-bounces@ietf.org Fri Apr 4 03:42:46 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A562E28C100; Fri, 4 Apr 2008 03:42:46 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 679463A6D01 for ; Fri, 4 Apr 2008 03:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.223 X-Spam-Level: X-Spam-Status: No, score=-1.223 tagged_above=-999 required=5 tests=[AWL=2.725, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+b+Hws8JMD5 for ; Fri, 4 Apr 2008 03:42:36 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 280803A6823 for ; Fri, 4 Apr 2008 03:42:36 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8F1B2207C5; Fri, 4 Apr 2008 12:42:40 +0200 (CEST) X-AuditID: c1b4fb3c-ad099bb00000193b-5e-47f606204502 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6120A20884; Fri, 4 Apr 2008 12:42:40 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 12:42:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 12:42:39 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC050740577F@esealmw109.eemea.ericsson.se> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34700@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Single DSCP for Admission and Flow Termination Marking thread-index: AciSmam/Ae1M4lI9Ra60kF9c/KnbMQDmI68AAAMLKIA= References: <9671A92C3C8B5744BC97F855F7CB6465153C513F@zcarhxm1.corp.nortel.com> <75A199C5D243C741BF3D3F1EBCEF9BA503B34700@E03MVZ1-UKDY.domain1.systemhost.net> From: "Ingemar Johansson S" To: , , X-OriginalArrivalTime: 04 Apr 2008 10:42:39.0877 (UTC) FILETIME=[9AC58B50:01C89640] X-Brightmail-Tracker: AAAAAA== Subject: Re: [PCN] Single DSCP for Admission and Flow Termination Marking X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1603345933==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1603345933== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89640.9A95BE4C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89640.9A95BE4C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi =20 I am also interested in an answer to this question, and it goes mainly for all the different encoding options that "fiddle" with the ECN bits in one way or the other. I have a feeling that tunneling is more or less the only way to ensure atleast some of the e2e ECN semantics as described in RFC3168 and RFC4774. However I recall that tunneling has its fair share of issues (from earlier discussion by Bob Briscoe). I believe that it would be really helpful if the group could propose how the e2e ECN semantics is best handled. It need to note be solved now but should preferrably be solved once the core issues are solved.=20 =20 I am watching this WG mainly from an application point of view and the ECN bits can be useful for adaptation purposes in eg. streaming applications. The details of flow admission/termination are partly above my head, my main interest is in trying to keep ECN working even across PCN domains. =20 Regards /Ingemar =20 =20 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: den 4 april 2008 11:01 To: babiarz@nortel.com; pcn@ietf.org Subject: Re: [PCN] Single DSCP for Admission and Flow Termination Marking Joe quick question - in terms of ECN compatibility - is this achieved by tunnelling over the pcn-domain?=20 Thanks Phil.=20 =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Jozef Babiarz Sent: 30 March 2008 20:10 To: pcn@ietf.org Subject: [PCN] Single DSCP for Admission and Flow Termination Marking =20 I was thinking about the encoding and tunneling problem for PCN and I think there may be a method by which a single DSCP and the ECN field can be used to signal both admission control and flow termination using ECN bits. Would like others to think about this and point out any issues that I may have missed. The proposed approach can use the EF-admit DSCP for PCN. My assumptions: The EF-admit DSCP is used for end-to-end admission control as proposed by Fred Baker and the PCN wg also reuses this DSCP for PCN based admission control and flow termination function for edge-to-edge. Should note that I believe this can also be used for end-to-end PCN based admission and termination but this is currently out of scope so I will not discuss. Proposed encoding: A packet that is market with EF-admit DSCP means that it is admission control with that ECN bits be used in the following way: ECN =3D 00, means that packet is not-PCN-capable and that admission control is done some other way. Interior nodes remark ECN =3D "01" packets to "11" if traffic rate is above PCN-lower-rate. Interior nodes remark ECN =3D "10" packets to "11" if traffic rate is above PCN-upper-rate.=20 How it works: For PCN based admission control this approach requires that "probe" packet be sent at flow setup to determine if a new flow can be admitted. Example of a probe packet is a RSVP Path message sent from ingress-edge-node to egress-edge-node. The RSVP Path packet is market with EF-admit DSCP and has its ECN bits set to "01". Interior nodes meter EF-admit packets against the PCN-lower-rate and the result of the meter is passed to the marker where the marker remarks "01" packet to "11" if PCN-lower-rate was exceeded. The metering and marking behavior is the so called "threshold marking" as defined in CL or 3sm drafts for admission control. For PCN based flow termination, once a flow is admitted, ingress-edge-node marks admitted PCN traffic with ECN bits to "10". Interior nodes meter EF-admit packets against PCN-upper-rate and the results of the meter is passed to the marker where the maker remarks "10" packets to "11" based on "excess-rate marking" with or without marking frequency reduction.=20 The egress-edge-node knows if the "11" market packet is a probe or it belongs to an admitted flow therefore it can interpret what the marking means.=20 This sounds simple, so what have I missed?=20 This approach works with tunneling, as ECN CE state is copied from outer to inner IP header on de-encapsulation. I believe that this marking also satisfies guidelines in RFC4774. Are there any conditions where this marking approach will not work? One final note: If PCN wg decides to reuse the EF-admit DSCP for PCN than we need to ask Fred Baker to add a statement in to his draft that the ECN bits in the IP header are used for other function and that RFC3168 does not apply to EF-admit DSCP as per guidance in RFC4774. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 ------_=_NextPart_001_01C89640.9A95BE4C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Single DSCP for Admission and Flow Termination = Marking
Hi
 
I am also interested in an answer to this = question, and it=20 goes mainly for all the different encoding options that "fiddle" with = the ECN=20 bits in one way or the other. I have a feeling that tunneling is more or = less=20 the only way to ensure atleast some of the e2e ECN semantics as = described in=20 RFC3168 and RFC4774. However I recall that tunneling has its fair = share of=20 issues (from earlier discussion by Bob Briscoe).
I believe that it would be really helpful if = the group=20 could propose how the e2e ECN semantics is best handled. It need to note = be=20 solved now but should preferrably be solved once the core issues = are=20 solved. 
 
I am watching this WG mainly from an = application point of=20 view and the ECN bits can be useful for adaptation purposes in eg. = streaming=20 applications. The details of flow admission/termination are partly above = my=20 head, my main interest is in trying to keep ECN working even across = PCN=20 domains.
 
Regards
/Ingemar
 
 

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of=20 philip.eardley@bt.com
Sent: den 4 april 2008 = 11:01
To:=20 babiarz@nortel.com; pcn@ietf.org
Subject: Re: [PCN] Single = DSCP for=20 Admission and Flow Termination Marking

Joe

quick = question – in=20 terms of ECN compatibility – is this achieved by tunnelling over = the pcn-domain?=20

Thanks

Phil.=20

 

-----Original=20 Message-----
From:=20 pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Jozef = Babiarz
Sent: 30 March 2008 = 20:10
To: pcn@ietf.org
Subject: [PCN] Single DSCP for = Admission=20 and Flow Termination Marking

 

I was thinking about the = encoding=20 and tunneling problem for PCN and I think there may be a method by which = a=20 single DSCP and the ECN field can be used to signal both admission = control and=20 flow termination using ECN bits. Would like others to think about this = and point=20 out any issues that I may have missed.

The proposed=20 approach can use the = EF-admit DSCP=20 for PCN.

My = assumptions:

The EF-admit DSCP is used = for=20 end-to-end admission control as proposed by Fred Baker and the PCN wg = also=20 reuses this DSCP for PCN based admission control and flow termination = function=20 for edge-to-edge. Should note that I believe this can also be used for=20 end-to-end PCN based admission and termination but this is currently out = of=20 scope so I will not discuss.

Proposed = encoding:

A packet that is market = with=20 EF-admit DSCP means that it is admission control with that ECN bits be = used in=20 the following way:

ECN =3D 00, means that = packet is=20 not-PCN-capable and that admission control is done some other=20 way.

Interior = nodes remark ECN = =3D “01” packets = to “11” if traffic rate=20 is above PCN-lower-rate.

Interior nodes remark ECN=20 =3D “10” packets = to “11” if traffic rate=20 is above PCN-upper-rate.

How it = works:

For PCN based admission = control this=20 approach requires that “probe” packet be sent at flow setup = to determine if a=20 new flow can be admitted. Example of a probe packet is a RSVP Path message = sent from=20 ingress-edge-node to egress-edge-node. The RSVP Path packet is market = with=20 EF-admit DSCP and has its ECN bits set to=20 “01”. Interior = nodes meter EF-admit=20 packets against the PCN-lower-rate and the result of the meter is passed = to the=20 marker where the marker remarks = “01” packet = to “11” if = PCN-lower-rate was=20 exceeded. The metering = and marking=20 behavior is the so called “threshold=20 marking” as defined in CL or 3sm drafts for admission = control.

For PCN based flow = termination, once=20 a flow is admitted, ingress-edge-node=20 marks=20 admitted PCN=20 traffic with ECN bits = to “10”.=20 Interior nodes=20 meter EF-admit packets against = PCN-upper-rate=20 and the results = of the meter=20 is passed to the marker where the maker remarks=20 “10” packets = to “11” based = on “excess-rate = marking” with or=20 without marking frequency reduction. =

The egress-edge-node knows = if=20 the “11” market=20 packet is a probe or = it belongs to an = admitted=20 flow therefore it=20 can interpret = what the=20 marking means.

This sounds simple, so = what have I=20 missed?

This = approach works=20 with tunneling,=20 as ECN CE state is copied=20 from outer to = inner IP header=20 on de-encapsulation.

I = believe that=20 this = marking also=20 satisfies guidelines in=20 RFC4774.

Are there any conditions = where this=20 marking approach will not work?

One=20 final = note:

If PCN wg decides to reuse = the=20 EF-admit DSCP for PCN than we need=20 to ask Fred Baker to add a statement in to his draft = that the=20 ECN bits in the IP header = are used=20 for other function and that RFC3168 does not apply to EF-admit DSCP as = per=20 guidance in RFC4774.

Regards,=20 Joe

email:babiarz@nortel.com

Telephone:613-763-6098

= ------_=_NextPart_001_01C89640.9A95BE4C-- --===============1603345933== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1603345933==-- From pcn-bounces@ietf.org Fri Apr 4 05:07:47 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5B0B28C3B0; Fri, 4 Apr 2008 05:07:47 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E3CD3A6BEC for ; Fri, 4 Apr 2008 05:07:47 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ew9UvEK65eT for ; Fri, 4 Apr 2008 05:07:46 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 3B4B13A6C12 for ; Fri, 4 Apr 2008 05:07:46 -0700 (PDT) Received: from cpe-071-077-051-004.nc.res.rr.com ([71.77.51.4]) by elom.tchmachines.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jhkht-0006oO-9G; Fri, 04 Apr 2008 08:07:45 -0400 From: Steven Blake To: Georgios Karagiannis In-Reply-To: <003101c8962c$04f48400$810c5982@dynamic.ewi.utwente.nl> References: <75A199C5D243C741BF3D3F1EBCEF9BA503B346F6@E03MVZ1-UKDY.domain1.systemhost.net> <003101c8962c$04f48400$810c5982@dynamic.ewi.utwente.nl> Date: Fri, 04 Apr 2008 08:07:45 -0400 Message-Id: <1207310865.3277.143.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: pcn@ietf.org Subject: Re: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On Fri, 2008-04-04 at 10:15 +0200, Georgios Karagiannis wrote: > Hi Phil > > The scalability problem with the trunk model mentioned by Lars is the > following. > Suppose that a network uses 200 ingress/egress edges. > > In the worst case the edges will have to maintain the following number > of states: > > Trunk model (max number of state per PHB at edges) > ---------------- > Max. number of ingress-egress-aggregated states at each ingress: (N-1) > = 199 > Max. number of ingress-egress-aggregated states at each egress: > (N-1)^2 = 39601 I don't believe this is correct. There are a total of (N-1)^2 ingress/egress aggregates in the network, but each egress terminates only N-1. > HOSE model (max. number of states per PHB at edges) > -------------- > Max. number of per PHB states (instead of ingress-egress-aggregates) > at each ingress: (N-1) = 199 > Max. number of per PHB states at each egress: (N-1) = 199 Please explain. Note also that, unless traffic is tunneled from the ingress to egress, then each egress will have to maintain state for each PCN flow traversing it, so as to be able to associate an ingress router with the flow. Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Apr 4 06:09:36 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD14928C21F; Fri, 4 Apr 2008 06:09:36 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 198AE28C389 for ; Fri, 4 Apr 2008 06:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.359 X-Spam-Level: X-Spam-Status: No, score=0.359 tagged_above=-999 required=5 tests=[AWL=0.863, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiDMXt7c7utJ for ; Fri, 4 Apr 2008 06:09:35 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 0F0E03A6B88 for ; Fri, 4 Apr 2008 06:09:34 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m34D9VhD016947; Fri, 4 Apr 2008 15:09:39 +0200 (MEST) From: "Georgios Karagiannis" To: "'Steven Blake'" References: <75A199C5D243C741BF3D3F1EBCEF9BA503B346F6@E03MVZ1-UKDY.domain1.systemhost.net> <003101c8962c$04f48400$810c5982@dynamic.ewi.utwente.nl> <1207310865.3277.143.camel@tachyon> Date: Fri, 4 Apr 2008 15:09:26 +0200 Message-ID: <001301c89655$2198aea0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1207310865.3277.143.camel@tachyon> thread-index: AciWU6qtMurcNqCoRHOGkE2RlzAxdgAAEY4A X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 04 Apr 2008 15:09:39 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] Why is PCN only supportingtrunk(ingress-egresss-aggregated)model? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Steven Please see below > -----Original Message----- > From: Steven Blake [mailto:slblake@petri-meat.com] > Sent: vrijdag 4 april 2008 14:08 > To: Georgios Karagiannis > Cc: philip.eardley@bt.com; lars.westberg@ericsson.com; pcn@ietf.org > Subject: Re: [PCN] Why is PCN only > supportingtrunk(ingress-egresss-aggregated)model? > > On Fri, 2008-04-04 at 10:15 +0200, Georgios Karagiannis wrote: > > > Hi Phil > > > > The scalability problem with the trunk model mentioned by > Lars is the > > following. > > Suppose that a network uses 200 ingress/egress edges. > > > > In the worst case the edges will have to maintain the > following number > > of states: > > > > Trunk model (max number of state per PHB at edges) > > ---------------- > > Max. number of ingress-egress-aggregated states at each > ingress: (N-1) > > = 199 Max. number of ingress-egress-aggregated states at > each egress: > > (N-1)^2 = 39601 > > I don't believe this is correct. There are a total of > (N-1)^2 ingress/egress aggregates in the network, but each > egress terminates only N-1. The situation that Lars described was a full meshed trunk model! This will mean that each ingress could also route packets through other ingresses (by using e.g. preconfiguration) before they are sent to the egress. Thus if you have a network with 3 ingresses and one egress, then the total number of paths that the egress is receiveing is 9. Ingress1 => egress Ingress2 => egress Ingress3 => egress Ingress1 => Ingress2 => egress Ingress1 => Ingress3 => egress Ingress2 => Ingress1 => egress Ingress2 => Ingress3 => egress Ingress3 => Ingress1 => egress Ingress3 => Ingress2 => egress Best regards, Georgios > > > HOSE model (max. number of states per PHB at edges) > > -------------- > > Max. number of per PHB states (instead of > ingress-egress-aggregates) > > at each ingress: (N-1) = 199 Max. number of per PHB states at each > > egress: (N-1) = 199 > > Please explain. > > Note also that, unless traffic is tunneled from the ingress > to egress, then each egress will have to maintain state for > each PCN flow traversing it, so as to be able to associate an > ingress router with the flow. > > > Regards, > > // Steve > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Apr 4 08:15:54 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AE9D3A6B0F; Fri, 4 Apr 2008 08:15:54 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC99B3A6D65 for ; Fri, 4 Apr 2008 08:15:51 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VFe4+qaoBbd for ; Fri, 4 Apr 2008 08:15:49 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 15CA03A6C4C for ; Fri, 4 Apr 2008 08:15:10 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Fri, 4 Apr 2008 17:15:14 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 17:15:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 17:16:54 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C010BC8CA@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1206983895.3561.12.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Consensus questions: Q4, Q5, and Q6 Thread-Index: AciTU3JRyUX4TBNNRnmj33KzeQYPQwDEEqZg References: <1206983895.3561.12.camel@neutrino> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 04 Apr 2008 15:15:14.0263 (UTC) FILETIME=[AEBECE70:01C89666] Cc: pcn@ietf.org Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Steven, this one is more difficult. My views below. Regards, Rudiger | Q4: Should the standards-track PCN scheme require (as a MUST implement | feature) that interior PCN routers support Excess-Rate marking, | according to the particular method of handling already marked | packets and drops described in Anna Charny's presentation? | http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf Yes. | | Q5: Should the standards-track PCN scheme require (as a MUST implement | feature) that interior PCN routers support Threshold marking (in | addition to Excess-Rate marking), according to the particular method | described in Philip Eardley's presentation on Tuesday? | http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf Tough. Phil suggested something like PCN lite and to me that sounds a little like two RFCs or like a parent and a child RFC. I'm not sure. I'm happy with any simple mechanism proving to be efficient and I think this is one. So that's a yes. But I'd like to be sure that suppliers don't implement excess or threshold only. As a non participant in Philadelphia, I'm worried by the rerefence '(see encoding)' in Phil's document. I guess I've seen that or it is in the minutes. A reference to the coding presentation as part of this question may be helpful. | | Q6: If presented with sufficient evidence in a timely fashion, would | the PCN wg entertain the option of modifying the interior router | Excess-Rate marking behavior for the standards-track PCN scheme (as | described in question 4)? I need a better specification of what "sufficient evidence" means. I'm not interested in a solution performing slightly better than any of Q4 and Q5 but coming with serious implementation complexity (this also covers implementation of completely new policing or queuing mechanisms, any kind of per flow measurements in backbone routers, RAO processing on backbone routers, to name a few). I also object to any proposal which isn't well engineered, so that standardisation of PCN is further delayed. Any input of that type should go to a separate draft. | | According to the draft meeting minutes, Q4 was accepted 8-0 | (my notes have it as 6-0), Q5 was accepted 6-1, and Q6 was | accepted 2-0. | | Please send comments to the list during the next few days. | | | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | Steven Blake | Ericsson/Redback Networks +1 919-472-9913 | | _______________________________________________ | PCN mailing list | PCN@ietf.org | https://www.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Apr 4 08:17:19 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C4943A6E0E; Fri, 4 Apr 2008 08:17:19 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B90543A6E3D for ; Fri, 4 Apr 2008 08:17:17 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 201rK1bb7VWj for ; Fri, 4 Apr 2008 08:17:16 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 6D8C53A6E0E for ; Fri, 4 Apr 2008 08:17:15 -0700 (PDT) Received: from cpe-071-077-051-004.nc.res.rr.com ([71.77.51.4] helo=localhost) by elom.tchmachines.com with esmtp (Exim 4.68) (envelope-from ) id 1JhnfH-00056I-9b; Fri, 04 Apr 2008 11:17:15 -0400 Date: Fri, 4 Apr 2008 11:17:15 -0400 From: Steven Blake To: Georgios Karagiannis Message-ID: <20080404151715.GA24574@tachyon.nc.rr.com> References: <75A199C5D243C741BF3D3F1EBCEF9BA503B346F6@E03MVZ1-UKDY.domain1.systemhost.net> <003101c8962c$04f48400$810c5982@dynamic.ewi.utwente.nl> <1207310865.3277.143.camel@tachyon> <001301c89655$2198aea0$810c5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <001301c89655$2198aea0$810c5982@dynamic.ewi.utwente.nl> User-Agent: Mutt/1.4.2.3i X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: pcn@ietf.org Subject: Re: [PCN] Why is PCN only supportingtrunk(ingress-egresss-aggregated)model? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On Fri, Apr 04, 2008 at 03:09:26PM +0200, Georgios Karagiannis wrote: > > I don't believe this is correct. There are a total of > > (N-1)^2 ingress/egress aggregates in the network, but each > > egress terminates only N-1. > > The situation that Lars described was a full meshed trunk model! > This will mean that each ingress could also route packets through other > ingresses (by using e.g. > preconfiguration) before they are sent to the egress. > > Thus if you have a network with 3 ingresses and one egress, then the total > number of paths > that the egress is receiveing is 9. > Ingress1 => egress > Ingress2 => egress > Ingress3 => egress > Ingress1 => Ingress2 => egress > Ingress1 => Ingress3 => egress > Ingress2 => Ingress1 => egress > Ingress2 => Ingress3 => egress > Ingress3 => Ingress1 => egress > Ingress3 => Ingress2 => egress Georgios, - You only have more than three paths in the case of ECMP, in which case you may have many more than nine. - Why only consider the case where traffic is routed via one more ingress, instead of two/three/four/etc.? - How and why would the egress distinguish between traffic that entered the network via an ingress X, and traffic that entered by another ingress Y that was routed via X? Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Apr 4 08:29:03 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0618328C440; Fri, 4 Apr 2008 08:29:03 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2D1F28C440 for ; Fri, 4 Apr 2008 08:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.287 X-Spam-Level: X-Spam-Status: No, score=0.287 tagged_above=-999 required=5 tests=[AWL=0.791, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGArk0HiQ-Xj for ; Fri, 4 Apr 2008 08:28:56 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 36B8E3A6E1B for ; Fri, 4 Apr 2008 08:28:56 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m34FSm2Q005699; Fri, 4 Apr 2008 17:28:55 +0200 (MEST) From: "Georgios Karagiannis" To: "'Steven Blake'" References: <75A199C5D243C741BF3D3F1EBCEF9BA503B346F6@E03MVZ1-UKDY.domain1.systemhost.net> <003101c8962c$04f48400$810c5982@dynamic.ewi.utwente.nl> <1207310865.3277.143.camel@tachyon> <001301c89655$2198aea0$810c5982@dynamic.ewi.utwente.nl> <20080404151715.GA24574@tachyon.nc.rr.com> Date: Fri, 4 Apr 2008 17:28:40 +0200 Message-ID: <001801c89668$94f49040$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080404151715.GA24574@tachyon.nc.rr.com> thread-index: AciWZv8Ofn22mhw2So2ULvSaZnyfKwAAHsww X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 04 Apr 2008 17:28:55 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] Why is PCN only supportingtrunk(ingress-egresss-aggregated)model? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Steven Please see in line! > -----Original Message----- > From: Steven Blake [mailto:slblake@petri-meat.com] > Sent: vrijdag 4 april 2008 17:17 > To: Georgios Karagiannis > Cc: philip.eardley@bt.com; lars.westberg@ericsson.com; pcn@ietf.org > Subject: Re: [PCN] Why is PCN only > supportingtrunk(ingress-egresss-aggregated)model? > > On Fri, Apr 04, 2008 at 03:09:26PM +0200, Georgios Karagiannis wrote: > > > > I don't believe this is correct. There are a total of > > > (N-1)^2 ingress/egress aggregates in the network, but each egress > > > terminates only N-1. > > > > The situation that Lars described was a full meshed trunk model! > > This will mean that each ingress could also route packets through > > other ingresses (by using e.g. > > preconfiguration) before they are sent to the egress. > > > > Thus if you have a network with 3 ingresses and one egress, > then the > > total number of paths that the egress is receiveing is 9. > > Ingress1 => egress > > Ingress2 => egress > > Ingress3 => egress > > Ingress1 => Ingress2 => egress > > Ingress1 => Ingress3 => egress > > Ingress2 => Ingress1 => egress > > Ingress2 => Ingress3 => egress > > Ingress3 => Ingress1 => egress > > Ingress3 => Ingress2 => egress > > Georgios, > > - You only have more than three paths in the case of ECMP, in > which case you > may have many more than nine. Georgios: Yes, you are right, so you get more ingress-egress states > > - Why only consider the case where traffic is routed via one > more ingress, > instead of two/three/four/etc.? Georgios: Yes, you are right, so you get more ingress-egress states > > - How and why would the egress distinguish between traffic > that entered the > network via an ingress X, and traffic that entered by > another ingress Y > that was routed via X? Georgios: It is because the flows passing through the different ingresses and are routed to the same egress might follow a different path. Thus the flows that are forwarded through the following path: IngressX => Egress Might follow a different path then the flows that were routed via: IngressY => IngressX => Egress Best regards, Georgios > > > Regards, > > // Steve > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sat Apr 5 05:33:06 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 970BB3A6CFA; Sat, 5 Apr 2008 05:33:06 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4134D3A6D22 for ; Sat, 5 Apr 2008 05:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.492 X-Spam-Level: * X-Spam-Status: No, score=1.492 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_72=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Azngyxe+N1ss for ; Sat, 5 Apr 2008 05:33:04 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id EE16128C20B for ; Sat, 5 Apr 2008 05:33:03 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id m35CX55U025511; Sat, 5 Apr 2008 14:33:05 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sat, 05 Apr 2008 12:33:04 +0000 To: "philip.eardley@bt.com" , "lars.westberg@ericsson.com" , "pcn@ietf.org" Date: Sat, 05 Apr 2008 12:33:04 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: <5hZyVWd2.1207398784.3318430.karagian@ewi.utwente.nl> In-Reply-To: <003101c8962c$04f48400$810c5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Sat, 05 Apr 2008 14:33:06 +0200 (MEST) Subject: Re: [PCN] Why is PCN only supporting trunk(ingress-egresss-aggregated)model? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi all I have checked the below calculations made by me and I think that I have to clarify some things: >Trunk model (max number of state per PHB at edges) >---------------- >Max. number of ingress-egress-aggregated states at each ingress: (N-1) = 199 >Max. number of ingress-egress-aggregated states at each egress: (N-1)^2 = >39601 Georgios: The above caluclation regarding number of ingress-egress-aggregated states at each egress is only valid if the following is valid: * A full meshed trunk model is used. This will mean that each ingress could also route packets through other ingresses (by using e.g. preconfiguration) before they are sent to the egress. * Flows passing through the different ingresses and are routed to the same egress might follow a different path. Thus the flows that are forwarded through the following path: IngressX => Egress Might follow a different path then the flows that were routed via: IngressY => IngressX => Egress By having separate ingress-egress states for such situations, it prevents the actions where flows that are belonging to one congested ingress-egress aggregate trunk, but are not passing through the same communication path as the congested trunk, are used in solving the congestion in the ingress-egress-aggregated trunk. In the above example IngressX and Egress will then have to maintain two types of aggregation states. IngressX-Egress state IngressY-IngressX-Egress state. > >HOSE model (max. number of states per PHB at edges) >-------------- >Max. number of per PHB states (instead of ingress-egress-aggregates) at each >ingress: (N-1) = 199 >Max. number of per PHB states at each egress: (N-1) = 199 Georgios: The above calculation was related to the number of PHB states on all edges used in this example. Note that: Max. number of per PHB states at each ingress: = 1 PHB state (this holds for any example). Max. number of per PHB states at each egress: = 1 PHB state (this holds for any example) Furthermore, note that when an egress based admission control and flow termination handling solution, such as LC-PCN, is used for the support of the HOSE model, then the PCN domain can use any kind of routing. Thus this type of HOSE model is routing agnostic. Best regards, Georgios On 4/4/2008, "Georgios Karagiannis" wrote: >Hi Phil > >The scalability problem with the trunk model mentioned by Lars is the >following. >Suppose that a network uses 200 ingress/egress edges. > >In the worst case the edges will have to maintain the following number of >states: > >Trunk model (max number of state per PHB at edges) >---------------- >Max. number of ingress-egress-aggregated states at each ingress: (N-1) = 199 >Max. number of ingress-egress-aggregated states at each egress: (N-1)^2 = >39601 > > >HOSE model (max. number of states per PHB at edges) >-------------- >Max. number of per PHB states (instead of ingress-egress-aggregates) at each >ingress: (N-1) = 199 >Max. number of per PHB states at each egress: (N-1) = 199 > >Regarding flow termination using EMFT, as it was already emphasized during >the IETF meeting, >EMFT is too slow and it will not able to solve the flow termination >accurately. > >By using the features that are currently described in LC-PCN for ECMP >solution and by using per PHB aggregated states at the edges, >instead of ingress-egress-aggregated states at the edges then the HOSE model >can work accurately. > > >Best regards, >Georgios > > > > > _____ > >From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >philip.eardley@bt.com >Sent: donderdag 3 april 2008 17:31 >To: lars.westberg@ericsson.com; pcn@ietf.org >Subject: Re: [PCN] Why is PCN only supporting >trunk(ingress-egresss-aggregated)model? > > > >Hi lasse > > > >My answer was only about admission ctrl. Actually I'm not sure I get your >scalability worry - after all, in the pcn architecture doc If the number of >edges is really too high for the ingress to keep track of the pre-congestion >level for all the egresses, then it seems very likely that there'll be no >current comms between the ingress & many of the egresses, and hence no need >to track that pre-congestion level > > > >On the subject of flow termination ctrl my instinct is that scalability is >(even?) less of a concern. If it really is, then you could go for >terminating marked flows or a subset, as in michael's EMFT > > > >phil > >-----Original Message----- >From: Lars Westberg [mailto:lars.westberg@ericsson.com] >Sent: 03 April 2008 15:51 >To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org >Subject: RE: [PCN] Why is PCN only supporting trunk >(ingress-egresss-aggregated)model? > > > >Hi Phil > > > >The major problem is that the egress will notice the congestion if a single >marking scheme is used but I think it may be a problem to calculate the >excess rate. > >May be you can check it more in detail. > > > >One of the reason is of cources that we are thinking of deplyment scenario >where the number of edges are very large and I am worried that the >trunk-approach will impose a limitations in the network design. > > > >-Lasse > > > > > _____ > > >From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >Sent: den 3 april 2008 09:51 >To: Lars Westberg; pcn@ietf.org >Subject: RE: [PCN] Why is PCN only supporting trunk >(ingress-egresss-aggregated)model? > >Lasse > >To check: the hose model would mean that the admission decision is made at >each ingress node, regardless of what egress the traffic is destined to. So, >a PCN hose model would involve each ingress getting congestion reports from >every egress (for traffic from that ingress) and recording them as a >collected (aggregated) value of pre-congestion. > >As far as I know, no-one has looked at this - I don't think we should delay >current progress by looking at it, since it seems to me a significant change >to the conceptual model. But it looks to me like an extension that could >easily be done with the pcn technology described in the architecture draft. > >phil > > > >-----Original Message----- >From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars >Westberg >Sent: 03 April 2008 06:16 >To: pcn@ietf.org >Subject: [PCN] Why is PCN only supporting trunk >(ingress-egresss-aggregated)model? > > > >Hi, >>From the PCN architecture draft that I have read and from the discussions >that I have followed I see that PCN is currently only supporting the trunk >aggregation model, where ingress-egreess-aggregated states are used. Thus >each ingress and egress will use per each ingress - egress set one >aggregated state. > >In am concerned about the scalabillity to large networks. This is due to the >N^2 trunk mesh of trunks, where N represents the number of edges in a >network. >I think it would be good if PCN could support the HOSE model, where no >aggregation states are used to model a bandwidth limit. Therefore, I would >recommend to look into PCN -extention for HOSE type scenario. > >comments? >-lasse > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sat Apr 5 21:55:48 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85DEB28C0E9; Sat, 5 Apr 2008 21:55:48 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ABC13A6A20 for ; Sat, 5 Apr 2008 21:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_20=-0.74, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MANQoRFPLCwu for ; Sat, 5 Apr 2008 21:55:35 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id CC48A3A689C for ; Sat, 5 Apr 2008 21:55:07 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m364sXM28776; Sun, 6 Apr 2008 04:54:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 6 Apr 2008 00:55:08 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB6465155B99C7@zcarhxm1.corp.nortel.com> In-Reply-To: <1B6169C658325341A3B8066E23919E1C010BC6D7@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Single DSCP for Admission and Flow Termination Marking Thread-Index: AciSmam/Ae1M4lI9Ra60kF9c/KnbMQDk6SywAFxSoRA= References: <9671A92C3C8B5744BC97F855F7CB6465153C513F@zcarhxm1.corp.nortel.com> <1B6169C658325341A3B8066E23919E1C010BC6D7@S4DE8PSAANK.mitte.t-com.de> From: "Jozef Babiarz" To: "Geib, Ruediger" Cc: pcn@ietf.org Subject: Re: [PCN] Single DSCP for Admission and Flow Termination Marking X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1309469702==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1309469702== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C897A2.648DFEBA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C897A2.648DFEBA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See comments below. =20 Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 ________________________________ From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: April 4, 2008 4:52 AM To: Babiarz, Jozef (CAR:0S03) Cc: pcn@ietf.org Subject: RE: [PCN] Single DSCP for Admission and Flow Termination Marking =20 Hi Joe, =20 congratulations, smart engineering. =20 Some initial thoughts: =20 - a PCN policer counts all packets belonging to the EF-admit DSCP. After the lower threshold is passed, a certain type is remarked, after the upper=20 has been passed, all are remarked. - you mention probing, but I'm not sure we should call it that. We are in=20 agreement, that the RSVP path message must be sent anyway. What=20 we talk about is an encoding option at the ingress and a specific=20 marking behaviour at the core. [Joe] I'm OK with not calling it probing. =20 Two questions: - is it possible to realise your proposal with a token bucket policer? I guess=20 not, because the policer counts all packets of a certain DSCP, but it=20 modifies only part of all. This seems to resemble the behaviour of a=20 hyrachical policer. Which doesn't have to be bad - its just that hyrachical=20 schedulers aren't a commodity in backbone routers these days. [Joe] Yes it's possible. I have modified a token bucket policer on one of our routers in the lab to do this type of marking.=20 Used one TB for PCN-lower-rate and second TB for PCN-upper-rate. =20 - the ingress must mark RSVP refresh messages differently than initial=20 messages. I may be wrong, but RSVP refreshes don't look different than initial set up messages. The only difference is, that a node registers state=20 has been set up already. The differentiation is required to avoid an admission=20 stop to result in a termination. [Joe] I would assume the RSVP refresh message would be sent with the same ECN markings as the RSVP PATH message. The egress know that this is RSVP packet (I still think that we should call it probe packet) and that reflects current traffic level against PCN-lower-rate (admission).=20 =20 Then let's come to one of my favorite subjects, MPLS interoperability. Too bad,=20 that doesn't work. You can optimistically squeeze one EXP codepoint from the MPLS bunch. So there (and I guess for Ethernet too), an SM proposal=20 will be it. That's bad in these networks and shouldn't avoid smarter solutions=20 in the IP network. [Joe] In MPLS networks, I think that you only need one PCN mechanism and that is admission control. In my view why do you need flow termination when you have engineered LSPs with fast-reroute? If you large LSPs SM works fine. =20 However the friends of MPLS shouldn't be left without a PCN solution. I=20 currently can't imagine, how single marking could be downpropagated to an=20 IP packet following the above coding scheme in a reasonable way.=20 Especially if your backbone works with pen ultimate hop popping of labels. So in the MPLS case, probably a different solution is required. =20 =20 =20 =09 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Jozef Babiarz Sent: Sunday, March 30, 2008 9:10 PM To: pcn@ietf.org Subject: [PCN] Single DSCP for Admission and Flow Termination Marking I was thinking about the encoding and tunneling problem for PCN and I think there may be a method by which a single DSCP and the ECN field can be used to signal both admission control and flow termination using ECN bits. Would like others to think about this and point out any issues that I may have missed. The proposed approach can use the EF-admit DSCP for PCN. My assumptions: The EF-admit DSCP is used for end-to-end admission control as proposed by Fred Baker and the PCN wg also reuses this DSCP for PCN based admission control and flow termination function for edge-to-edge. Should note that I believe this can also be used for end-to-end PCN based admission and termination but this is currently out of scope so I will not discuss. Proposed encoding: A packet that is market with EF-admit DSCP means that it is admission control with that ECN bits be used in the following way: ECN =3D 00, means that packet is not-PCN-capable and that admission control is done some other way. Interior nodes remark ECN =3D "01" packets to "11" if traffic rate is above PCN-lower-rate. Interior nodes remark ECN =3D "10" packets to "11" if traffic rate is above PCN-upper-rate.=20 How it works: For PCN based admission control this approach requires that "probe" packet be sent at flow setup to determine if a new flow can be admitted. Example of a probe packet is a RSVP Path message sent from ingress-edge-node to egress-edge-node. The RSVP Path packet is market with EF-admit DSCP and has its ECN bits set to "01". Interior nodes meter EF-admit packets against the PCN-lower-rate and the result of the meter is passed to the marker where the marker remarks "01" packet to "11" if PCN-lower-rate was exceeded. The metering and marking behavior is the so called "threshold marking" as defined in CL or 3sm drafts for admission control. For PCN based flow termination, once a flow is admitted, ingress-edge-node marks admitted PCN traffic with ECN bits to "10". Interior nodes meter EF-admit packets against PCN-upper-rate and the results of the meter is passed to the marker where the maker remarks "10" packets to "11" based on "excess-rate marking" with or without marking frequency reduction.=20 The egress-edge-node knows if the "11" market packet is a probe or it belongs to an admitted flow therefore it can interpret what the marking means.=20 This sounds simple, so what have I missed?=20 This approach works with tunneling, as ECN CE state is copied from outer to inner IP header on de-encapsulation. I believe that this marking also satisfies guidelines in RFC4774. Are there any conditions where this marking approach will not work? One final note: If PCN wg decides to reuse the EF-admit DSCP for PCN than we need to ask Fred Baker to add a statement in to his draft that the ECN bits in the IP header are used for other function and that RFC3168 does not apply to EF-admit DSCP as per guidance in RFC4774. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 ------_=_NextPart_001_01C897A2.648DFEBA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Single DSCP for Admission and Flow Termination Marking

See comments = below.

 

Regards, = Joe
email:babiarz@nortel.com
Telephone:613-763-6098

From: Geib, = Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: April 4, 2008 4:52 = AM
To: Babiarz, Jozef (CAR:0S03)
Cc: pcn@ietf.org
Subject: RE: [PCN] Single = DSCP for Admission and Flow Termination Marking

 

Hi = Joe,

 

congratulations, smart = engineering.

 

Some initial = thoughts:

 

- a PCN policer counts = all packets belonging to the EF-admit DSCP. = After 

  the lower threshold is = passed, a certain type is remarked, after the upper =

  has been passed, all are = remarked.

- you mention probing, but I'm not = sure we should call it that. We are in

  agreement, that the RSVP = path message must be sent anyway. What

  we talk about is an encoding option at the ingress and a specific =

  marking behaviour at the = core.

[Joe] I’m OK with not calling it = probing.

 

Two = questions:

- is it possible to realise your = proposal with a token bucket policer? I guess

  not, because the policer = counts all packets of a certain DSCP, but it

  modifies only part of all. This seems to resemble the behaviour of a =

  = hyrachical policer. Which doesn't have to be bad - its just that hyrachical =

  schedulers aren't a = commodity in backbone routers these days.

[Joe] Yes it’s possible. I have modified a = token bucket policer on one of our routers in the lab to do this type of = marking.

Used one TB for PCN-lower-rate and second TB for PCN-upper-rate.

 

- the ingress must mark = RSVP refresh messages differently than initial

  messages. I may be wrong, = but RSVP refreshes don't look different than

  initial set up messages. The = only difference is, that a node registers state

  has been set up already. The differentiation is required to avoid an admission =

  stop to result in a = termination.

[Joe] I would assume the RSVP refresh message would = be sent with the same ECN markings as the RSVP PATH message. The egress know = that this is RSVP packet (I still think that we should call it probe packet) and = that reflects current traffic level against PCN-lower-rate (admission). =

 

Then let's come to one of my = favorite subjects, MPLS interoperability. Too bad,

that doesn't work. You can = optimistically squeeze one EXP codepoint from

the MPLS bunch. So there (and I = guess for Ethernet too), an SM proposal

will be it. That's bad in these = networks and shouldn't avoid smarter solutions

in the IP = network.

[Joe] In MPLS networks, I think that you only need = one PCN mechanism and that is admission control. In my view why do you need flow = termination when you have engineered LSPs with fast-reroute? If you large LSPs SM works = fine.

 

However the friends of MPLS = shouldn't be left without a PCN solution. I

currently can't imagine, how single marking could be downpropagated to an

IP packet following the above = coding scheme in a reasonable way.

Especially if your backbone works = with pen ultimate hop popping of labels.

So in the MPLS case, probably a = different solution is required.

 

 

 

From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Jozef Babiarz
Sent: Sunday, March 30, = 2008 9:10 PM
To: pcn@ietf.org
Subject: [PCN] Single = DSCP for Admission and Flow Termination Marking

I was thinking about the encoding and tunneling problem for PCN and I = think there may be a method by which a single DSCP and the ECN field can be used to = signal both admission control and flow termination using ECN bits. Would like = others to think about this and point out any issues that I may have = missed.

The proposed approach can use the EF-admit DSCP for = PCN.

My assumptions:

The EF-admit DSCP is used for end-to-end admission control as proposed by = Fred Baker and the PCN wg also reuses this DSCP for PCN based admission = control and flow termination function for edge-to-edge. Should note that I believe = this can also be used for end-to-end PCN based admission and termination but this = is currently out of scope so I will not = discuss.

Proposed encoding:

A packet that is market with EF-admit DSCP means that it is admission = control with that ECN bits be used in the following = way:

ECN =3D 00, means that packet is not-PCN-capable and that admission control = is done some other way.

Interior nodes remark ECN =3D “01” packets to “11” if traffic rate is above = PCN-lower-rate.

Interior nodes remark ECN =3D “10” packets to “11” if traffic rate is above PCN-upper-rate. =

How it works:

For PCN based admission control this approach requires that = “probe” packet be sent at flow setup to determine if a new flow can be admitted. Example of a probe packet is a RSVP Path message sent = from ingress-edge-node to egress-edge-node. The RSVP Path packet is market = with EF-admit DSCP and has its ECN bits set to “01”. Interior nodes meter EF-admit packets against the PCN-lower-rate and the = result of the meter is passed to the marker where the marker = remarks “01” packet to “11” if PCN-lower-rate was = exceeded. The metering and marking behavior is the so called “threshold marking” as defined in CL or 3sm drafts for admission = control.

For PCN based flow termination, once a flow is admitted, = ingress-edge-node marks admitted PCN traffic with ECN bits to = “10”. Interior nodes meter EF-admit packets against = PCN-upper-rate and the results of the meter is passed to the marker where the maker = remarks “10” packets to “11” based on “excess-rate marking” with or without marking frequency = reduction.

The egress-edge-node knows if the “11” market = packet is a probe or it belongs to an admitted flow therefore it = can interpret what the marking means.

This sounds simple, so what have I missed?

This approach works with tunneling, = as ECN CE state is copied from outer to inner IP header = on de-encapsulation.

I believe that this marking = also satisfies guidelines in RFC4774.

Are there any conditions where this marking approach will not = work?

One final note:

If PCN wg decides to reuse the EF-admit DSCP for PCN than we = need to ask Fred Baker to add a statement in to his draft that the ECN bits in the IP header are used for other function and that RFC3168 does not = apply to EF-admit DSCP as per guidance in RFC4774.

Regards, = Joe

email:babiarz@nortel.com<= /p>

Telephone:613-763-6098

------_=_NextPart_001_01C897A2.648DFEBA-- --===============1309469702== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1309469702==-- From pcn-bounces@ietf.org Sat Apr 5 21:58:16 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB7853A6A20; Sat, 5 Apr 2008 21:58:16 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD39B3A69DB for ; Sat, 5 Apr 2008 21:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=1.639, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2K55M8+idB2 for ; Sat, 5 Apr 2008 21:58:08 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 615753A68DD for ; Sat, 5 Apr 2008 21:58:08 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m364vbM28816; Sun, 6 Apr 2008 04:57:37 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 6 Apr 2008 00:58:12 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB6465155B99C8@zcarhxm1.corp.nortel.com> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34700@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Single DSCP for Admission and Flow Termination Marking Thread-Index: AciSmam/Ae1M4lI9Ra60kF9c/KnbMQDmI68AAFwSjaA= References: <9671A92C3C8B5744BC97F855F7CB6465153C513F@zcarhxm1.corp.nortel.com> <75A199C5D243C741BF3D3F1EBCEF9BA503B34700@E03MVZ1-UKDY.domain1.systemhost.net> From: "Jozef Babiarz" To: , Subject: Re: [PCN] Single DSCP for Admission and Flow Termination Marking X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0176650315==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0176650315== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C897A2.D2406BB9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C897A2.D2406BB9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil, not sure I understand your question. ECN traffic is marked with a different DSCP therefore it will not be subject to this marking treatment.=20 =20 Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: April 4, 2008 5:01 AM To: Babiarz, Jozef (CAR:0S03); pcn@ietf.org Subject: RE: [PCN] Single DSCP for Admission and Flow Termination Marking =20 Joe quick question - in terms of ECN compatibility - is this achieved by tunnelling over the pcn-domain?=20 Thanks Phil.=20 =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Jozef Babiarz Sent: 30 March 2008 20:10 To: pcn@ietf.org Subject: [PCN] Single DSCP for Admission and Flow Termination Marking =20 I was thinking about the encoding and tunneling problem for PCN and I think there may be a method by which a single DSCP and the ECN field can be used to signal both admission control and flow termination using ECN bits. Would like others to think about this and point out any issues that I may have missed. The proposed approach can use the EF-admit DSCP for PCN. My assumptions: The EF-admit DSCP is used for end-to-end admission control as proposed by Fred Baker and the PCN wg also reuses this DSCP for PCN based admission control and flow termination function for edge-to-edge. Should note that I believe this can also be used for end-to-end PCN based admission and termination but this is currently out of scope so I will not discuss. Proposed encoding: A packet that is market with EF-admit DSCP means that it is admission control with that ECN bits be used in the following way: ECN =3D 00, means that packet is not-PCN-capable and that admission control is done some other way. Interior nodes remark ECN =3D "01" packets to "11" if traffic rate is above PCN-lower-rate. Interior nodes remark ECN =3D "10" packets to "11" if traffic rate is above PCN-upper-rate.=20 How it works: For PCN based admission control this approach requires that "probe" packet be sent at flow setup to determine if a new flow can be admitted. Example of a probe packet is a RSVP Path message sent from ingress-edge-node to egress-edge-node. The RSVP Path packet is market with EF-admit DSCP and has its ECN bits set to "01". Interior nodes meter EF-admit packets against the PCN-lower-rate and the result of the meter is passed to the marker where the marker remarks "01" packet to "11" if PCN-lower-rate was exceeded. The metering and marking behavior is the so called "threshold marking" as defined in CL or 3sm drafts for admission control. For PCN based flow termination, once a flow is admitted, ingress-edge-node marks admitted PCN traffic with ECN bits to "10". Interior nodes meter EF-admit packets against PCN-upper-rate and the results of the meter is passed to the marker where the maker remarks "10" packets to "11" based on "excess-rate marking" with or without marking frequency reduction.=20 The egress-edge-node knows if the "11" market packet is a probe or it belongs to an admitted flow therefore it can interpret what the marking means.=20 This sounds simple, so what have I missed?=20 This approach works with tunneling, as ECN CE state is copied from outer to inner IP header on de-encapsulation. I believe that this marking also satisfies guidelines in RFC4774. Are there any conditions where this marking approach will not work? One final note: If PCN wg decides to reuse the EF-admit DSCP for PCN than we need to ask Fred Baker to add a statement in to his draft that the ECN bits in the IP header are used for other function and that RFC3168 does not apply to EF-admit DSCP as per guidance in RFC4774. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 ------_=_NextPart_001_01C897A2.D2406BB9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Single DSCP for Admission and Flow Termination Marking

Phil, not sure I understand your = question.

ECN traffic is marked with a = different DSCP therefore it will not be subject to this marking treatment. =

 

Regards, = Joe
email:babiarz@nortel.com
Telephone:613-763-6098

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: April 4, 2008 5:01 = AM
To: Babiarz, Jozef (CAR:0S03); pcn@ietf.org
Subject: RE: [PCN] Single = DSCP for Admission and Flow Termination Marking

 

Joe=

quick question = – in terms of ECN compatibility – is this achieved by tunnelling over = the pcn-domain?

Thanks

Phil. =

 

-----Original Message-----
From: = pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = Behalf Of Jozef Babiarz
Sent: 30 March 2008 = 20:10
To: pcn@ietf.org
Subject: [PCN] Single = DSCP for Admission and Flow Termination Marking

 

I was thinking about the encoding and tunneling problem for PCN and I = think there may be a method by which a single DSCP and the ECN field can be used to = signal both admission control and flow termination using ECN bits. Would like = others to think about this and point out any issues that I may have = missed.

The proposed approach can use the EF-admit DSCP for = PCN.

My assumptions:

The EF-admit DSCP is used for end-to-end admission control as proposed by = Fred Baker and the PCN wg also reuses this DSCP for PCN based admission = control and flow termination function for edge-to-edge. Should note that I believe = this can also be used for end-to-end PCN based admission and termination but this = is currently out of scope so I will not discuss.

Proposed encoding:

A packet that is market with EF-admit DSCP means that it is admission = control with that ECN bits be used in the following way:

ECN =3D 00, means that packet is not-PCN-capable and that admission control = is done some other way.

Interior nodes remark ECN =3D “01” packets to “11” if traffic rate is above = PCN-lower-rate.

Interior nodes remark ECN =3D “10” packets to “11” if traffic rate is above PCN-upper-rate. =

How it works:

For PCN based admission control this approach requires that = “probe” packet be sent at flow setup to determine if a new flow can be admitted. Example of a probe packet is a RSVP Path message sent = from ingress-edge-node to egress-edge-node. The RSVP Path packet is market = with EF-admit DSCP and has its ECN bits set to “01”. Interior nodes meter EF-admit packets against the PCN-lower-rate and the = result of the meter is passed to the marker where the marker = remarks “01” packet to “11” if PCN-lower-rate was = exceeded. The metering and marking behavior is the so called “threshold marking” as defined in CL or 3sm drafts for admission = control.

For PCN based flow termination, once a flow is admitted, = ingress-edge-node marks admitted PCN traffic with ECN bits to = “10”. Interior nodes meter EF-admit packets against = PCN-upper-rate and the results of the meter is passed to the marker where the maker = remarks “10” packets to “11” based on “excess-rate marking” with or without marking frequency = reduction.

The egress-edge-node knows if the “11” market = packet is a probe or it belongs to an admitted flow therefore it = can interpret what the marking means.

This sounds simple, so what have I missed?

This approach works with tunneling, = as ECN CE state is copied from outer to inner IP header = on de-encapsulation.

I believe that this marking = also satisfies guidelines in RFC4774.

Are there any conditions where this marking approach will not = work?

One final note:

If PCN wg decides to reuse the EF-admit DSCP for PCN than we = need to ask Fred Baker to add a statement in to his draft that the ECN bits in the IP header are used for other function and that RFC3168 does not = apply to EF-admit DSCP as per guidance in RFC4774.

Regards, = Joe

email:babiarz@nortel.com

Telephone:613-763-6098

------_=_NextPart_001_01C897A2.D2406BB9-- --===============0176650315== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0176650315==-- From pcn-bounces@ietf.org Sat Apr 5 22:30:42 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CD243A696A; Sat, 5 Apr 2008 22:30:42 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C56B3A691E for ; Sat, 5 Apr 2008 22:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[AWL=1.567, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqJ63qCUIx7k for ; Sat, 5 Apr 2008 22:30:32 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id CB25028C0E9 for ; Sat, 5 Apr 2008 22:30:18 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m365TlM29831; Sun, 6 Apr 2008 05:29:47 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 6 Apr 2008 01:30:22 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB6465155B99C9@zcarhxm1.corp.nortel.com> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC050740577F@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Single DSCP for Admission and Flow Termination Marking Thread-Index: AciSmam/Ae1M4lI9Ra60kF9c/KnbMQDmI68AAAMLKIAAWWVpkA== References: <9671A92C3C8B5744BC97F855F7CB6465153C513F@zcarhxm1.corp.nortel.com> <75A199C5D243C741BF3D3F1EBCEF9BA503B34700@E03MVZ1-UKDY.domain1.systemhost.net> <026F8EEDAD2C4342A993203088C1FC050740577F@esealmw109.eemea.ericsson.se> From: "Jozef Babiarz" To: "Ingemar Johansson S" , , Subject: Re: [PCN] Single DSCP for Admission and Flow Termination Marking X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1229969566==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1229969566== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C897A7.505C6841" This is a multi-part message in MIME format. ------_=_NextPart_001_01C897A7.505C6841 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable PCN is deployed only in Diffserv network. If PCN wg would like to reuse the standardized ECN bits to support alternate ECN semantics, than it should define a new traffic class consistent with RFC3246 and have IANA assigned a DSCP value. In the definition of the new traffic class the PCN semantics is specified. And yes in my mind PCN should be end-to-end signaling experienced congestion levels. Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 ________________________________ From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com]=20 Sent: April 4, 2008 6:43 AM To: philip.eardley@bt.com; Babiarz, Jozef (CAR:0S03); pcn@ietf.org Subject: RE: [PCN] Single DSCP for Admission and Flow Termination Marking =20 Hi =20 I am also interested in an answer to this question, and it goes mainly for all the different encoding options that "fiddle" with the ECN bits in one way or the other. I have a feeling that tunneling is more or less the only way to ensure atleast some of the e2e ECN semantics as described in RFC3168 and RFC4774. However I recall that tunneling has its fair share of issues (from earlier discussion by Bob Briscoe). I believe that it would be really helpful if the group could propose how the e2e ECN semantics is best handled. It need to note be solved now but should preferrably be solved once the core issues are solved.=20 =20 I am watching this WG mainly from an application point of view and the ECN bits can be useful for adaptation purposes in eg. streaming applications. The details of flow admission/termination are partly above my head, my main interest is in trying to keep ECN working even across PCN domains. =20 Regards /Ingemar =20 =20 =20 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: den 4 april 2008 11:01 To: babiarz@nortel.com; pcn@ietf.org Subject: Re: [PCN] Single DSCP for Admission and Flow Termination Marking Joe quick question - in terms of ECN compatibility - is this achieved by tunnelling over the pcn-domain?=20 Thanks Phil.=20 =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Jozef Babiarz Sent: 30 March 2008 20:10 To: pcn@ietf.org Subject: [PCN] Single DSCP for Admission and Flow Termination Marking =20 I was thinking about the encoding and tunneling problem for PCN and I think there may be a method by which a single DSCP and the ECN field can be used to signal both admission control and flow termination using ECN bits. Would like others to think about this and point out any issues that I may have missed. The proposed approach can use the EF-admit DSCP for PCN. My assumptions: The EF-admit DSCP is used for end-to-end admission control as proposed by Fred Baker and the PCN wg also reuses this DSCP for PCN based admission control and flow termination function for edge-to-edge. Should note that I believe this can also be used for end-to-end PCN based admission and termination but this is currently out of scope so I will not discuss. Proposed encoding: A packet that is market with EF-admit DSCP means that it is admission control with that ECN bits be used in the following way: ECN =3D 00, means that packet is not-PCN-capable and that admission control is done some other way. Interior nodes remark ECN =3D "01" packets to "11" if traffic rate is above PCN-lower-rate. Interior nodes remark ECN =3D "10" packets to "11" if traffic rate is above PCN-upper-rate.=20 How it works: For PCN based admission control this approach requires that "probe" packet be sent at flow setup to determine if a new flow can be admitted. Example of a probe packet is a RSVP Path message sent from ingress-edge-node to egress-edge-node. The RSVP Path packet is market with EF-admit DSCP and has its ECN bits set to "01". Interior nodes meter EF-admit packets against the PCN-lower-rate and the result of the meter is passed to the marker where the marker remarks "01" packet to "11" if PCN-lower-rate was exceeded. The metering and marking behavior is the so called "threshold marking" as defined in CL or 3sm drafts for admission control. For PCN based flow termination, once a flow is admitted, ingress-edge-node marks admitted PCN traffic with ECN bits to "10". Interior nodes meter EF-admit packets against PCN-upper-rate and the results of the meter is passed to the marker where the maker remarks "10" packets to "11" based on "excess-rate marking" with or without marking frequency reduction.=20 The egress-edge-node knows if the "11" market packet is a probe or it belongs to an admitted flow therefore it can interpret what the marking means.=20 This sounds simple, so what have I missed?=20 This approach works with tunneling, as ECN CE state is copied from outer to inner IP header on de-encapsulation. I believe that this marking also satisfies guidelines in RFC4774. Are there any conditions where this marking approach will not work? One final note: If PCN wg decides to reuse the EF-admit DSCP for PCN than we need to ask Fred Baker to add a statement in to his draft that the ECN bits in the IP header are used for other function and that RFC3168 does not apply to EF-admit DSCP as per guidance in RFC4774. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 ------_=_NextPart_001_01C897A7.505C6841 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Single DSCP for Admission and Flow Termination Marking

PCN is deployed only in Diffserv = network. If PCN wg would like to reuse the standardized ECN bits to support = alternate ECN semantics, than it should define a new traffic class consistent with RFC3246 and = have IANA assigned a DSCP value.  In the definition of the new traffic class = the PCN semantics is specified. And yes in my mind PCN should be end-to-end = signaling experienced congestion levels.

Regards, = Joe
email:babiarz@nortel.com
Telephone:613-763-6098

From: = Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com]
Sent: April 4, 2008 6:43 = AM
To: = philip.eardley@bt.com; Babiarz, Jozef (CAR:0S03); pcn@ietf.org
Subject: RE: [PCN] Single = DSCP for Admission and Flow Termination Marking

 

Hi<= span lang=3DEN-GB>

 

I am also = interested in an answer to this question, and it goes mainly for all the different = encoding options that "fiddle" with the ECN bits in one way or the = other. I have a feeling that tunneling is more or less the only way to ensure = atleast some of the e2e ECN semantics as described in RFC3168 and RFC4774. = However I recall that tunneling has its fair share of issues (from earlier = discussion by Bob Briscoe).

I believe that = it would be really helpful if the group could propose how the e2e ECN semantics = is best handled. It need to note be solved now but should preferrably be solved = once the core issues are solved. 

 

I am watching = this WG mainly from an application point of view and the ECN bits can be useful = for adaptation purposes in eg. streaming applications. The details of flow admission/termination are partly above my head, my main interest is in = trying to keep ECN working even across PCN domains.

 

Regards

/Ingemar

 

 

 

From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: den 4 april 2008 = 11:01
To: babiarz@nortel.com; pcn@ietf.org
Subject: Re: [PCN] Single = DSCP for Admission and Flow Termination Marking

Joe

quick question = – in terms of ECN compatibility – is this achieved by tunnelling over = the pcn-domain?

Thanks

Phil. =

 

-----Original Message-----
From: = pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = Behalf Of Jozef Babiarz
Sent: 30 March 2008 = 20:10
To: pcn@ietf.org
Subject: [PCN] Single = DSCP for Admission and Flow Termination Marking

 

I was thinking about the encoding and tunneling problem for PCN and I = think there may be a method by which a single DSCP and the ECN field can be used to = signal both admission control and flow termination using ECN bits. Would like = others to think about this and point out any issues that I may have = missed.

The proposed approach can use the EF-admit DSCP for = PCN.

My assumptions:

The EF-admit DSCP is used for end-to-end admission control as proposed by = Fred Baker and the PCN wg also reuses this DSCP for PCN based admission = control and flow termination function for edge-to-edge. Should note that I believe = this can also be used for end-to-end PCN based admission and termination but this = is currently out of scope so I will not discuss.

Proposed encoding:

A packet that is market with EF-admit DSCP means that it is admission = control with that ECN bits be used in the following way:

ECN =3D 00, means that packet is not-PCN-capable and that admission control = is done some other way.

Interior nodes remark ECN =3D “01” packets to “11” if traffic rate is above = PCN-lower-rate.

Interior nodes remark ECN =3D “10” packets to “11” if traffic rate is above PCN-upper-rate. =

How it works:

For PCN based admission control this approach requires that = “probe” packet be sent at flow setup to determine if a new flow can be admitted. = Example of a probe packet is a RSVP Path message sent from ingress-edge-node to egress-edge-node. The RSVP Path packet is market with EF-admit DSCP and = has its ECN bits set to “01”. Interior nodes meter = EF-admit packets against the PCN-lower-rate and the result of the meter is passed = to the marker where the marker remarks “01” packet = to “11” if PCN-lower-rate was exceeded. The metering and marking = behavior is the so called “threshold marking” as defined in = CL or 3sm drafts for admission control.

For PCN based flow termination, once a flow is admitted, = ingress-edge-node marks admitted PCN traffic with ECN bits to = “10”. Interior nodes meter EF-admit packets against = PCN-upper-rate and the results of the meter is passed to the marker where the maker = remarks “10” packets to “11” based on “excess-rate marking” with or without marking frequency = reduction.

The egress-edge-node knows if the “11” market = packet is a probe or it belongs to an admitted flow therefore it = can interpret what the marking means.

This sounds simple, so what have I missed?

This approach works with tunneling, = as ECN CE state is copied from outer to inner IP header = on de-encapsulation.

I believe that this marking = also satisfies guidelines in RFC4774.

Are there any conditions where this marking approach will not = work?

One final note:

If PCN wg decides to reuse the EF-admit DSCP for PCN than we = need to ask Fred Baker to add a statement in to his draft that the ECN bits in the IP header are used for other function and that RFC3168 does not = apply to EF-admit DSCP as per guidance in RFC4774.

Regards, = Joe

email:babiarz@nortel.com

Telephone:613-763-6098

------_=_NextPart_001_01C897A7.505C6841-- --===============1229969566== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1229969566==-- From pcn-bounces@ietf.org Sat Apr 5 22:57:42 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 845693A696A; Sat, 5 Apr 2008 22:57:42 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2FF63A68E6 for ; Sat, 5 Apr 2008 22:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.946 X-Spam-Level: X-Spam-Status: No, score=-3.946 tagged_above=-999 required=5 tests=[AWL=2.653, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9htYT127kYW for ; Sat, 5 Apr 2008 22:57:40 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id CCECC3A683B for ; Sat, 5 Apr 2008 22:57:39 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m365vko02100; Sun, 6 Apr 2008 05:57:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 6 Apr 2008 01:57:43 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB6465155B99CA@zcarhxm1.corp.nortel.com> In-Reply-To: <1206983895.3561.12.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Consensus questions: Q4, Q5, and Q6 Thread-Index: AciTU3Sg0pmBSrzpRNKgHbtRc6IMSQEVopwQ References: <1206983895.3561.12.camel@neutrino> From: "Jozef Babiarz" To: "Steven Blake" , "pcn" Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org My answers below. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Steven Blake Sent: March 31, 2008 1:18 PM To: pcn Subject: [PCN] Consensus questions: Q4, Q5, and Q6 Here are the remaining three questions that were taken during the IETF 71 meeting: Q4: Should the standards-track PCN scheme require (as a MUST implement feature) that interior PCN routers support Excess-Rate marking, according to the particular method of handling already marked packets and drops described in Anna Charny's presentation? http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf [Joe] No. Q5: Should the standards-track PCN scheme require (as a MUST implement feature) that interior PCN routers support Threshold marking (in addition to Excess-Rate marking), according to the particular method described in Philip Eardley's presentation on Tuesday? http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf [Joe] Yes. Q6: If presented with sufficient evidence in a timely fashion, would the PCN wg entertain the option of modifying the interior router Excess-Rate marking behavior for the standards-track PCN scheme (as described in question 4)? [Joe] Abstain. I missed the meeting so do not know what was proposed. According to the draft meeting minutes, Q4 was accepted 8-0 (my notes have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0. Please send comments to the list during the next few days. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Apr 6 17:36:23 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CAA228C204; Sun, 6 Apr 2008 17:36:23 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23C8A28C1F4 for ; Sun, 6 Apr 2008 17:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=1.396, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tOWE-GN9fNK for ; Sun, 6 Apr 2008 17:36:11 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 1ACF128C215 for ; Sun, 6 Apr 2008 17:36:10 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m370ZIU27169; Mon, 7 Apr 2008 00:35:18 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 6 Apr 2008 20:35:52 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB6465155B9ADE@zcarhxm1.corp.nortel.com> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB6465155B99C7@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN in MPLS Network Thread-Index: AciSmam/Ae1M4lI9Ra60kF9c/KnbMQDk6SywAFxSoRAAKInesA== References: <9671A92C3C8B5744BC97F855F7CB6465153C513F@zcarhxm1.corp.nortel.com> <1B6169C658325341A3B8066E23919E1C010BC6D7@S4DE8PSAANK.mitte.t-com.de> <9671A92C3C8B5744BC97F855F7CB6465155B99C7@zcarhxm1.corp.nortel.com> From: "Jozef Babiarz" To: "Jozef Babiarz" , "Geib, Ruediger" Cc: pcn@ietf.org Subject: Re: [PCN] PCN in MPLS Network X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1051328098==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1051328098== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89847.56E92E51" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89847.56E92E51 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ruediger, Are you interested in using PCN in MPLS network? What kind of MPLS network are you running? Do you need both admission control and flow termination mechanism and why? =20 In MPLS network the 3 EXP bits (8 states) can be used to signal different network treatment. Operators can assign and use the 8 states as encoding by the 3 EXP bits to indicate that this traffic is PCN-capable, traffic level is above PCN-lower-rate and/or PCN-upper-rate, etc. To support PCN, 2 or 3 out of 8 states would be need. The other 5 or 6 encoding states can be used for QoS and ECN. =20 I have been thinking about PCN in MPLS and have come up with one example where I think it would be useful. MPLS Network does not support TE and PCN is used to limit the amount of traffic that can be admitted. In this example I do not believe that flow termination would be useful. So on 2 encoding states are needed. =20 Can someone give me an MPLS example that would benefit from use PCN flow termination and admission control? Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Babiarz, Jozef (CAR:0S03) Sent: April 6, 2008 12:55 AM To: Geib, Ruediger Cc: pcn@ietf.org Subject: Re: [PCN] Single DSCP for Admission and Flow Termination Marking =20 See comments below. =20 Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 ________________________________ From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: April 4, 2008 4:52 AM To: Babiarz, Jozef (CAR:0S03) Cc: pcn@ietf.org Subject: RE: [PCN] Single DSCP for Admission and Flow Termination Marking =20 Hi Joe, =20 congratulations, smart engineering. =20 Some initial thoughts: =20 - a PCN policer counts all packets belonging to the EF-admit DSCP. After the lower threshold is passed, a certain type is remarked, after the upper=20 has been passed, all are remarked. - you mention probing, but I'm not sure we should call it that. We are in=20 agreement, that the RSVP path message must be sent anyway. What=20 we talk about is an encoding option at the ingress and a specific=20 marking behaviour at the core. [Joe] I'm OK with not calling it probing. =20 Two questions: - is it possible to realise your proposal with a token bucket policer? I guess=20 not, because the policer counts all packets of a certain DSCP, but it=20 modifies only part of all. This seems to resemble the behaviour of a=20 hyrachical policer. Which doesn't have to be bad - its just that hyrachical=20 schedulers aren't a commodity in backbone routers these days. [Joe] Yes it's possible. I have modified a token bucket policer on one of our routers in the lab to do this type of marking.=20 Used one TB for PCN-lower-rate and second TB for PCN-upper-rate. =20 - the ingress must mark RSVP refresh messages differently than initial=20 messages. I may be wrong, but RSVP refreshes don't look different than initial set up messages. The only difference is, that a node registers state=20 has been set up already. The differentiation is required to avoid an admission=20 stop to result in a termination. [Joe] I would assume the RSVP refresh message would be sent with the same ECN markings as the RSVP PATH message. The egress know that this is RSVP packet (I still think that we should call it probe packet) and that reflects current traffic level against PCN-lower-rate (admission).=20 =20 Then let's come to one of my favorite subjects, MPLS interoperability. Too bad,=20 that doesn't work. You can optimistically squeeze one EXP codepoint from the MPLS bunch. So there (and I guess for Ethernet too), an SM proposal=20 will be it. That's bad in these networks and shouldn't avoid smarter solutions=20 in the IP network. [Joe] In MPLS networks, I think that you only need one PCN mechanism and that is admission control. In my view why do you need flow termination when you have engineered LSPs with fast-reroute? If you large LSPs SM works fine. =20 However the friends of MPLS shouldn't be left without a PCN solution. I=20 currently can't imagine, how single marking could be downpropagated to an=20 IP packet following the above coding scheme in a reasonable way.=20 Especially if your backbone works with pen ultimate hop popping of labels. So in the MPLS case, probably a different solution is required. =20 =20 =20 =09 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Jozef Babiarz Sent: Sunday, March 30, 2008 9:10 PM To: pcn@ietf.org Subject: [PCN] Single DSCP for Admission and Flow Termination Marking I was thinking about the encoding and tunneling problem for PCN and I think there may be a method by which a single DSCP and the ECN field can be used to signal both admission control and flow termination using ECN bits. Would like others to think about this and point out any issues that I may have missed. The proposed approach can use the EF-admit DSCP for PCN. My assumptions: The EF-admit DSCP is used for end-to-end admission control as proposed by Fred Baker and the PCN wg also reuses this DSCP for PCN based admission control and flow termination function for edge-to-edge. Should note that I believe this can also be used for end-to-end PCN based admission and termination but this is currently out of scope so I will not discuss. Proposed encoding: A packet that is market with EF-admit DSCP means that it is admission control with that ECN bits be used in the following way: ECN =3D 00, means that packet is not-PCN-capable and that admission control is done some other way. Interior nodes remark ECN =3D "01" packets to "11" if traffic rate is above PCN-lower-rate. Interior nodes remark ECN =3D "10" packets to "11" if traffic rate is above PCN-upper-rate.=20 How it works: For PCN based admission control this approach requires that "probe" packet be sent at flow setup to determine if a new flow can be admitted. Example of a probe packet is a RSVP Path message sent from ingress-edge-node to egress-edge-node. The RSVP Path packet is market with EF-admit DSCP and has its ECN bits set to "01". Interior nodes meter EF-admit packets against the PCN-lower-rate and the result of the meter is passed to the marker where the marker remarks "01" packet to "11" if PCN-lower-rate was exceeded. The metering and marking behavior is the so called "threshold marking" as defined in CL or 3sm drafts for admission control. For PCN based flow termination, once a flow is admitted, ingress-edge-node marks admitted PCN traffic with ECN bits to "10". Interior nodes meter EF-admit packets against PCN-upper-rate and the results of the meter is passed to the marker where the maker remarks "10" packets to "11" based on "excess-rate marking" with or without marking frequency reduction.=20 The egress-edge-node knows if the "11" market packet is a probe or it belongs to an admitted flow therefore it can interpret what the marking means.=20 This sounds simple, so what have I missed?=20 This approach works with tunneling, as ECN CE state is copied from outer to inner IP header on de-encapsulation. I believe that this marking also satisfies guidelines in RFC4774. Are there any conditions where this marking approach will not work? One final note: If PCN wg decides to reuse the EF-admit DSCP for PCN than we need to ask Fred Baker to add a statement in to his draft that the ECN bits in the IP header are used for other function and that RFC3168 does not apply to EF-admit DSCP as per guidance in RFC4774. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 ------_=_NextPart_001_01C89847.56E92E51 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Single DSCP for Admission and Flow Termination Marking

Ruediger,

Are you interested in using PCN in = MPLS network? What kind of MPLS network are you running? Do you need both = admission control and flow termination mechanism and = why?

 

In MPLS network the 3 EXP bits (8 = states) can be used to signal different network treatment. Operators can assign and = use the 8 states as encoding by the 3 EXP bits to indicate that this traffic is = PCN-capable, traffic level is above PCN-lower-rate and/or PCN-upper-rate, etc. To = support PCN, 2 or 3 out of 8 states would be need. The other 5 or 6 encoding = states can be used for QoS and ECN.

 

I have been thinking about PCN in = MPLS and have come up with one example where I think it would be = useful.

MPLS Network does not support TE = and PCN is used to limit the amount of traffic that can be admitted. In this = example I do not believe that flow termination would be useful. So on 2 encoding = states are needed.

 

Can someone give me an MPLS example = that would benefit from use PCN flow termination and admission = control?

Regards, = Joe
email:babiarz@nortel.com
Telephone:613-763-6098

From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Babiarz, = Jozef (CAR:0S03)
Sent: April 6, 2008 12:55 = AM
To: Geib, Ruediger
Cc: pcn@ietf.org
Subject: Re: [PCN] Single = DSCP for Admission and Flow Termination Marking

 

See comments = below.

 

Regards, = Joe
email:babiarz@nortel.com
Telephone:613-763-6098

From: Geib, = Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: April 4, 2008 4:52 = AM
To: Babiarz, Jozef (CAR:0S03)
Cc: pcn@ietf.org
Subject: RE: [PCN] Single = DSCP for Admission and Flow Termination Marking

 

Hi = Joe,

 

congratulations, smart = engineering.

 

Some initial = thoughts:

 

- a PCN policer counts = all packets belonging to the EF-admit DSCP. = After 

  the lower threshold is = passed, a certain type is remarked, after the upper =

  has been passed, all are = remarked.

- you mention probing, but I'm not = sure we should call it that. We are in

  agreement, that the RSVP = path message must be sent anyway. What

  we talk about is an encoding option at the ingress and a specific =

  marking behaviour at the = core.

[Joe] I’m OK with not calling it = probing.

 

Two = questions:

- is it possible to realise your = proposal with a token bucket policer? I guess

  not, because the policer = counts all packets of a certain DSCP, but it

  modifies only part of all. This seems to resemble the behaviour of a =

  = hyrachical policer. Which doesn't have to be bad - its just that hyrachical =

  schedulers aren't a = commodity in backbone routers these days.

[Joe] Yes it’s possible. I have modified a = token bucket policer on one of our routers in the lab to do this type of = marking.

Used one TB for PCN-lower-rate and second TB for PCN-upper-rate.

 

- the ingress must mark = RSVP refresh messages differently than initial

  messages. I may be wrong, = but RSVP refreshes don't look different than

  initial set up messages. The = only difference is, that a node registers state

  has been set up already. The differentiation is required to avoid an admission =

  stop to result in a = termination.

[Joe] I would assume the RSVP refresh message would = be sent with the same ECN markings as the RSVP PATH message. The egress know = that this is RSVP packet (I still think that we should call it probe packet) and = that reflects current traffic level against PCN-lower-rate (admission). =

 

Then let's come to one of my = favorite subjects, MPLS interoperability. Too bad,

that doesn't work. You can = optimistically squeeze one EXP codepoint from

the MPLS bunch. So there (and I = guess for Ethernet too), an SM proposal

will be it. That's bad in these = networks and shouldn't avoid smarter solutions

in the IP = network.

[Joe] In MPLS networks, I think that you only need = one PCN mechanism and that is admission control. In my view why do you need flow termination when you have engineered LSPs with fast-reroute? If you = large LSPs SM works fine.

 

However the friends of MPLS = shouldn't be left without a PCN solution. I

currently can't imagine, how single marking could be downpropagated to an

IP packet following the above = coding scheme in a reasonable way.

Especially if your backbone works = with pen ultimate hop popping of labels.

So in the MPLS case, probably a = different solution is required.

 

 

 

From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Jozef Babiarz
Sent: Sunday, March 30, = 2008 9:10 PM
To: pcn@ietf.org
Subject: [PCN] Single = DSCP for Admission and Flow Termination Marking

I was thinking about the encoding and tunneling problem for PCN and I = think there may be a method by which a single DSCP and the ECN field can be used to = signal both admission control and flow termination using ECN bits. Would like = others to think about this and point out any issues that I may have = missed.

The proposed approach can use the EF-admit DSCP for = PCN.

My assumptions:

The EF-admit DSCP is used for end-to-end admission control as proposed by = Fred Baker and the PCN wg also reuses this DSCP for PCN based admission = control and flow termination function for edge-to-edge. Should note that I believe = this can also be used for end-to-end PCN based admission and termination but this = is currently out of scope so I will not = discuss.

Proposed encoding:

A packet that is market with EF-admit DSCP means that it is admission = control with that ECN bits be used in the following way:

ECN =3D 00, means that packet is not-PCN-capable and that admission control = is done some other way.

Interior nodes remark ECN =3D “01” packets to “11” if traffic rate is above = PCN-lower-rate.

Interior nodes remark ECN =3D “10” packets to “11” if traffic rate is above PCN-upper-rate. =

How it works:

For PCN based admission control this approach requires that = “probe” packet be sent at flow setup to determine if a new flow can be admitted. Example of a probe packet is a RSVP Path message sent = from ingress-edge-node to egress-edge-node. The RSVP Path packet is market = with EF-admit DSCP and has its ECN bits set to “01”. Interior nodes meter EF-admit packets against the PCN-lower-rate and the = result of the meter is passed to the marker where the marker = remarks “01” packet to “11” if PCN-lower-rate was = exceeded. The metering and marking behavior is the so called “threshold marking” as defined in CL or 3sm drafts for admission = control.

For PCN based flow termination, once a flow is admitted, = ingress-edge-node marks admitted PCN traffic with ECN bits to = “10”. Interior nodes meter EF-admit packets against = PCN-upper-rate and the results of the meter is passed to the marker where the maker = remarks “10” packets to “11” based on “excess-rate marking” with or without marking frequency = reduction.

The egress-edge-node knows if the “11” market = packet is a probe or it belongs to an admitted flow therefore it = can interpret what the marking means.

This sounds simple, so what have I missed?

This approach works with tunneling, = as ECN CE state is copied from outer to inner IP header = on de-encapsulation.

I believe that this marking = also satisfies guidelines in RFC4774.

Are there any conditions where this marking approach will not = work?

One final note:

If PCN wg decides to reuse the EF-admit DSCP for PCN than we = need to ask Fred Baker to add a statement in to his draft that the ECN bits in the IP header are used for other function and that RFC3168 does not = apply to EF-admit DSCP as per guidance in RFC4774.

Regards, = Joe

email:babiarz@nortel.com<= /p>

Telephone:613-763-6098

------_=_NextPart_001_01C89847.56E92E51-- --===============1051328098== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1051328098==-- From pcn-bounces@ietf.org Mon Apr 7 00:09:22 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F72728C2CC; Mon, 7 Apr 2008 00:09:22 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21C3428C2C8 for ; Mon, 7 Apr 2008 00:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpqKNGW--Yt3 for ; Mon, 7 Apr 2008 00:09:17 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id E5AFE28C291 for ; Mon, 7 Apr 2008 00:09:16 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Mon, 7 Apr 2008 09:09:27 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Apr 2008 09:09:26 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 09:11:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-Id: <1B6169C658325341A3B8066E23919E1C010BC9C7@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB6465155B99C7@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Single DSCP for Admission and Flow Termination Marking thread-index: AciSmam/Ae1M4lI9Ra60kF9c/KnbMQDk6SywAFxSoRAAN2RasA== References: <9671A92C3C8B5744BC97F855F7CB6465153C513F@zcarhxm1.corp.nortel.com> <1B6169C658325341A3B8066E23919E1C010BC6D7@S4DE8PSAANK.mitte.t-com.de> <9671A92C3C8B5744BC97F855F7CB6465155B99C7@zcarhxm1.corp.nortel.com> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 07 Apr 2008 07:09:26.0899 (UTC) FILETIME=[50CD4430:01C8987E] Cc: pcn@ietf.org Subject: Re: [PCN] Single DSCP for Admission and Flow Termination Marking X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1911851340==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1911851340== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8987E.5086E170" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8987E.5086E170 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Joe, =20 two more statements in line, =20 Rudiger ________________________________ From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: April 4, 2008 4:52 AM To: Babiarz, Jozef (CAR:0S03) Cc: pcn@ietf.org Subject: RE: [PCN] Single DSCP for Admission and Flow Termination = Marking =20 Hi Joe, =20 congratulations, smart engineering. =20 Some initial thoughts: =20 - a PCN policer counts all packets belonging to the EF-admit DSCP. = After=20 the lower threshold is passed, a certain type is remarked, after the = upper=20 has been passed, all are remarked. - you mention probing, but I'm not sure we should call it that. We are = in=20 agreement, that the RSVP path message must be sent anyway. What=20 we talk about is an encoding option at the ingress and a specific=20 marking behaviour at the core. [Joe] I'm OK with not calling it probing. =20 Two questions: - is it possible to realise your proposal with a token bucket policer? = I guess=20 not, because the policer counts all packets of a certain DSCP, but it = modifies only part of all. This seems to resemble the behaviour of a=20 hyrachical policer. Which doesn't have to be bad - its just that = hyrachical=20 schedulers aren't a commodity in backbone routers these days. [Joe] Yes it's possible. I have modified a token bucket policer on one = of our routers in the lab to do this type of marking.=20 Used one TB for PCN-lower-rate and second TB for PCN-upper-rate. =20 - the ingress must mark RSVP refresh messages differently than initial=20 messages. I may be wrong, but RSVP refreshes don't look different = than=20 initial set up messages. The only difference is, that a node = registers state=20 has been set up already. The differentiation is required to avoid an = admission=20 stop to result in a termination. [Joe] I would assume the RSVP refresh message would be sent with the = same ECN markings as the RSVP PATH message. The egress know that this is = RSVP packet (I still think that we should call it probe packet) and that = reflects current traffic level against PCN-lower-rate (admission). =20 =20 [RG] I don't understand the "reflects current traffic level against = PCN-lower-rate" statement. Do you mean the sum of the signaled rates as = compared to a measured traffic rate by that?=20 =20 Then let's come to one of my favorite subjects, MPLS interoperability. = Too bad,=20 that doesn't work. You can optimistically squeeze one EXP codepoint = from=20 the MPLS bunch. So there (and I guess for Ethernet too), an SM proposal = will be it. That's bad in these networks and shouldn't avoid smarter = solutions=20 in the IP network. [Joe] In MPLS networks, I think that you only need one PCN mechanism = and that is admission control. In my view why do you need flow = termination when you have engineered LSPs with fast-reroute? If you = large LSPs SM works fine.=20 =20 [RG] I'm favouring a solution without termination and you are right = that I expect traffic engineering to avoid packet loss in the PCN class = under regular operational conditions. Long intervals with traffic above = the lower threshold should be avoided however. But I'm favouring network = to end signaling by passing on CE marked packets to this regard (and I'm = aware that you too are supporting network to end signaling by passing on = CE marked packets). =20 However the friends of MPLS shouldn't be left without a PCN solution. I = currently can't imagine, how single marking could be downpropagated to = an=20 IP packet following the above coding scheme in a reasonable way.=20 Especially if your backbone works with pen ultimate hop popping of = labels. So in the MPLS case, probably a different solution is required. =20 =20 =20 =09 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Jozef Babiarz Sent: Sunday, March 30, 2008 9:10 PM To: pcn@ietf.org Subject: [PCN] Single DSCP for Admission and Flow Termination Marking I was thinking about the encoding and tunneling problem for PCN and I = think there may be a method by which a single DSCP and the ECN field can = be used to signal both admission control and flow termination using ECN = bits. Would like others to think about this and point out any issues = that I may have missed. The proposed approach can use the EF-admit DSCP for PCN. My assumptions: The EF-admit DSCP is used for end-to-end admission control as proposed = by Fred Baker and the PCN wg also reuses this DSCP for PCN based = admission control and flow termination function for edge-to-edge. Should = note that I believe this can also be used for end-to-end PCN based = admission and termination but this is currently out of scope so I will = not discuss. Proposed encoding: A packet that is market with EF-admit DSCP means that it is admission = control with that ECN bits be used in the following way: ECN =3D 00, means that packet is not-PCN-capable and that admission = control is done some other way. Interior nodes remark ECN =3D "01" packets to "11" if traffic rate is = above PCN-lower-rate. Interior nodes remark ECN =3D "10" packets to "11" if traffic rate is = above PCN-upper-rate.=20 How it works: For PCN based admission control this approach requires that "probe" = packet be sent at flow setup to determine if a new flow can be admitted. = Example of a probe packet is a RSVP Path message sent from = ingress-edge-node to egress-edge-node. The RSVP Path packet is market = with EF-admit DSCP and has its ECN bits set to "01". Interior nodes = meter EF-admit packets against the PCN-lower-rate and the result of the = meter is passed to the marker where the marker remarks "01" packet to = "11" if PCN-lower-rate was exceeded. The metering and marking behavior = is the so called "threshold marking" as defined in CL or 3sm drafts for = admission control. For PCN based flow termination, once a flow is admitted, = ingress-edge-node marks admitted PCN traffic with ECN bits to "10". = Interior nodes meter EF-admit packets against PCN-upper-rate and the = results of the meter is passed to the marker where the maker remarks = "10" packets to "11" based on "excess-rate marking" with or without = marking frequency reduction.=20 The egress-edge-node knows if the "11" market packet is a probe or it = belongs to an admitted flow therefore it can interpret what the marking = means.=20 This sounds simple, so what have I missed?=20 This approach works with tunneling, as ECN CE state is copied from = outer to inner IP header on de-encapsulation. I believe that this marking also satisfies guidelines in RFC4774. Are there any conditions where this marking approach will not work? One final note: If PCN wg decides to reuse the EF-admit DSCP for PCN than we need to = ask Fred Baker to add a statement in to his draft that the ECN bits in = the IP header are used for other function and that RFC3168 does not = apply to EF-admit DSCP as per guidance in RFC4774. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 ------_=_NextPart_001_01C8987E.5086E170 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Single DSCP = for Admission and Flow Termination Marking
Hi=20 Joe,
 
two=20 more statements in line,
 
Rudiger

From: Geib,=20 Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: April 4, 2008 4:52 = AM
To: Babiarz,=20 Jozef (CAR:0S03)
Cc: pcn@ietf.org
Subject: RE: [PCN] Single DSCP = for=20 Admission and Flow Termination = Marking

 

Hi=20 Joe,

 

congratulations,=20 smart engineering.

 

Some = initial=20 thoughts:

 

- a PCN=20 policer counts all packets belonging to the EF-admit DSCP.=20 After 

  the=20 lower threshold is passed, a certain type is remarked, after the = upper=20

  has = been=20 passed, all are remarked.

- you = mention=20 probing, but I'm not sure we should call it that. We are in=20

  = agreement,=20 that the RSVP path message must be sent anyway. What=20

  we = talk about=20 is an encoding option at the ingress and a specific=20

  = marking=20 behaviour at the core.

[Joe]=20 I=92m OK with not calling it probing.

 

Two=20 questions:

- is it = possible to=20 realise your proposal with a token bucket policer? I guess=20

  not, = because=20 the policer counts all packets of a certain DSCP, but it=20

  = modifies only=20 part of all. This seems to resemble the behaviour of a=20

 =20 hyrachical policer. Which doesn't have to be bad - its just = that=20 hyrachical

  = schedulers=20 aren't a commodity in backbone routers these days.

[Joe]=20 Yes it=92s possible. I have modified a token bucket policer on one of = our=20 routers in the lab to do this type of marking.=20

Used=20 one TB for PCN-lower-rate and second TB for=20 PCN-upper-rate.

 

- the = ingress must=20 mark RSVP refresh messages differently than initial=20

  = messages. I=20 may be wrong, but RSVP refreshes don't look different than=20

  = initial set up=20 messages. The only difference is, that a node registers state=20

  has = been set=20 up already. The differentiation is required to avoid an admission=20

  stop = to result=20 in a termination.

[Joe]=20 I would assume the RSVP refresh message would be sent with the same = ECN=20 markings as the RSVP PATH message. The egress know that this is RSVP = packet (I=20 still think that we should call it probe packet) and that reflects = current=20 traffic level against PCN-lower-rate (admission).  

 

[RG] I don't = understand the=20 "reflects current traffic level against PCN-lower-rate" statement. Do = you mean=20 the sum of the signaled rates as compared to a measured traffic rate = by=20 that? 

 

Then let's = come to=20 one of my favorite subjects, MPLS interoperability. Too bad,=20

that = doesn't work.=20 You can optimistically squeeze one EXP codepoint from=20

the MPLS = bunch. So=20 there (and I guess for Ethernet too), an SM proposal=20

will be it. = That's=20 bad in these networks and shouldn't avoid smarter solutions=20

in the IP=20 network.

[Joe]=20 In MPLS networks, I think that you only need one PCN mechanism and = that is=20 admission control. In my view why do you need flow termination when = you have=20 engineered LSPs with fast-reroute? If you large LSPs SM works = fine. 

 

[RG] I'm = favouring a=20 solution without termination and you are right that I expect traffic=20 engineering to avoid packet loss in the PCN class = under regular=20 operational conditions. Long intervals with traffic above the lower = threshold=20 should be avoided however. But I'm favouring network to=20 end signaling by passing on CE marked packets to this regard = (and=20 I'm aware that you too are supporting network to end signaling by = passing=20 on CE marked packets).

 

However the = friends=20 of MPLS shouldn't be left without a PCN solution. I=20

currently = can't=20 imagine, how single marking could be downpropagated to an=20

IP packet = following=20 the above coding scheme in a reasonable way. =

Especially = if your=20 backbone works with pen ultimate hop popping of=20 labels.

So in the = MPLS case,=20 probably a different solution is required.

 

 

 

From: pcn-bounces@ietf.org = [mailto:pcn-bounces@ietf.org] On Behalf=20 Of Jozef Babiarz
Sent: Sunday, March 30, 2008 = 9:10=20 PM
To:=20 pcn@ietf.org
Subject: [PCN]=20 Single DSCP for Admission and Flow Termination = Marking

I=20 was thinking about the encoding and tunneling problem for PCN and I = think=20 there may be a method by which a single DSCP and the ECN field can = be used=20 to signal both admission control and flow termination using ECN = bits. Would=20 like others to think about this and point out any issues that I may = have=20 missed.

The proposed=20 approach can use the EF-admit = DSCP for=20 PCN.

My=20 assumptions:

The EF-admit DSCP is = used for=20 end-to-end admission control as proposed by Fred Baker and the PCN = wg also=20 reuses this DSCP for PCN based admission control and flow = termination=20 function for edge-to-edge. Should note that I believe this can also = be used=20 for end-to-end PCN based admission and termination but this is = currently out=20 of scope so I will not discuss.

Proposed=20 encoding:

A packet that is = market with=20 EF-admit DSCP means that it is admission control with that ECN bits = be used=20 in the following way:

ECN =3D 00, means that = packet is=20 not-PCN-capable and that admission control is done some other=20 way.

Interior = nodes=20 remark ECN = =3D =9301=94=20 packets to =9311=94 if traffic rate is above=20 PCN-lower-rate.

Interior nodes remark = ECN=20 =3D =9310=94 packets to = =9311=94 if traffic=20 rate is above PCN-upper-rate.

How it=20 works:

For PCN based = admission control=20 this approach requires that =93probe=94 packet be sent at flow setup = to=20 determine if a new flow can be admitted. Example of a probe=20 packet is a RSVP Path message = sent from=20 ingress-edge-node to egress-edge-node. The RSVP Path packet is = market with=20 EF-admit DSCP and has its ECN bits set to =9301=94. Interior=20 nodes meter EF-admit packets against the PCN-lower-rate and the = result of=20 the meter is passed to the marker where the marker = remarks=20 =9301=94 packet = to=20 =9311=94 if = PCN-lower-rate was=20 exceeded. The metering and = marking=20 behavior is the so called =93threshold = marking=94 as defined=20 in CL or 3sm drafts for admission = control.

For PCN based flow = termination,=20 once a flow is admitted, ingress-edge-node marks=20 admitted PCN=20 traffic with = ECN bits=20 to =9310=94. Interior=20 nodes meter EF-admit = packets=20 against PCN-upper-rate and the results of the = meter is=20 passed to the marker where the maker remarks =9310=94 packets=20 to =9311=94 based = on=20 =93excess-rate = marking=94 with or=20 without marking frequency reduction.

The egress-edge-node = knows if=20 the =9311=94 market = packet=20 is=20 a probe or it belongs to an admitted = flow therefore it = can=20 interpret what the = marking=20 means.

This sounds simple, so = what have=20 I missed?

This = approach=20 works = with=20 tunneling, as ECN = CE state=20 is copied from outer to inner IP = header=20 on de-encapsulation.

I = believe that = this=20 marking also = satisfies guidelines = in=20 RFC4774.

Are there any = conditions where=20 this marking approach will not work?

One = final=20 note:

If PCN wg decides to = reuse the=20 EF-admit DSCP for PCN than we need to ask = Fred Baker=20 to add a statement in to his draft that the=20 ECN bits in the IP = header are=20 used for other function and that RFC3168 does not apply to EF-admit = DSCP as=20 per guidance in RFC4774.

Regards,=20 Joe

email:babiarz@nortel.com<= /P>

Telephone:613-763-6098

------_=_NextPart_001_01C8987E.5086E170-- --===============1911851340== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1911851340==-- From pcn-bounces@ietf.org Mon Apr 7 00:26:42 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AD0528C2DB; Mon, 7 Apr 2008 00:26:42 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCA353A6E62 for ; Mon, 7 Apr 2008 00:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-1.151, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SS2VR4JclNlq for ; Mon, 7 Apr 2008 00:26:38 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id C00C228C2F7 for ; Mon, 7 Apr 2008 00:26:35 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Mon, 7 Apr 2008 09:26:46 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Apr 2008 09:26:45 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 09:28:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-Id: <1B6169C658325341A3B8066E23919E1C010BC9EE@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB6465155B9ADE@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN in MPLS Network thread-index: AciSmam/Ae1M4lI9Ra60kF9c/KnbMQDk6SywAFxSoRAAKInesAAPjG6A References: <9671A92C3C8B5744BC97F855F7CB6465153C513F@zcarhxm1.corp.nortel.com> <1B6169C658325341A3B8066E23919E1C010BC6D7@S4DE8PSAANK.mitte.t-com.de> <9671A92C3C8B5744BC97F855F7CB6465155B99C7@zcarhxm1.corp.nortel.com> <9671A92C3C8B5744BC97F855F7CB6465155B9ADE@zcarhxm1.corp.nortel.com> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 07 Apr 2008 07:26:45.0361 (UTC) FILETIME=[BBC5FE10:01C89880] Cc: pcn@ietf.org Subject: Re: [PCN] PCN in MPLS Network X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0889591806==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0889591806== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89880.BB4AD06D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89880.BB4AD06D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Joe, =20 I've mentioned that in my other mail, but I'm happy to repeat it here: =20 - the network is running LDP, - it is engineered to maintain an SLA under regular operational = conditions (ie. including single outages), - all routers are DiffServ enabled. =20 Our backbone engineering departement is extremly careful with assigning = additional EXP values for any feature in the core network. As I don't = like termination (and I think to recall that someone mentioned it is = forbidden in Germany), I'm looking at admission control as the only = feature required by PCN. To avoid long term admission stop intervals, = I'm favouring to pass on network to end CE marked packets.=20 =20 If I understand your message right, we are largely in agreement. =20 Regards, =20 Rudiger ________________________________ From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: Monday, April 07, 2008 2:36 AM To: Jozef Babiarz; Geib, R=FCdiger Cc: pcn@ietf.org Subject: RE: [PCN] PCN in MPLS Network =09 =09 Ruediger, Are you interested in using PCN in MPLS network? What kind of MPLS = network are you running? Do you need both admission control and flow = termination mechanism and why? =20 In MPLS network the 3 EXP bits (8 states) can be used to signal = different network treatment. Operators can assign and use the 8 states = as encoding by the 3 EXP bits to indicate that this traffic is = PCN-capable, traffic level is above PCN-lower-rate and/or = PCN-upper-rate, etc. To support PCN, 2 or 3 out of 8 states would be = need. The other 5 or 6 encoding states can be used for QoS and ECN. =20 I have been thinking about PCN in MPLS and have come up with one = example where I think it would be useful. MPLS Network does not support TE and PCN is used to limit the amount of = traffic that can be admitted. In this example I do not believe that flow = termination would be useful. So on 2 encoding states are needed. =20 Can someone give me an MPLS example that would benefit from use PCN = flow termination and admission control? Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 =09 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Babiarz, Jozef (CAR:0S03) Sent: April 6, 2008 12:55 AM To: Geib, Ruediger Cc: pcn@ietf.org Subject: Re: [PCN] Single DSCP for Admission and Flow Termination = Marking =20 See comments below. =20 Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 =09 ________________________________ From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: April 4, 2008 4:52 AM To: Babiarz, Jozef (CAR:0S03) Cc: pcn@ietf.org Subject: RE: [PCN] Single DSCP for Admission and Flow Termination = Marking =20 Hi Joe, =20 congratulations, smart engineering. =20 Some initial thoughts: =20 - a PCN policer counts all packets belonging to the EF-admit DSCP. = After=20 the lower threshold is passed, a certain type is remarked, after the = upper=20 has been passed, all are remarked. - you mention probing, but I'm not sure we should call it that. We are = in=20 agreement, that the RSVP path message must be sent anyway. What=20 we talk about is an encoding option at the ingress and a specific=20 marking behaviour at the core. [Joe] I'm OK with not calling it probing. =20 Two questions: - is it possible to realise your proposal with a token bucket policer? = I guess=20 not, because the policer counts all packets of a certain DSCP, but it = modifies only part of all. This seems to resemble the behaviour of a=20 hyrachical policer. Which doesn't have to be bad - its just that = hyrachical=20 schedulers aren't a commodity in backbone routers these days. [Joe] Yes it's possible. I have modified a token bucket policer on one = of our routers in the lab to do this type of marking.=20 Used one TB for PCN-lower-rate and second TB for PCN-upper-rate. =20 - the ingress must mark RSVP refresh messages differently than initial=20 messages. I may be wrong, but RSVP refreshes don't look different = than=20 initial set up messages. The only difference is, that a node = registers state=20 has been set up already. The differentiation is required to avoid an = admission=20 stop to result in a termination. [Joe] I would assume the RSVP refresh message would be sent with the = same ECN markings as the RSVP PATH message. The egress know that this is = RSVP packet (I still think that we should call it probe packet) and that = reflects current traffic level against PCN-lower-rate (admission).=20 =20 Then let's come to one of my favorite subjects, MPLS interoperability. = Too bad,=20 that doesn't work. You can optimistically squeeze one EXP codepoint = from=20 the MPLS bunch. So there (and I guess for Ethernet too), an SM proposal = will be it. That's bad in these networks and shouldn't avoid smarter = solutions=20 in the IP network. [Joe] In MPLS networks, I think that you only need one PCN mechanism = and that is admission control. In my view why do you need flow = termination when you have engineered LSPs with fast-reroute? If you = large LSPs SM works fine. =20 However the friends of MPLS shouldn't be left without a PCN solution. I = currently can't imagine, how single marking could be downpropagated to = an=20 IP packet following the above coding scheme in a reasonable way.=20 Especially if your backbone works with pen ultimate hop popping of = labels. So in the MPLS case, probably a different solution is required. =20 =20 =20 =09 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Jozef Babiarz Sent: Sunday, March 30, 2008 9:10 PM To: pcn@ietf.org Subject: [PCN] Single DSCP for Admission and Flow Termination Marking I was thinking about the encoding and tunneling problem for PCN and I = think there may be a method by which a single DSCP and the ECN field can = be used to signal both admission control and flow termination using ECN = bits. Would like others to think about this and point out any issues = that I may have missed. The proposed approach can use the EF-admit DSCP for PCN. My assumptions: The EF-admit DSCP is used for end-to-end admission control as proposed = by Fred Baker and the PCN wg also reuses this DSCP for PCN based = admission control and flow termination function for edge-to-edge. Should = note that I believe this can also be used for end-to-end PCN based = admission and termination but this is currently out of scope so I will = not discuss. Proposed encoding: A packet that is market with EF-admit DSCP means that it is admission = control with that ECN bits be used in the following way: ECN =3D 00, means that packet is not-PCN-capable and that admission = control is done some other way. Interior nodes remark ECN =3D "01" packets to "11" if traffic rate is = above PCN-lower-rate. Interior nodes remark ECN =3D "10" packets to "11" if traffic rate is = above PCN-upper-rate.=20 How it works: For PCN based admission control this approach requires that "probe" = packet be sent at flow setup to determine if a new flow can be admitted. = Example of a probe packet is a RSVP Path message sent from = ingress-edge-node to egress-edge-node. The RSVP Path packet is market = with EF-admit DSCP and has its ECN bits set to "01". Interior nodes = meter EF-admit packets against the PCN-lower-rate and the result of the = meter is passed to the marker where the marker remarks "01" packet to = "11" if PCN-lower-rate was exceeded. The metering and marking behavior = is the so called "threshold marking" as defined in CL or 3sm drafts for = admission control. For PCN based flow termination, once a flow is admitted, = ingress-edge-node marks admitted PCN traffic with ECN bits to "10". = Interior nodes meter EF-admit packets against PCN-upper-rate and the = results of the meter is passed to the marker where the maker remarks = "10" packets to "11" based on "excess-rate marking" with or without = marking frequency reduction.=20 The egress-edge-node knows if the "11" market packet is a probe or it = belongs to an admitted flow therefore it can interpret what the marking = means.=20 This sounds simple, so what have I missed?=20 This approach works with tunneling, as ECN CE state is copied from = outer to inner IP header on de-encapsulation. I believe that this marking also satisfies guidelines in RFC4774. Are there any conditions where this marking approach will not work? One final note: If PCN wg decides to reuse the EF-admit DSCP for PCN than we need to = ask Fred Baker to add a statement in to his draft that the ECN bits in = the IP header are used for other function and that RFC3168 does not = apply to EF-admit DSCP as per guidance in RFC4774. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 ------_=_NextPart_001_01C89880.BB4AD06D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Single DSCP = for Admission and Flow Termination Marking
Hi Joe,
 
I've mentioned that in my other mail, but I'm = happy to=20 repeat it here:
 
- the network is running = LDP,
- it is engineered to maintain an SLA under = regular=20 operational conditions (ie. including single = outages),
- all routers are DiffServ = enabled.
 
Our backbone engineering departement is = extremly careful=20 with assigning additional EXP values for any feature in the core = network. As I=20 don't like termination (and I think to recall that someone mentioned it = is=20 forbidden in Germany), I'm looking at admission control as the = only=20 feature required by PCN. To avoid long term admission = stop intervals, I'm=20 favouring to pass on network to end CE marked packets. =
 
If I understand your message right, we are = largely in=20 agreement.
 
Regards,
 
Rudiger

From: Jozef Babiarz=20 [mailto:babiarz@nortel.com]
Sent: Monday, April 07, 2008 = 2:36=20 AM
To: Jozef Babiarz; Geib, R=FCdiger
Cc:=20 pcn@ietf.org
Subject: RE: [PCN] PCN in MPLS=20 Network

Ruediger,

Are you = interested in=20 using PCN in MPLS network? What kind of MPLS network are you running? = Do you=20 need both admission control and flow termination mechanism and=20 why?

 

In MPLS = network the 3=20 EXP bits (8 states) can be used to signal different network treatment. = Operators can assign and use the 8 states as encoding by the 3 EXP = bits to=20 indicate that this traffic is PCN-capable, traffic level is above=20 PCN-lower-rate and/or PCN-upper-rate, etc. To support PCN, 2 or 3 out = of 8=20 states would be need. The other 5 or 6 encoding states can be used for = QoS and=20 ECN.

 

I have been = thinking=20 about PCN in MPLS and have come up with one example where I think it = would be=20 useful.

MPLS = Network does not=20 support TE and PCN is used to limit the amount of traffic that can be=20 admitted. In this example I do not believe that flow termination would = be=20 useful. So on 2 encoding states are = needed.

 

Can someone = give me=20 an MPLS example that would benefit from use PCN flow termination and = admission=20 control?

Regards,=20 Joe=20
email:babiarz@nortel.com
Telephone:613-763-6098 =

From:=20 pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Babiarz, Jozef (CAR:0S03)
Sent: April 6, 2008 12:55 = AM
To: Geib, Ruediger
Cc: pcn@ietf.org
Subject: Re: [PCN] Single DSCP = for=20 Admission and Flow Termination = Marking

 

See = comments=20 below.

 

Regards,=20 Joe=20
email:babiarz@nortel.com
Telephone:613-763-6098 =

From: Geib,=20 Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: April 4, 2008 4:52 = AM
To: Babiarz,=20 Jozef (CAR:0S03)
Cc: pcn@ietf.org
Subject: RE: [PCN] Single DSCP = for=20 Admission and Flow Termination = Marking

 

Hi=20 Joe,

 

congratulations,=20 smart engineering.

 

Some = initial=20 thoughts:

 

- a PCN=20 policer counts all packets belonging to the EF-admit DSCP.=20 After 

  the=20 lower threshold is passed, a certain type is remarked, after the = upper=20

  has = been=20 passed, all are remarked.

- you = mention=20 probing, but I'm not sure we should call it that. We are in=20

  = agreement,=20 that the RSVP path message must be sent anyway. What=20

  we = talk about=20 is an encoding option at the ingress and a specific=20

  = marking=20 behaviour at the core.

[Joe]=20 I=92m OK with not calling it probing.

 

Two=20 questions:

- is it = possible to=20 realise your proposal with a token bucket policer? I guess=20

  not, = because=20 the policer counts all packets of a certain DSCP, but it=20

  = modifies only=20 part of all. This seems to resemble the behaviour of a=20

 =20 hyrachical policer. Which doesn't have to be bad - its just = that=20 hyrachical

  = schedulers=20 aren't a commodity in backbone routers these days.

[Joe]=20 Yes it=92s possible. I have modified a token bucket policer on one of = our=20 routers in the lab to do this type of marking.=20

Used=20 one TB for PCN-lower-rate and second TB for=20 PCN-upper-rate.

 

- the = ingress must=20 mark RSVP refresh messages differently than initial=20

  = messages. I=20 may be wrong, but RSVP refreshes don't look different than=20

  = initial set up=20 messages. The only difference is, that a node registers state=20

  has = been set=20 up already. The differentiation is required to avoid an admission=20

  stop = to result=20 in a termination.

[Joe]=20 I would assume the RSVP refresh message would be sent with the same = ECN=20 markings as the RSVP PATH message. The egress know that this is RSVP = packet (I=20 still think that we should call it probe packet) and that reflects = current=20 traffic level against PCN-lower-rate (admission). =

 

Then let's = come to=20 one of my favorite subjects, MPLS interoperability. Too bad,=20

that = doesn't work.=20 You can optimistically squeeze one EXP codepoint from=20

the MPLS = bunch. So=20 there (and I guess for Ethernet too), an SM proposal=20

will be it. = That's=20 bad in these networks and shouldn't avoid smarter solutions=20

in the IP=20 network.

[Joe]=20 In MPLS networks, I think that you only need one PCN mechanism and = that is=20 admission control. In my view why do you need flow termination when = you have=20 engineered LSPs with fast-reroute? If you large LSPs SM works=20 fine.

 

However the = friends=20 of MPLS shouldn't be left without a PCN solution. I=20

currently = can't=20 imagine, how single marking could be downpropagated to an=20

IP packet = following=20 the above coding scheme in a reasonable way. =

Especially = if your=20 backbone works with pen ultimate hop popping of=20 labels.

So in the = MPLS case,=20 probably a different solution is required.

 

 

 

From: pcn-bounces@ietf.org = [mailto:pcn-bounces@ietf.org] On Behalf=20 Of Jozef Babiarz
Sent: Sunday, March 30, 2008 = 9:10=20 PM
To:=20 pcn@ietf.org
Subject: [PCN]=20 Single DSCP for Admission and Flow Termination = Marking

I=20 was thinking about the encoding and tunneling problem for PCN and I = think=20 there may be a method by which a single DSCP and the ECN field can = be used=20 to signal both admission control and flow termination using ECN = bits. Would=20 like others to think about this and point out any issues that I may = have=20 missed.

The proposed=20 approach can use the EF-admit = DSCP for=20 PCN.

My=20 assumptions:

The EF-admit DSCP is = used for=20 end-to-end admission control as proposed by Fred Baker and the PCN = wg also=20 reuses this DSCP for PCN based admission control and flow = termination=20 function for edge-to-edge. Should note that I believe this can also = be used=20 for end-to-end PCN based admission and termination but this is = currently out=20 of scope so I will not discuss.

Proposed=20 encoding:

A packet that is = market with=20 EF-admit DSCP means that it is admission control with that ECN bits = be used=20 in the following way:

ECN =3D 00, means that = packet is=20 not-PCN-capable and that admission control is done some other=20 way.

Interior = nodes=20 remark ECN = =3D =9301=94=20 packets to =9311=94 if traffic rate is above=20 PCN-lower-rate.

Interior nodes remark = ECN=20 =3D =9310=94 packets to = =9311=94 if traffic=20 rate is above PCN-upper-rate.

How it=20 works:

For PCN based = admission control=20 this approach requires that =93probe=94 packet be sent at flow setup = to=20 determine if a new flow can be admitted. Example of a probe=20 packet is a RSVP Path message = sent from=20 ingress-edge-node to egress-edge-node. The RSVP Path packet is = market with=20 EF-admit DSCP and has its ECN bits set to =9301=94. Interior=20 nodes meter EF-admit packets against the PCN-lower-rate and the = result of=20 the meter is passed to the marker where the marker = remarks=20 =9301=94 packet = to=20 =9311=94 if = PCN-lower-rate was=20 exceeded. The metering and = marking=20 behavior is the so called =93threshold = marking=94 as defined=20 in CL or 3sm drafts for admission = control.

For PCN based flow = termination,=20 once a flow is admitted, ingress-edge-node marks=20 admitted PCN=20 traffic with = ECN bits=20 to =9310=94. Interior=20 nodes meter EF-admit = packets=20 against PCN-upper-rate and the results of the = meter is=20 passed to the marker where the maker remarks =9310=94 packets=20 to =9311=94 based = on=20 =93excess-rate = marking=94 with or=20 without marking frequency reduction.

The egress-edge-node = knows if=20 the =9311=94 market = packet=20 is=20 a probe or it belongs to an admitted = flow therefore it = can=20 interpret what the = marking=20 means.

This sounds simple, so = what have=20 I missed?

This = approach=20 works = with=20 tunneling, as ECN = CE state=20 is copied from outer to inner IP = header=20 on de-encapsulation.

I = believe that = this=20 marking also = satisfies guidelines = in=20 RFC4774.

Are there any = conditions where=20 this marking approach will not work?

One = final=20 note:

If PCN wg decides to = reuse the=20 EF-admit DSCP for PCN than we need to ask = Fred Baker=20 to add a statement in to his draft that the=20 ECN bits in the IP = header are=20 used for other function and that RFC3168 does not apply to EF-admit = DSCP as=20 per guidance in RFC4774.

Regards,=20 Joe

email:babiarz@nortel.com<= /P>

Telephone:613-763-6098

------_=_NextPart_001_01C89880.BB4AD06D-- --===============0889591806== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0889591806==-- From pcn-bounces@ietf.org Mon Apr 7 03:44:55 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5B4628C1A9; Mon, 7 Apr 2008 03:44:55 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C8528C148 for ; Mon, 7 Apr 2008 03:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAghfxl1aNLM for ; Mon, 7 Apr 2008 03:44:53 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0B2C528C108 for ; Mon, 7 Apr 2008 03:44:53 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E279321027 for ; Mon, 7 Apr 2008 12:45:04 +0200 (CEST) X-AuditID: c1b4fb3e-ab192bb000004ec0-0b-47f9fb3097c1 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BEB52200C9 for ; Mon, 7 Apr 2008 12:45:04 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 12:45:04 +0200 Received: from ericsson.com ([147.214.131.227]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 12:45:04 +0200 Message-ID: <47F9FB30.8080001@ericsson.com> Date: Mon, 07 Apr 2008 12:45:04 +0200 From: Lars westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steven Blake References: <1206983895.3561.12.camel@neutrino> In-Reply-To: <1206983895.3561.12.camel@neutrino> X-OriginalArrivalTime: 07 Apr 2008 10:45:04.0458 (UTC) FILETIME=[70301AA0:01C8989C] X-Brightmail-Tracker: AAAAAA== Cc: pcn Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0428795821==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0428795821== Content-Type: multipart/alternative; boundary="------------000306000104060801060107" This is a multi-part message in MIME format. --------------000306000104060801060107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit answers inline: Steven Blake wrote: > Here are the remaining three questions that were taken during the IETF > 71 meeting: > > Q4: Should the standards-track PCN scheme require (as a MUST implement > feature) that interior PCN routers support Excess-Rate marking, > according to the particular method of handling already marked > packets and drops described in Anna Charny's presentation? > http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf > YES, only if Q6 is accepted > > > Q5: Should the standards-track PCN scheme require (as a MUST implement > feature) that interior PCN routers support Threshold marking (in > addition to Excess-Rate marking), according to the particular method > described in Philip Eardley's presentation on Tuesday? > http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf > YES > > > Q6: If presented with sufficient evidence in a timely fashion, would > the PCN wg entertain the option of modifying the interior router > Excess-Rate marking behavior for the standards-track PCN scheme (as > described in question 4)? > YES > > > According to the draft meeting minutes, Q4 was accepted 8-0 (my notes > have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0. > > Please send comments to the list during the next few days. > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > --------------000306000104060801060107 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit answers inline:

Steven Blake wrote:
[PCN] Consensus questions: Q4, Q5, and Q6

Here are the remaining three questions that were taken during the IETF
71 meeting:

Q4: Should the standards-track PCN scheme require (as a MUST implement
    feature) that interior PCN routers support Excess-Rate marking,
    according to the particular method of handling already marked
    packets and drops described in Anna Charny's presentation?
    http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf

YES, only if Q6 is accepted



Q5: Should the standards-track PCN scheme require (as a MUST implement
    feature) that interior PCN routers support Threshold marking (in
    addition to Excess-Rate marking), according to the particular method
    described in Philip Eardley's presentation on Tuesday?
    http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf

YES



Q6: If presented with sufficient evidence in a timely fashion, would
    the PCN wg entertain the option of modifying the interior router
    Excess-Rate marking behavior for the standards-track PCN scheme (as
    described in question 4)?

YES



According to the draft meeting minutes, Q4 was accepted 8-0 (my notes
have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0.

Please send comments to the list during the next few days.


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven Blake                <steven.blake@ericsson.com>
Ericsson/Redback Networks               +1 919-472-9913

_______________________________________________
PCN mailing list
PCN@ietf.org
https://www.ietf.org/mailman/listinfo/pcn

--------------000306000104060801060107-- --===============0428795821== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0428795821==-- From pcn-bounces@ietf.org Mon Apr 7 03:47:41 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB4113A6DA2; Mon, 7 Apr 2008 03:47:41 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BB9E3A6CAB for ; Mon, 7 Apr 2008 03:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.892 X-Spam-Level: X-Spam-Status: No, score=0.892 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXyDS2db5YzY for ; Mon, 7 Apr 2008 03:47:39 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 968E43A6B1A for ; Mon, 7 Apr 2008 03:47:39 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id m37AlpsZ029587; Mon, 7 Apr 2008 12:47:51 +0200 (MEST) Received: from 194.237.142.10 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 07 Apr 2008 10:47:51 +0000 To: "Steven Blake" , "pcn" Date: Mon, 07 Apr 2008 10:47:50 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <1206983895.3561.12.camel@neutrino> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 07 Apr 2008 12:47:51 +0200 (MEST) Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi all Please see in line! On 3/31/2008, "Steven Blake" wrote: >Here are the remaining three questions that were taken during the IETF >71 meeting: > >Q4: Should the standards-track PCN scheme require (as a MUST implement > feature) that interior PCN routers support Excess-Rate marking, > according to the particular method of handling already marked > packets and drops described in Anna Charny's presentation? > http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf Yes, if Q6 is also accepted > >Q5: Should the standards-track PCN scheme require (as a MUST implement > feature) that interior PCN routers support Threshold marking (in > addition to Excess-Rate marking), according to the particular method > described in Philip Eardley's presentation on Tuesday? > http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf Yes > >Q6: If presented with sufficient evidence in a timely fashion, would > the PCN wg entertain the option of modifying the interior router > Excess-Rate marking behavior for the standards-track PCN scheme (as > described in question 4)? Yes Best regards, Georgios > >According to the draft meeting minutes, Q4 was accepted 8-0 (my notes >have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0. > >Please send comments to the list during the next few days. > > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Steven Blake >Ericsson/Redback Networks +1 919-472-9913 > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Apr 7 03:54:13 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 612BB3A6C7B; Mon, 7 Apr 2008 03:54:13 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 533153A6D05 for ; Mon, 7 Apr 2008 03:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_ASCII0=1.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 561aKOYe0zV3 for ; Mon, 7 Apr 2008 03:54:10 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id CD52F3A6DE1 for ; Mon, 7 Apr 2008 03:54:09 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 11:54:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 11:54:20 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34715@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <47F9FB30.8080001@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Consensus questions: Q4, Q5, and Q6 Thread-Index: AciYnJKSuGOJxhGtSb2D8qepCf3qMgAAOH9g From: To: , X-OriginalArrivalTime: 07 Apr 2008 10:54:21.0616 (UTC) FILETIME=[BC47AB00:01C8989D] Cc: pcn@ietf.org Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1328070234==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1328070234== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8989D.BBDBDCC3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8989D.BBDBDCC3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lars, Georgios, =20 On Q6, please could you comment / confirm you agree with my email: =20 Yes, although it obviously depends what the evidence is! to me 'timely fashion' means before the 00 dublin draft deadline and 'evidence' means a set of simulations with comparisons with at least CL. In the meantime, we should proceed on the assumption that this evidence isn't forthcoming (that was how I understood the discussion in Philadelphia).=20 =20 Thanks Phil/ =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars westberg Sent: 07 April 2008 11:45 To: Steven Blake Cc: pcn Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 =20 answers inline: Steven Blake wrote: Here are the remaining three questions that were taken during the IETF 71 meeting: Q4: Should the standards-track PCN scheme require (as a MUST implement feature) that interior PCN routers support Excess-Rate marking, according to the particular method of handling already marked packets and drops described in Anna Charny's presentation? http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf YES, only if Q6 is accepted Q5: Should the standards-track PCN scheme require (as a MUST implement feature) that interior PCN routers support Threshold marking (in addition to Excess-Rate marking), according to the particular method described in Philip Eardley's presentation on Tuesday? http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf YES Q6: If presented with sufficient evidence in a timely fashion, would the PCN wg entertain the option of modifying the interior router Excess-Rate marking behavior for the standards-track PCN scheme (as described in question 4)? YES According to the draft meeting minutes, Q4 was accepted 8-0 (my notes have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0. Please send comments to the list during the next few days. =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D Steven Blake =20 Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn ------_=_NextPart_001_01C8989D.BBDBDCC3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [PCN] Consensus questions: Q4, Q5, and Q6

Lars, Georgios,

 

On Q6, please could you comment / = confirm you agree with my email:

 

Yes, although it obviously depends what the evidence = is! to me 'timely fashion' means before the 00 dublin draft deadline and 'evidence' means a set of = simulations with comparisons with at least CL. In the meantime, we should proceed on = the assumption that this evidence isn't forthcoming (that was how I understood the = discussion in Philadelphia).

 

Thanks

Phil/

 

-----Origi= nal Message-----
From: = pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = Behalf Of Lars westberg
Sent: 07 April 2008 = 11:45
To: Steven Blake
Cc: pcn
Subject: Re: [PCN] = Consensus questions: Q4, Q5, and Q6

 

answers inline:

Steven Blake wrote:

Here are the remaining three questions that were taken during the IETF
71 meeting:

Q4: Should the standards-track PCN scheme require (as a MUST = implement
    feature) that interior PCN routers support = Excess-Rate marking,
    according to the particular method of handling = already marked
    packets and drops described in Anna Charny's = presentation?
    http://w= ww3.ietf.org/proceedings/08mar/slides/pcn-6.pdf

YES, only if Q6 is accepted



Q5: Should the standards-track PCN scheme require (as a MUST = implement
    feature) that interior PCN routers support Threshold = marking (in
    addition to Excess-Rate marking), according to the particular method
    described in Philip Eardley's presentation on = Tuesday?
    http://w= ww3.ietf.org/proceedings/08mar/slides/pcn-4.pdf

YES



Q6: If presented with sufficient evidence in a timely fashion, would
    the PCN wg entertain the option of modifying the = interior router
    Excess-Rate marking behavior for the standards-track = PCN scheme (as
    described in question 4)?

YES



According to the draft meeting minutes, Q4 was accepted 8-0 (my = notes
have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0.

Please send comments to the list during the next few days.


=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D
Steven Blake           &n= bsp;    <steven.blake@ericsson.com&g= t;
Ericsson/Redback Networks           = ;    +1 919-472-9913

_______________________________________________
PCN mailing list
PCN@ietf.org
https://www.ietf.org/m= ailman/listinfo/pcn

=00 ------_=_NextPart_001_01C8989D.BBDBDCC3-- --===============1328070234== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1328070234==-- From pcn-bounces@ietf.org Mon Apr 7 04:04:35 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCEDE3A6AA1; Mon, 7 Apr 2008 04:04:35 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 080C33A69CA for ; Mon, 7 Apr 2008 04:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mRdOz7EVYuS for ; Mon, 7 Apr 2008 04:04:33 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D8C133A6AA1 for ; Mon, 7 Apr 2008 04:04:32 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 15600210CD; Mon, 7 Apr 2008 13:02:06 +0200 (CEST) X-AuditID: c1b4fb3e-ad196bb000004ec0-6f-47f9ff2dba41 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DAE352107F; Mon, 7 Apr 2008 13:02:05 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 13:02:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 13:02:04 +0200 Message-ID: In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34715@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Consensus questions: Q4, Q5, and Q6 Thread-Index: AciYnJKSuGOJxhGtSb2D8qepCf3qMgAAOH9gAAApgeA= References: <47F9FB30.8080001@ericsson.com> <75A199C5D243C741BF3D3F1EBCEF9BA503B34715@E03MVZ1-UKDY.domain1.systemhost.net> From: "Lars Westberg" To: , "Steve Blake" X-OriginalArrivalTime: 07 Apr 2008 11:02:05.0576 (UTC) FILETIME=[D0D25880:01C8989E] X-Brightmail-Tracker: AAAAAA== Cc: pcn@ietf.org Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1347425276==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1347425276== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8989E.D037186B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8989E.D037186B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The purpose is to prepare a simulatoin cases that showing the comparison based on the working group specification. As I understand, there are some drafts about performance comparison scenario. =20 -Lasse =20 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: den 7 april 2008 12:54 To: Lars Westberg; Steve Blake Cc: pcn@ietf.org Subject: RE: [PCN] Consensus questions: Q4, Q5, and Q6 Lars, Georgios, =20 On Q6, please could you comment / confirm you agree with my email: =20 Yes, although it obviously depends what the evidence is! to me 'timely fashion' means before the 00 dublin draft deadline and 'evidence' means a set of simulations with comparisons with at least CL. In the meantime, we should proceed on the assumption that this evidence isn't forthcoming (that was how I understood the discussion in Philadelphia).=20 =20 Thanks Phil/ =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars westberg Sent: 07 April 2008 11:45 To: Steven Blake Cc: pcn Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 =20 answers inline: Steven Blake wrote: Here are the remaining three questions that were taken during the IETF 71 meeting: Q4: Should the standards-track PCN scheme require (as a MUST implement feature) that interior PCN routers support Excess-Rate marking, according to the particular method of handling already marked packets and drops described in Anna Charny's presentation? http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf YES, only if Q6 is accepted Q5: Should the standards-track PCN scheme require (as a MUST implement feature) that interior PCN routers support Threshold marking (in addition to Excess-Rate marking), according to the particular method described in Philip Eardley's presentation on Tuesday? http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf YES Q6: If presented with sufficient evidence in a timely fashion, would the PCN wg entertain the option of modifying the interior router Excess-Rate marking behavior for the standards-track PCN scheme (as described in question 4)? YES According to the draft meeting minutes, Q4 was accepted 8-0 (my notes have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0. Please send comments to the list during the next few days. =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D Steven Blake =20 Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn ------_=_NextPart_001_01C8989E.D037186B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [PCN] Consensus questions: Q4, Q5, and Q6
The=20 purpose is to prepare a simulatoin cases that showing the comparison = based on=20 the working group specification. As I understand, there are some drafts = about=20 performance comparison scenario.
 
-Lasse
 

From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: den 7 april 2008=20 12:54
To: Lars Westberg; Steve Blake
Cc:=20 pcn@ietf.org
Subject: RE: [PCN] Consensus questions: Q4, Q5, = and=20 Q6

Lars,=20 Georgios,

 

On Q6, please = could you=20 comment / confirm you agree with my email:

 

Yes,=20 although it obviously depends what the evidence is! to me 'timely = fashion' means=20 before the 00 dublin draft=20 deadline and 'evidence' means a set of simulations with comparisons with = at=20 least CL. In the meantime, we should proceed on the assumption that this = evidence isn't forthcoming (that was how I understood the discussion in=20 Philadelphia).=20

 

Thanks

Phil/

 

-----Original=20 Message-----
From:=20 pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars = westberg
Sent: 07 April 2008 = 11:45
To: Steven Blake
Cc: pcn
Subject: Re: [PCN] Consensus = questions: Q4,=20 Q5, and Q6

 

answers inline:

Steven Blake=20 wrote:

Here = are the=20 remaining three questions that were taken during the IETF
71=20 meeting:

Q4: Should the standards-track PCN scheme require (as a = MUST=20 implement
    feature) that interior PCN routers = support=20 Excess-Rate marking,
    according to the particular = method of=20 handling already marked
    packets and drops = described in=20 Anna Charny's presentation?
    http://w= ww3.ietf.org/proceedings/08mar/slides/pcn-6.pdf

YES, only if Q6 is = accepted



Q5: Should the standards-track PCN = scheme=20 require (as a MUST implement
    feature) that = interior PCN=20 routers support Threshold marking (in
    addition to=20 Excess-Rate marking), according to the particular = method
   =20 described in Philip Eardley's presentation on = Tuesday?
    http://w= ww3.ietf.org/proceedings/08mar/slides/pcn-4.pdf

YES



Q6: If presented with sufficient = evidence in a=20 timely fashion, would
    the PCN wg entertain the = option of=20 modifying the interior router
    Excess-Rate marking = behavior=20 for the standards-track PCN scheme (as
    described = in=20 question 4)?

YES



According to the draft meeting = minutes, Q4 was=20 accepted 8-0 (my notes
have it as 6-0), Q5 was accepted 6-1, and Q6 = was=20 accepted 2-0.

Please send comments to the list during the next = few=20 days.


=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D
Steven=20 Blake           &n= bsp;   =20 <steven.blake@ericsson.com&g= t;
Ericsson/Redback=20 Networks           = ;   =20 +1 = 919-472-9913

_______________________________________________
PC= N=20 mailing list
PCN@ietf.org
https://www.ietf.org/m= ailman/listinfo/pcn

------_=_NextPart_001_01C8989E.D037186B-- --===============1347425276== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1347425276==-- From pcn-bounces@ietf.org Mon Apr 7 04:11:37 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4D53A69CA; Mon, 7 Apr 2008 04:11:37 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8341D3A69CA for ; Mon, 7 Apr 2008 04:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_ASCII0=1.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLpJUmlMScLj for ; Mon, 7 Apr 2008 04:11:32 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id BB8C63A690C for ; Mon, 7 Apr 2008 04:11:31 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 12:11:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 12:11:42 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34716@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Consensus questions: Q4, Q5, and Q6 Thread-Index: AciYnJKSuGOJxhGtSb2D8qepCf3qMgAAOH9gAAApgeAAAHXEwA== From: To: , X-OriginalArrivalTime: 07 Apr 2008 11:11:43.0498 (UTC) FILETIME=[294A3EA0:01C898A0] Cc: pcn@ietf.org Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0705072288==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0705072288== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C898A0.28B99BAD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C898A0.28B99BAD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks that sounds good. several people [not me!} can help with making sure the simulations are truly comparable [this seems to be quite tricky]=20 =20 -----Original Message----- From: Lars Westberg [mailto:lars.westberg@ericsson.com]=20 Sent: 07 April 2008 12:02 To: Eardley,PL,Philip,CXR9 R; Steve Blake Cc: pcn@ietf.org Subject: RE: [PCN] Consensus questions: Q4, Q5, and Q6 =20 The purpose is to prepare a simulatoin cases that showing the comparison based on the working group specification. As I understand, there are some drafts about performance comparison scenario. =20 -Lasse =20 =20 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: den 7 april 2008 12:54 To: Lars Westberg; Steve Blake Cc: pcn@ietf.org Subject: RE: [PCN] Consensus questions: Q4, Q5, and Q6 Lars, Georgios, =20 On Q6, please could you comment / confirm you agree with my email: =20 Yes, although it obviously depends what the evidence is! to me 'timely fashion' means before the 00 dublin draft deadline and 'evidence' means a set of simulations with comparisons with at least CL. In the meantime, we should proceed on the assumption that this evidence isn't forthcoming (that was how I understood the discussion in Philadelphia).=20 =20 Thanks Phil/ =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars westberg Sent: 07 April 2008 11:45 To: Steven Blake Cc: pcn Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 =20 answers inline: Steven Blake wrote: Here are the remaining three questions that were taken during the IETF 71 meeting: Q4: Should the standards-track PCN scheme require (as a MUST implement feature) that interior PCN routers support Excess-Rate marking, according to the particular method of handling already marked packets and drops described in Anna Charny's presentation? http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf YES, only if Q6 is accepted Q5: Should the standards-track PCN scheme require (as a MUST implement feature) that interior PCN routers support Threshold marking (in addition to Excess-Rate marking), according to the particular method described in Philip Eardley's presentation on Tuesday? http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf YES Q6: If presented with sufficient evidence in a timely fashion, would the PCN wg entertain the option of modifying the interior router Excess-Rate marking behavior for the standards-track PCN scheme (as described in question 4)? YES According to the draft meeting minutes, Q4 was accepted 8-0 (my notes have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0. Please send comments to the list during the next few days. =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D Steven Blake =20 Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn ------_=_NextPart_001_01C898A0.28B99BAD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [PCN] Consensus questions: Q4, Q5, and Q6

Thanks that sounds good. several = people [not me!} can help with making sure the simulations are truly comparable = [this seems to be quite tricky]

 

-----Origi= nal Message-----
From: Lars Westberg [mailto:lars.westberg@ericsson.com]
Sent: 07 April 2008 = 12:02
To: = Eardley,PL,Philip,CXR9 R; Steve Blake
Cc: pcn@ietf.org
Subject: RE: [PCN] = Consensus questions: Q4, Q5, and Q6

 

The purpose is to prepare a = simulatoin cases that showing the comparison based on the working group = specification. As I understand, there are some drafts about performance comparison = scenario.

 

-Lasse

 

 

From: philip.eardley@bt.com = [mailto:philip.eardley@bt.com]
Sent: den 7 april 2008 = 12:54
To: Lars Westberg; Steve = Blake
Cc: pcn@ietf.org
Subject: RE: [PCN] = Consensus questions: Q4, Q5, and Q6

Lars, Georgios,

 

On Q6, please could you comment / = confirm you agree with my email:

 

Yes, although it obviously depends what the evidence is! to me 'timely fashion' means = before the 00 dublin draft deadline and 'evidence' means a set of simulations = with comparisons with at least CL. In the meantime, we should proceed on the assumption that this evidence isn't forthcoming (that was how I = understood the discussion in Philadelphia).

 

Thanks

Phil/

 

-----Origi= nal Message-----
From: = pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = Behalf Of Lars westberg
Sent: 07 April 2008 = 11:45
To: Steven Blake
Cc: pcn
Subject: Re: [PCN] = Consensus questions: Q4, Q5, and Q6

 

answers = inline:

Steven Blake wrote:

Here are the remaining three questions that were taken during the IETF
71 meeting:

Q4: Should the standards-track PCN scheme require (as a MUST = implement
    feature) that interior PCN routers support = Excess-Rate marking,
    according to the particular method of handling = already marked
    packets and drops described in Anna Charny's = presentation?
    http://w= ww3.ietf.org/proceedings/08mar/slides/pcn-6.pdf

YES, only if = Q6 is accepted



Q5: Should the standards-track PCN scheme require (as a MUST = implement
    feature) that interior PCN routers support Threshold = marking (in
    addition to Excess-Rate marking), according to the particular method
    described in Philip Eardley's presentation on = Tuesday?
    http://w= ww3.ietf.org/proceedings/08mar/slides/pcn-4.pdf

YES



Q6: If presented with sufficient evidence in a timely fashion, would
    the PCN wg entertain the option of modifying the = interior router
    Excess-Rate marking behavior for the standards-track = PCN scheme (as
    described in question 4)?

YES



According to the draft meeting minutes, Q4 was accepted 8-0 (my = notes
have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0.

Please send comments to the list during the next few days.


=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D
Steven Blake           &n= bsp;    <steven.blake@ericsson.com&g= t;
Ericsson/Redback Networks           = ;    +1 919-472-9913

_______________________________________________
PCN mailing list
PCN@ietf.org
https://www.ietf.org/m= ailman/listinfo/pcn

=00 ------_=_NextPart_001_01C898A0.28B99BAD-- --===============0705072288== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0705072288==-- From pcn-bounces@ietf.org Mon Apr 7 06:08:58 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B07513A6E78; Mon, 7 Apr 2008 06:08:58 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EFD03A6AC3 for ; Mon, 7 Apr 2008 06:08:53 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SXeGKryzoWg for ; Mon, 7 Apr 2008 06:08:48 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 132993A6DA2 for ; Mon, 7 Apr 2008 06:08:47 -0700 (PDT) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 14:08:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 14:09:07 +0100 Message-ID: In-Reply-To: <1206983895.3561.12.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Consensus questions: Q4, Q5, and Q6 Thread-Index: AciTU3QM80BhUV9OQy2auck3TNexYQFXM4VQ From: To: , X-OriginalArrivalTime: 07 Apr 2008 13:08:59.0262 (UTC) FILETIME=[8AEEA1E0:01C898B0] Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Inline... Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Steven Blake > Sent: 31 March 2008 18:18 > To: pcn > Subject: [PCN] Consensus questions: Q4, Q5, and Q6 > > Here are the remaining three questions that were taken during the IETF > 71 meeting: > > Q4: Should the standards-track PCN scheme require (as a MUST implement > feature) that interior PCN routers support Excess-Rate marking, > according to the particular method of handling already marked > packets and drops described in Anna Charny's presentation? > http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf > YES > Q5: Should the standards-track PCN scheme require (as a MUST implement > feature) that interior PCN routers support Threshold marking (in > addition to Excess-Rate marking), according to the > particular method > described in Philip Eardley's presentation on Tuesday? > http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf > YES > Q6: If presented with sufficient evidence in a timely fashion, would > the PCN wg entertain the option of modifying the interior router > Excess-Rate marking behavior for the standards-track PCN > scheme (as > described in question 4)? > YES, but ONLY if a) the evidence is convincing (e.g. much better in majority of FEASIBLE deployment scenarios) and b) is available for the Dublin meeting. Otherwise I don't support delaying things any further... > According to the draft meeting minutes, Q4 was accepted 8-0 (my notes > have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0. > > Please send comments to the list during the next few days. > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Apr 7 19:09:10 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D48A3A6C7B; Mon, 7 Apr 2008 19:09:10 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D7023A6BF3 for ; Mon, 7 Apr 2008 19:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.956 X-Spam-Level: X-Spam-Status: No, score=-2.956 tagged_above=-999 required=5 tests=[AWL=1.342, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OushMZfkya9T for ; Mon, 7 Apr 2008 19:08:58 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 810243A683E for ; Mon, 7 Apr 2008 19:08:57 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m3828Qp15334; Tue, 8 Apr 2008 02:08:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 22:08:47 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB64651561B4C0@zcarhxm1.corp.nortel.com> In-Reply-To: <1B6169C658325341A3B8066E23919E1C010BC9C7@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Single DSCP for Admission and Flow Termination Marking Thread-Index: AciSmam/Ae1M4lI9Ra60kF9c/KnbMQDk6SywAFxSoRAAN2RasAAnp+TQ References: <9671A92C3C8B5744BC97F855F7CB6465153C513F@zcarhxm1.corp.nortel.com> <1B6169C658325341A3B8066E23919E1C010BC6D7@S4DE8PSAANK.mitte.t-com.de> <9671A92C3C8B5744BC97F855F7CB6465155B99C7@zcarhxm1.corp.nortel.com> <1B6169C658325341A3B8066E23919E1C010BC9C7@S4DE8PSAANK.mitte.t-com.de> From: "Jozef Babiarz" To: "Geib, Ruediger" Cc: pcn@ietf.org Subject: Re: [PCN] Single DSCP for Admission and Flow Termination Marking X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0054504892==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0054504892== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8991D.7D50AF89" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8991D.7D50AF89 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ruediger, see further explanations in line, =20 =20 Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 ________________________________ From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: April 7, 2008 3:11 AM To: Babiarz, Jozef (CAR:0S03) Cc: pcn@ietf.org Subject: RE: [PCN] Single DSCP for Admission and Flow Termination Marking =20 Hi Joe, =20 two more statements in line, =20 Rudiger ________________________________ From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: April 4, 2008 4:52 AM To: Babiarz, Jozef (CAR:0S03) Cc: pcn@ietf.org Subject: RE: [PCN] Single DSCP for Admission and Flow Termination Marking =20 Hi Joe, =20 congratulations, smart engineering. =20 Some initial thoughts: =20 - a PCN policer counts all packets belonging to the EF-admit DSCP. After=20 the lower threshold is passed, a certain type is remarked, after the upper=20 has been passed, all are remarked. - you mention probing, but I'm not sure we should call it that. We are in=20 agreement, that the RSVP path message must be sent anyway. What=20 we talk about is an encoding option at the ingress and a specific=20 marking behaviour at the core. [Joe] I'm OK with not calling it probing. =20 Two questions: - is it possible to realise your proposal with a token bucket policer? I guess=20 not, because the policer counts all packets of a certain DSCP, but it=20 modifies only part of all. This seems to resemble the behaviour of a=20 hyrachical policer. Which doesn't have to be bad - its just that hyrachical=20 schedulers aren't a commodity in backbone routers these days. [Joe] Yes it's possible. I have modified a token bucket policer on one of our routers in the lab to do this type of marking.=20 Used one TB for PCN-lower-rate and second TB for PCN-upper-rate. =20 - the ingress must mark RSVP refresh messages differently than initial=20 messages. I may be wrong, but RSVP refreshes don't look different than=20 initial set up messages. The only difference is, that a node registers state=20 has been set up already. The differentiation is required to avoid an admission=20 stop to result in a termination. [Joe] I would assume the RSVP refresh message would be sent with the same ECN markings as the RSVP PATH message. The egress know that this is RSVP packet (I still think that we should call it probe packet) and that reflects current traffic level against PCN-lower-rate (admission). =20 =20 [RG] I don't understand the "reflects current traffic level against PCN-lower-rate" statement. Do you mean the sum of the signaled rates as compared to a measured traffic rate by that?=20 [Joe] My assumption is that PCN-lower-rate marked use "Threshold" marking behavior as outlined by Phil Eardley's presentation, therefore anytime RSVP PATH or RSVP refresh packet is sent, the egress will know the current status of traffic along the path. If the traffic level is below PCN-lower-rate the packet will not be marked, but if it is above packet is marked. There is no need to perform any rate measurements in the egress or ingress for admission control.=20 =20 Then let's come to one of my favorite subjects, MPLS interoperability. Too bad,=20 that doesn't work. You can optimistically squeeze one EXP codepoint from=20 the MPLS bunch. So there (and I guess for Ethernet too), an SM proposal=20 will be it. That's bad in these networks and shouldn't avoid smarter solutions=20 in the IP network. [Joe] In MPLS networks, I think that you only need one PCN mechanism and that is admission control. In my view why do you need flow termination when you have engineered LSPs with fast-reroute? If you large LSPs SM works fine.=20 =20 [RG] I'm favouring a solution without termination and you are right that I expect traffic engineering to avoid packet loss in the PCN class under regular operational conditions. Long intervals with traffic above the lower threshold should be avoided however. But I'm favouring network to end signaling by passing on CE marked packets to this regard (and I'm aware that you too are supporting network to end signaling by passing on CE marked packets). [Joe] Yes. I support that PCN marking or CE be passed to endpoint.=20 =20 However the friends of MPLS shouldn't be left without a PCN solution. I=20 currently can't imagine, how single marking could be downpropagated to an=20 IP packet following the above coding scheme in a reasonable way. Especially if your backbone works with pen ultimate hop popping of labels. So in the MPLS case, probably a different solution is required. =20 =20 =20 =09 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Jozef Babiarz Sent: Sunday, March 30, 2008 9:10 PM To: pcn@ietf.org Subject: [PCN] Single DSCP for Admission and Flow Termination Marking I was thinking about the encoding and tunneling problem for PCN and I think there may be a method by which a single DSCP and the ECN field can be used to signal both admission control and flow termination using ECN bits. Would like others to think about this and point out any issues that I may have missed. The proposed approach can use the EF-admit DSCP for PCN. My assumptions: The EF-admit DSCP is used for end-to-end admission control as proposed by Fred Baker and the PCN wg also reuses this DSCP for PCN based admission control and flow termination function for edge-to-edge. Should note that I believe this can also be used for end-to-end PCN based admission and termination but this is currently out of scope so I will not discuss. Proposed encoding: A packet that is market with EF-admit DSCP means that it is admission control with that ECN bits be used in the following way: ECN =3D 00, means that packet is not-PCN-capable and that admission control is done some other way. Interior nodes remark ECN =3D "01" packets to "11" if traffic rate is above PCN-lower-rate. Interior nodes remark ECN =3D "10" packets to "11" if traffic rate is above PCN-upper-rate.=20 How it works: For PCN based admission control this approach requires that "probe" packet be sent at flow setup to determine if a new flow can be admitted. Example of a probe packet is a RSVP Path message sent from ingress-edge-node to egress-edge-node. The RSVP Path packet is market with EF-admit DSCP and has its ECN bits set to "01". Interior nodes meter EF-admit packets against the PCN-lower-rate and the result of the meter is passed to the marker where the marker remarks "01" packet to "11" if PCN-lower-rate was exceeded. The metering and marking behavior is the so called "threshold marking" as defined in CL or 3sm drafts for admission control. For PCN based flow termination, once a flow is admitted, ingress-edge-node marks admitted PCN traffic with ECN bits to "10". Interior nodes meter EF-admit packets against PCN-upper-rate and the results of the meter is passed to the marker where the maker remarks "10" packets to "11" based on "excess-rate marking" with or without marking frequency reduction.=20 The egress-edge-node knows if the "11" market packet is a probe or it belongs to an admitted flow therefore it can interpret what the marking means.=20 This sounds simple, so what have I missed?=20 This approach works with tunneling, as ECN CE state is copied from outer to inner IP header on de-encapsulation. I believe that this marking also satisfies guidelines in RFC4774. Are there any conditions where this marking approach will not work? One final note: If PCN wg decides to reuse the EF-admit DSCP for PCN than we need to ask Fred Baker to add a statement in to his draft that the ECN bits in the IP header are used for other function and that RFC3168 does not apply to EF-admit DSCP as per guidance in RFC4774. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 ------_=_NextPart_001_01C8991D.7D50AF89 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Single DSCP for Admission and Flow Termination Marking

Ruediger, see further explanations = in line,  

 

Regards, = Joe
email:babiarz@nortel.com
Telephone:613-763-6098

From: Geib, = Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: April 7, 2008 3:11 = AM
To: Babiarz, Jozef (CAR:0S03)
Cc: pcn@ietf.org
Subject: RE: [PCN] Single = DSCP for Admission and Flow Termination Marking

 

= Hi Joe,

 

= two more statements in line,

 

= Rudiger

From: Geib, = Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: April 4, 2008 4:52 = AM
To: Babiarz, Jozef (CAR:0S03)
Cc: pcn@ietf.org
Subject: RE: [PCN] Single = DSCP for Admission and Flow Termination Marking

 

Hi = Joe,

 

congratulations, smart = engineering.

 

Some initial = thoughts:

 

- a PCN policer counts = all packets belonging to the EF-admit DSCP. = After 

  the lower threshold is = passed, a certain type is remarked, after the upper =

  has been passed, all are = remarked.

- you mention probing, but I'm not = sure we should call it that. We are in

  agreement, that the RSVP = path message must be sent anyway. What

  we talk about is an encoding option at the ingress and a specific =

  marking behaviour at the = core.

[Joe] I’m OK with not calling it = probing.

 

Two = questions:

- is it possible to realise your = proposal with a token bucket policer? I guess

  not, because the policer = counts all packets of a certain DSCP, but it

  modifies only part of all. This seems to resemble the behaviour of a =

  = hyrachical policer. Which doesn't have to be bad - its just that hyrachical =

  schedulers aren't a = commodity in backbone routers these days.

[Joe] Yes it’s possible. I have modified a = token bucket policer on one of our routers in the lab to do this type of = marking.

Used one TB for PCN-lower-rate and second TB for PCN-upper-rate.

 

- the ingress must mark = RSVP refresh messages differently than initial

  messages. I may be wrong, = but RSVP refreshes don't look different than

  initial set up messages. The = only difference is, that a node registers state

  has been set up already. The differentiation is required to avoid an admission =

  stop to result in a = termination.

[Joe] I would assume the RSVP refresh message would = be sent with the same ECN markings as the RSVP PATH message. The egress know = that this is RSVP packet (I still think that we should call it probe packet) and = that reflects current traffic level against PCN-lower-rate = (admission).  

 

[RG] I don't understand the "reflects current = traffic level against PCN-lower-rate" statement. Do you mean the sum of the signaled rates as compared to a measured traffic rate by = that? 

[Joe] My assumption is that PCN-lower-rate marked use = “Threshold” marking behavior as outlined by Phil Eardley’s presentation, = therefore anytime RSVP PATH or RSVP refresh packet is sent, the egress will know = the current status of traffic along the path. If the traffic level is below PCN-lower-rate the packet will not be marked, but if it is above packet = is marked. There is no need to perform any rate measurements in the egress = or ingress for admission control.

 

Then let's come to one of my = favorite subjects, MPLS interoperability. Too bad,

that doesn't work. You can = optimistically squeeze one EXP codepoint from

the MPLS bunch. So there (and I = guess for Ethernet too), an SM proposal

will be it. That's bad in these = networks and shouldn't avoid smarter solutions

in the IP = network.

[Joe] In MPLS networks, I think that you only need = one PCN mechanism and that is admission control. In my view why do you need flow termination when you have engineered LSPs with fast-reroute? If you = large LSPs SM works fine. 

 

[RG] I'm favouring a solution without = termination and you are right that I expect traffic engineering to avoid packet loss in = the PCN class under regular operational conditions. Long intervals = with traffic above the lower threshold should be avoided however. But I'm favouring network to end signaling by passing on CE marked packets to this regard (and I'm aware that you too are supporting network to end signaling by passing on CE marked = packets).

[Joe] Yes. I support that PCN marking or CE be passed = to endpoint.

 

However the friends of MPLS = shouldn't be left without a PCN solution. I

currently can't imagine, how single marking could be downpropagated to an

IP packet following the above = coding scheme in a reasonable way.

Especially if your backbone works = with pen ultimate hop popping of labels.

So in the MPLS case, probably a = different solution is required.

 

 

 

From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Jozef Babiarz
Sent: Sunday, March 30, = 2008 9:10 PM
To: pcn@ietf.org
Subject: [PCN] Single = DSCP for Admission and Flow Termination Marking

I was thinking about the encoding and tunneling problem for PCN and I = think there may be a method by which a single DSCP and the ECN field can be used to = signal both admission control and flow termination using ECN bits. Would like = others to think about this and point out any issues that I may have = missed.

The proposed approach can use the EF-admit DSCP for = PCN.

My assumptions:

The EF-admit DSCP is used for end-to-end admission control as proposed by = Fred Baker and the PCN wg also reuses this DSCP for PCN based admission = control and flow termination function for edge-to-edge. Should note that I believe = this can also be used for end-to-end PCN based admission and termination but this = is currently out of scope so I will not = discuss.

Proposed encoding:

A packet that is market with EF-admit DSCP means that it is admission = control with that ECN bits be used in the following = way:

ECN =3D 00, means that packet is not-PCN-capable and that admission control = is done some other way.

Interior nodes remark ECN =3D “01” packets to “11” if traffic rate is above = PCN-lower-rate.

Interior nodes remark ECN =3D “10” packets to “11” if traffic rate is above PCN-upper-rate. =

How it works:

For PCN based admission control this approach requires that = “probe” packet be sent at flow setup to determine if a new flow can be admitted. Example of a probe packet is a RSVP Path message sent = from ingress-edge-node to egress-edge-node. The RSVP Path packet is market = with EF-admit DSCP and has its ECN bits set to “01”. Interior nodes meter EF-admit packets against the PCN-lower-rate and the = result of the meter is passed to the marker where the marker = remarks “01” packet to “11” if PCN-lower-rate was = exceeded. The metering and marking behavior is the so called “threshold marking” as defined in CL or 3sm drafts for admission = control.

For PCN based flow termination, once a flow is admitted, = ingress-edge-node marks admitted PCN traffic with ECN bits to = “10”. Interior nodes meter EF-admit packets against = PCN-upper-rate and the results of the meter is passed to the marker where the maker = remarks “10” packets to “11” based on “excess-rate marking” with or without marking frequency = reduction.

The egress-edge-node knows if the “11” market = packet is a probe or it belongs to an admitted flow therefore it = can interpret what the marking means.

This sounds simple, so what have I missed?

This approach works with tunneling, = as ECN CE state is copied from outer to inner IP header = on de-encapsulation.

I believe that this marking = also satisfies guidelines in RFC4774.

Are there any conditions where this marking approach will not = work?

One final note:

If PCN wg decides to reuse the EF-admit DSCP for PCN than we = need to ask Fred Baker to add a statement in to his draft that the ECN bits in the IP header are used for other function and that RFC3168 does not = apply to EF-admit DSCP as per guidance in RFC4774.

Regards, = Joe

email:babiarz@nortel.com<= /p>

Telephone:613-763-6098

------_=_NextPart_001_01C8991D.7D50AF89-- --===============0054504892== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0054504892==-- From pcn-bounces@ietf.org Mon Apr 7 19:41:04 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4731B3A6955; Mon, 7 Apr 2008 19:41:04 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB1A93A6955 for ; Mon, 7 Apr 2008 19:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.005 X-Spam-Level: X-Spam-Status: No, score=-3.005 tagged_above=-999 required=5 tests=[AWL=1.293, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7W07XzTgehvt for ; Mon, 7 Apr 2008 19:40:48 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id C33043A68EE for ; Mon, 7 Apr 2008 19:40:47 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m382et004262; Tue, 8 Apr 2008 02:40:56 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 22:40:39 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB64651561B4DF@zcarhxm1.corp.nortel.com> In-Reply-To: <1B6169C658325341A3B8066E23919E1C010BC9EE@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN in MPLS Network Thread-Index: AciSmam/Ae1M4lI9Ra60kF9c/KnbMQDk6SywAFxSoRAAKInesAAPjG6AACe0KxA= References: <9671A92C3C8B5744BC97F855F7CB6465153C513F@zcarhxm1.corp.nortel.com> <1B6169C658325341A3B8066E23919E1C010BC6D7@S4DE8PSAANK.mitte.t-com.de> <9671A92C3C8B5744BC97F855F7CB6465155B99C7@zcarhxm1.corp.nortel.com> <9671A92C3C8B5744BC97F855F7CB6465155B9ADE@zcarhxm1.corp.nortel.com> <1B6169C658325341A3B8066E23919E1C010BC9EE@S4DE8PSAANK.mitte.t-com.de> From: "Jozef Babiarz" To: "Geib, Ruediger" Cc: pcn@ietf.org Subject: Re: [PCN] PCN in MPLS Network X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0682170918==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0682170918== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89921.F0199851" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89921.F0199851 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ruediger, =20 My point that I was trying to make is that, I believe that only = admission control will be useful in MPLS network, therefore in MPLS = networks only two encoding will be used.=20 =20 However, in IP networks, I believe that flow termination will be useful = and defining a marking method using ECN bits and a single DS codepoint = that can support reliably admission control and flow termination in most = deployments is what the workgroup should be striving for. I do not agree = with the notion that we can not have marking method for admission = control and one for flow termination (3 states) and the only way forward = is single marking approach (2 states). Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 ________________________________ From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: April 7, 2008 3:28 AM To: Babiarz, Jozef (CAR:0S03) Cc: pcn@ietf.org Subject: RE: [PCN] PCN in MPLS Network =20 Hi Joe, =20 I've mentioned that in my other mail, but I'm happy to repeat it here: =20 - the network is running LDP, - it is engineered to maintain an SLA under regular operational = conditions (ie. including single outages), - all routers are DiffServ enabled. =20 Our backbone engineering departement is extremly careful with assigning = additional EXP values for any feature in the core network. As I don't = like termination (and I think to recall that someone mentioned it is = forbidden in Germany), I'm looking at admission control as the only = feature required by PCN. To avoid long term admission stop intervals, = I'm favouring to pass on network to end CE marked packets.=20 =20 If I understand your message right, we are largely in agreement. =20 Regards, =20 Rudiger =20 =09 ________________________________ From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: Monday, April 07, 2008 2:36 AM To: Jozef Babiarz; Geib, R=FCdiger Cc: pcn@ietf.org Subject: RE: [PCN] PCN in MPLS Network Ruediger, Are you interested in using PCN in MPLS network? What kind of MPLS = network are you running? Do you need both admission control and flow = termination mechanism and why? =20 In MPLS network the 3 EXP bits (8 states) can be used to signal = different network treatment. Operators can assign and use the 8 states = as encoding by the 3 EXP bits to indicate that this traffic is = PCN-capable, traffic level is above PCN-lower-rate and/or = PCN-upper-rate, etc. To support PCN, 2 or 3 out of 8 states would be = need. The other 5 or 6 encoding states can be used for QoS and ECN. =20 I have been thinking about PCN in MPLS and have come up with one = example where I think it would be useful. MPLS Network does not support TE and PCN is used to limit the amount of = traffic that can be admitted. In this example I do not believe that flow = termination would be useful. So on 2 encoding states are needed. =20 Can someone give me an MPLS example that would benefit from use PCN = flow termination and admission control? Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 =09 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Babiarz, Jozef (CAR:0S03) Sent: April 6, 2008 12:55 AM To: Geib, Ruediger Cc: pcn@ietf.org Subject: Re: [PCN] Single DSCP for Admission and Flow Termination = Marking =20 See comments below. =20 Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 =09 ________________________________ From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: April 4, 2008 4:52 AM To: Babiarz, Jozef (CAR:0S03) Cc: pcn@ietf.org Subject: RE: [PCN] Single DSCP for Admission and Flow Termination = Marking =20 Hi Joe, =20 congratulations, smart engineering. =20 Some initial thoughts: =20 - a PCN policer counts all packets belonging to the EF-admit DSCP. = After=20 the lower threshold is passed, a certain type is remarked, after the = upper=20 has been passed, all are remarked. - you mention probing, but I'm not sure we should call it that. We are = in=20 agreement, that the RSVP path message must be sent anyway. What=20 we talk about is an encoding option at the ingress and a specific=20 marking behaviour at the core. [Joe] I'm OK with not calling it probing. =20 Two questions: - is it possible to realise your proposal with a token bucket policer? = I guess=20 not, because the policer counts all packets of a certain DSCP, but it = modifies only part of all. This seems to resemble the behaviour of a=20 hyrachical policer. Which doesn't have to be bad - its just that = hyrachical=20 schedulers aren't a commodity in backbone routers these days. [Joe] Yes it's possible. I have modified a token bucket policer on one = of our routers in the lab to do this type of marking.=20 Used one TB for PCN-lower-rate and second TB for PCN-upper-rate. =20 - the ingress must mark RSVP refresh messages differently than initial=20 messages. I may be wrong, but RSVP refreshes don't look different = than=20 initial set up messages. The only difference is, that a node = registers state=20 has been set up already. The differentiation is required to avoid an = admission=20 stop to result in a termination. [Joe] I would assume the RSVP refresh message would be sent with the = same ECN markings as the RSVP PATH message. The egress know that this is = RSVP packet (I still think that we should call it probe packet) and that = reflects current traffic level against PCN-lower-rate (admission).=20 =20 Then let's come to one of my favorite subjects, MPLS interoperability. = Too bad,=20 that doesn't work. You can optimistically squeeze one EXP codepoint = from=20 the MPLS bunch. So there (and I guess for Ethernet too), an SM proposal = will be it. That's bad in these networks and shouldn't avoid smarter = solutions=20 in the IP network. [Joe] In MPLS networks, I think that you only need one PCN mechanism = and that is admission control. In my view why do you need flow = termination when you have engineered LSPs with fast-reroute? If you = large LSPs SM works fine. =20 However the friends of MPLS shouldn't be left without a PCN solution. I = currently can't imagine, how single marking could be downpropagated to = an=20 IP packet following the above coding scheme in a reasonable way.=20 Especially if your backbone works with pen ultimate hop popping of = labels. So in the MPLS case, probably a different solution is required. =20 =20 =20 =09 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Jozef Babiarz Sent: Sunday, March 30, 2008 9:10 PM To: pcn@ietf.org Subject: [PCN] Single DSCP for Admission and Flow Termination Marking I was thinking about the encoding and tunneling problem for PCN and I = think there may be a method by which a single DSCP and the ECN field can = be used to signal both admission control and flow termination using ECN = bits. Would like others to think about this and point out any issues = that I may have missed. The proposed approach can use the EF-admit DSCP for PCN. My assumptions: The EF-admit DSCP is used for end-to-end admission control as proposed = by Fred Baker and the PCN wg also reuses this DSCP for PCN based = admission control and flow termination function for edge-to-edge. Should = note that I believe this can also be used for end-to-end PCN based = admission and termination but this is currently out of scope so I will = not discuss. Proposed encoding: A packet that is market with EF-admit DSCP means that it is admission = control with that ECN bits be used in the following way: ECN =3D 00, means that packet is not-PCN-capable and that admission = control is done some other way. Interior nodes remark ECN =3D "01" packets to "11" if traffic rate is = above PCN-lower-rate. Interior nodes remark ECN =3D "10" packets to "11" if traffic rate is = above PCN-upper-rate.=20 How it works: For PCN based admission control this approach requires that "probe" = packet be sent at flow setup to determine if a new flow can be admitted. = Example of a probe packet is a RSVP Path message sent from = ingress-edge-node to egress-edge-node. The RSVP Path packet is market = with EF-admit DSCP and has its ECN bits set to "01". Interior nodes = meter EF-admit packets against the PCN-lower-rate and the result of the = meter is passed to the marker where the marker remarks "01" packet to = "11" if PCN-lower-rate was exceeded. The metering and marking behavior = is the so called "threshold marking" as defined in CL or 3sm drafts for = admission control. For PCN based flow termination, once a flow is admitted, = ingress-edge-node marks admitted PCN traffic with ECN bits to "10". = Interior nodes meter EF-admit packets against PCN-upper-rate and the = results of the meter is passed to the marker where the maker remarks = "10" packets to "11" based on "excess-rate marking" with or without = marking frequency reduction.=20 The egress-edge-node knows if the "11" market packet is a probe or it = belongs to an admitted flow therefore it can interpret what the marking = means.=20 This sounds simple, so what have I missed?=20 This approach works with tunneling, as ECN CE state is copied from = outer to inner IP header on de-encapsulation. I believe that this marking also satisfies guidelines in RFC4774. Are there any conditions where this marking approach will not work? One final note: If PCN wg decides to reuse the EF-admit DSCP for PCN than we need to = ask Fred Baker to add a statement in to his draft that the ECN bits in = the IP header are used for other function and that RFC3168 does not = apply to EF-admit DSCP as per guidance in RFC4774. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 ------_=_NextPart_001_01C89921.F0199851 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Single DSCP for Admission and Flow Termination Marking

Hi = Ruediger,

 

My point that I was trying to make = is that, I believe that only admission control will be useful in MPLS = network, therefore in MPLS networks only two encoding will be used. =

 

However, in IP networks, I believe = that flow termination will be useful and defining a marking method using ECN = bits and a single DS codepoint that can support reliably admission control and = flow termination in most deployments is what the workgroup should be striving = for. I do not agree with the notion that we can not have marking method for = admission control and one for flow termination (3 states) and the only way forward = is single marking approach (2 states).

Regards, = Joe
email:babiarz@nortel.com
Telephone:613-763-6098

From: Geib, = Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: April 7, 2008 3:28 = AM
To: Babiarz, Jozef (CAR:0S03)
Cc: pcn@ietf.org
Subject: RE: [PCN] PCN in = MPLS Network

 

Hi = Joe,

 

I've mentioned that in my other = mail, but I'm happy to repeat it here:

 

- the network is running = LDP,

- it is engineered to maintain an = SLA under regular operational conditions (ie. = including single outages),

- all routers are DiffServ = enabled.

 

Our backbone engineering = departement is extremly careful with assigning additional EXP values for any feature in = the core network. As I don't like termination (and I think to recall that = someone mentioned it is forbidden in Germany), I'm looking at admission control as the only feature required = by PCN. To avoid long term admission stop intervals, I'm favouring to pass = on network to end CE marked packets.

 

If I understand your message right, = we are largely in agreement.

 

Regards,

 

Rudiger

=

 

From: Jozef Babiarz [mailto:babiarz@nortel.com]
Sent: Monday, April 07, = 2008 2:36 AM
To: Jozef Babiarz; Geib, = R=FCdiger
Cc: pcn@ietf.org
Subject: RE: [PCN] PCN in = MPLS Network

Ruediger,

Are you interested in using PCN in = MPLS network? What kind of MPLS network are you running? Do you need both = admission control and flow termination mechanism and = why?

 

In MPLS network the 3 EXP bits (8 = states) can be used to signal different network treatment. Operators can assign = and use the 8 states as encoding by the 3 EXP bits to indicate that this traffic = is PCN-capable, traffic level is above PCN-lower-rate and/or = PCN-upper-rate, etc. To support PCN, 2 or 3 out of 8 states would be need. The other 5 or 6 = encoding states can be used for QoS and ECN.

 

I have been thinking about PCN in = MPLS and have come up with one example where I think it would be = useful.

MPLS Network does not support TE = and PCN is used to limit the amount of traffic that can be admitted. In this = example I do not believe that flow termination would be useful. So on 2 encoding = states are needed.

 

Can someone give me an MPLS example = that would benefit from use PCN flow termination and admission = control?

Regards, = Joe
email:babiarz@nortel.com
Telephone:613-763-6098

From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Babiarz, = Jozef (CAR:0S03)
Sent: April 6, 2008 12:55 = AM
To: Geib, Ruediger
Cc: pcn@ietf.org
Subject: Re: [PCN] Single = DSCP for Admission and Flow Termination Marking

 

See comments = below.

 

Regards, = Joe
email:babiarz@nortel.com
Telephone:613-763-6098

From: Geib, = Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: April 4, 2008 4:52 = AM
To: Babiarz, Jozef (CAR:0S03)
Cc: pcn@ietf.org
Subject: RE: [PCN] Single = DSCP for Admission and Flow Termination Marking

 

Hi = Joe,

 

congratulations, smart = engineering.

 

Some initial = thoughts:

 

- a PCN policer counts = all packets belonging to the EF-admit DSCP. = After 

  the lower threshold is = passed, a certain type is remarked, after the upper =

  has been passed, all are = remarked.

- you mention probing, but I'm not = sure we should call it that. We are in

  agreement, that the RSVP = path message must be sent anyway. What

  we talk about is an encoding option at the ingress and a specific =

  marking behaviour at the = core.

[Joe] I’m OK with not calling it = probing.

 

Two = questions:

- is it possible to realise your = proposal with a token bucket policer? I guess

  not, because the policer = counts all packets of a certain DSCP, but it

  modifies only part of all. This seems to resemble the behaviour of a =

  = hyrachical policer. Which doesn't have to be bad - its just that hyrachical =

  schedulers aren't a = commodity in backbone routers these days.

[Joe] Yes it’s possible. I have modified a = token bucket policer on one of our routers in the lab to do this type of = marking.

Used one TB for PCN-lower-rate and second TB for PCN-upper-rate.

 

- the ingress must mark = RSVP refresh messages differently than initial

  messages. I may be wrong, = but RSVP refreshes don't look different than

  initial set up messages. The = only difference is, that a node registers state

  has been set up already. The differentiation is required to avoid an admission =

  stop to result in a = termination.

[Joe] I would assume the RSVP refresh message would = be sent with the same ECN markings as the RSVP PATH message. The egress know = that this is RSVP packet (I still think that we should call it probe packet) and = that reflects current traffic level against PCN-lower-rate (admission). =

 

Then let's come to one of my = favorite subjects, MPLS interoperability. Too bad,

that doesn't work. You can = optimistically squeeze one EXP codepoint from

the MPLS bunch. So there (and I = guess for Ethernet too), an SM proposal

will be it. That's bad in these = networks and shouldn't avoid smarter solutions

in the IP = network.

[Joe] In MPLS networks, I think that you only need = one PCN mechanism and that is admission control. In my view why do you need flow termination when you have engineered LSPs with fast-reroute? If you = large LSPs SM works fine.

 

However the friends of MPLS = shouldn't be left without a PCN solution. I

currently can't imagine, how single marking could be downpropagated to an

IP packet following the above = coding scheme in a reasonable way.

Especially if your backbone works = with pen ultimate hop popping of labels.

So in the MPLS case, probably a = different solution is required.

 

 

 

From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Jozef Babiarz
Sent: Sunday, March 30, = 2008 9:10 PM
To: pcn@ietf.org
Subject: [PCN] Single = DSCP for Admission and Flow Termination Marking

I was thinking about the encoding and tunneling problem for PCN and I = think there may be a method by which a single DSCP and the ECN field can be used to = signal both admission control and flow termination using ECN bits. Would like = others to think about this and point out any issues that I may have = missed.

The proposed approach can use the EF-admit DSCP for = PCN.

My assumptions:

The EF-admit DSCP is used for end-to-end admission control as proposed by = Fred Baker and the PCN wg also reuses this DSCP for PCN based admission = control and flow termination function for edge-to-edge. Should note that I believe = this can also be used for end-to-end PCN based admission and termination but this = is currently out of scope so I will not = discuss.

Proposed encoding:

A packet that is market with EF-admit DSCP means that it is admission = control with that ECN bits be used in the following = way:

ECN =3D 00, means that packet is not-PCN-capable and that admission control = is done some other way.

Interior nodes remark ECN =3D “01” packets to “11” if traffic rate is above = PCN-lower-rate.

Interior nodes remark ECN =3D “10” packets to “11” if traffic rate is above PCN-upper-rate. =

How it works:

For PCN based admission control this approach requires that = “probe” packet be sent at flow setup to determine if a new flow can be admitted. Example of a probe packet is a RSVP Path message sent = from ingress-edge-node to egress-edge-node. The RSVP Path packet is market = with EF-admit DSCP and has its ECN bits set to “01”. Interior nodes meter EF-admit packets against the PCN-lower-rate and the = result of the meter is passed to the marker where the marker = remarks “01” packet to “11” if PCN-lower-rate was = exceeded. The metering and marking behavior is the so called “threshold marking” as defined in CL or 3sm drafts for admission = control.

For PCN based flow termination, once a flow is admitted, = ingress-edge-node marks admitted PCN traffic with ECN bits to = “10”. Interior nodes meter EF-admit packets against = PCN-upper-rate and the results of the meter is passed to the marker where the maker = remarks “10” packets to “11” based on “excess-rate marking” with or without marking frequency = reduction.

The egress-edge-node knows if the “11” market = packet is a probe or it belongs to an admitted flow therefore it = can interpret what the marking means.

This sounds simple, so what have I missed?

This approach works with tunneling, = as ECN CE state is copied from outer to inner IP header = on de-encapsulation.

I believe that this marking = also satisfies guidelines in RFC4774.

Are there any conditions where this marking approach will not = work?

One final note:

If PCN wg decides to reuse the EF-admit DSCP for PCN than we = need to ask Fred Baker to add a statement in to his draft that the ECN bits in the IP header are used for other function and that RFC3168 does not = apply to EF-admit DSCP as per guidance in RFC4774.

Regards, = Joe

email:babiarz@nortel.com<= /p>

Telephone:613-763-6098

------_=_NextPart_001_01C89921.F0199851-- --===============0682170918== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0682170918==-- From pcn-bounces@ietf.org Wed Apr 9 18:34:27 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 507B93A6969; Wed, 9 Apr 2008 18:34:27 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F6273A68BC for ; Wed, 9 Apr 2008 18:34:25 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8z+pcen-pym for ; Wed, 9 Apr 2008 18:34:24 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 969543A6841 for ; Wed, 9 Apr 2008 18:34:24 -0700 (PDT) Received: from cpe-071-077-051-004.nc.res.rr.com ([71.77.51.4]) by elom.tchmachines.com with esmtpa (Exim 4.68) (envelope-from ) id 1JjlgX-0006Xo-HW for pcn@ietf.org; Wed, 09 Apr 2008 21:34:41 -0400 From: Steven Blake To: pcn Date: Wed, 09 Apr 2008 21:34:42 -0400 Message-Id: <1207791282.10491.35.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: [PCN] PCN response to ITU-T liaison X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org ITU-T Study Group 11 sent the PCN working a liaison statement in February, titled: "Intended work on the application of PCN in a RACF-controlled environment". The statement is available at: https://datatracker.ietf.org/liaison/423/ The chairs have drafted the following liaison response. We would like to have working group consensus on this response before sending it to SG11. Please send comments to the list within the next two weeks. ------------------------- To: ITU-T Study Group 11 Thank you for your liaison from your Seoul meeting on your intent to utilize PCN in a RACF-controlled environment. At this time, key details of the PCN architecture, such as packet encoding, interior node marking behaviors, and edge node computations and communication flows, still remain to be decided. Hence it would be premature for the ITU-T to begin work on the use of PCN in a RACF-controlled environment. We encourage you to continue monitoring developments in the PCN working group, and to keep us informed as you investigate the requirements of using the IETF PCN architecture and protocols in a RACF-controlled environment. Thank you, Scott Bradner and Steven Blake, PCN working group co-chairs // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Apr 9 18:35:32 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735BF3A6969; Wed, 9 Apr 2008 18:35:32 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0748E3A6807 for ; Wed, 9 Apr 2008 18:35:31 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0352hTRFUcK6 for ; Wed, 9 Apr 2008 18:35:30 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 396D63A6AD2 for ; Wed, 9 Apr 2008 18:35:21 -0700 (PDT) Received: from cpe-071-077-051-004.nc.res.rr.com ([71.77.51.4]) by elom.tchmachines.com with esmtpa (Exim 4.68) (envelope-from ) id 1JjlhS-0006yc-CW for pcn@ietf.org; Wed, 09 Apr 2008 21:35:38 -0400 From: Steven Blake To: pcn In-Reply-To: <1206983895.3561.12.camel@neutrino> References: <1206983895.3561.12.camel@neutrino> Date: Wed, 09 Apr 2008 21:35:39 -0400 Message-Id: <1207791339.10491.37.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On Mon, 2008-03-31 at 13:18 -0400, Steven Blake wrote: > Here are the remaining three questions that were taken during the IETF > 71 meeting: > > Q4: Should the standards-track PCN scheme require (as a MUST implement > feature) that interior PCN routers support Excess-Rate marking, > according to the particular method of handling already marked > packets and drops described in Anna Charny's presentation? > http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf > > Q5: Should the standards-track PCN scheme require (as a MUST implement > feature) that interior PCN routers support Threshold marking (in > addition to Excess-Rate marking), according to the particular method > described in Philip Eardley's presentation on Tuesday? > http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf > > Q6: If presented with sufficient evidence in a timely fashion, would > the PCN wg entertain the option of modifying the interior router > Excess-Rate marking behavior for the standards-track PCN scheme (as > described in question 4)? > > According to the draft meeting minutes, Q4 was accepted 8-0 (my notes > have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0. > > Please send comments to the list during the next few days. Any last comments? // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Apr 10 01:13:17 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A361E3A6F22; Thu, 10 Apr 2008 01:13:17 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099833A6F21 for ; Thu, 10 Apr 2008 01:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=1.151, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRF+PBoDacw8 for ; Thu, 10 Apr 2008 01:13:12 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 99A973A6F12 for ; Thu, 10 Apr 2008 01:13:11 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Thu, 10 Apr 2008 10:13:30 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Apr 2008 10:13:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Apr 2008 10:15:14 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C0113514A@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1207791282.10491.35.camel@tachyon> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN response to ITU-T liaison thread-index: AciaqxFLV3TE7gC+RT6pkFjcpPxPMgANpw5g References: <1207791282.10491.35.camel@tachyon> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 10 Apr 2008 08:13:29.0356 (UTC) FILETIME=[C252ECC0:01C89AE2] Cc: pcn@ietf.org Subject: Re: [PCN] PCN response to ITU-T liaison X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Steve, I have no objections to the proposed liaison response text. A question is, which architecture is assumed to support RACF. I'm not an expert there, but I wouldn't wonder if it is a centralised functionality. And the alternative reference document to be found in the ITU doc point to this direction (COPS, H.248 and DIAMETER). I don't regard this as a bad thing per se, as I didn't finally make up my mind on the best possible solution (Joe's last proposal on marking however requires on path signaling). What I want to say is, we should be careful here to avoid ITU to put architectural constraints on our work. Regards, Rudiger | -----Original Message----- | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | Behalf Of Steven Blake | Sent: Thursday, April 10, 2008 3:35 AM | To: pcn | Subject: [PCN] PCN response to ITU-T liaison | | ITU-T Study Group 11 sent the PCN working a liaison statement | in February, titled: "Intended work on the application of PCN | in a RACF-controlled environment". The statement is available at: | | https://datatracker.ietf.org/liaison/423/ | | The chairs have drafted the following liaison response. We | would like to have working group consensus on this response | before sending it to SG11. Please send comments to the list | within the next two weeks. | | ------------------------- | | To: ITU-T Study Group 11 | | Thank you for your liaison from your Seoul meeting on your | intent to utilize PCN in a RACF-controlled environment. | | At this time, key details of the PCN architecture, such as | packet encoding, interior node marking behaviors, and edge | node computations and communication flows, still remain to be | decided. Hence it would be premature for the ITU-T to begin | work on the use of PCN in a RACF-controlled environment. | | We encourage you to continue monitoring developments in the | PCN working group, and to keep us informed as you investigate | the requirements of using the IETF PCN architecture and | protocols in a RACF-controlled environment. | | Thank you, | | Scott Bradner and Steven Blake, PCN working group co-chairs | | | | // Steve | | _______________________________________________ | PCN mailing list | PCN@ietf.org | https://www.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Apr 10 09:22:29 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54C4F3A6D87; Thu, 10 Apr 2008 09:22:29 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EF7D3A6D76 for ; Thu, 10 Apr 2008 09:22:28 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hlG7B64J8gw for ; Thu, 10 Apr 2008 09:22:24 -0700 (PDT) Received: from smtp102.rog.mail.re2.yahoo.com (smtp102.rog.mail.re2.yahoo.com [206.190.36.80]) by core3.amsl.com (Postfix) with SMTP id 452BC3A6D5D for ; Thu, 10 Apr 2008 09:22:24 -0700 (PDT) Received: (qmail 54434 invoked from network); 10 Apr 2008 16:22:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=xyLSk6N8FIZ6zxDeiJESNpkWxAP2C9hJMxkP/kdIhtkoOM0G9wVHTrYgAk6pR7SWpn7OyQWzo66xb+uEcXzutuMoTT8t6hXr/OvAGweC/JKUMzPThjWD2RQbE3mzoXA50Qs00Y15kQX1qk70WuWgfsbjYIemNqrafPNiWSAD9lo= ; Received: from unknown (HELO ?192.168.10.134?) (tom.taylor@rogers.com@116.30.157.102 with plain) by smtp102.rog.mail.re2.yahoo.com with SMTP; 10 Apr 2008 16:22:39 -0000 X-YMail-OSG: 7sYPPzIVM1kJcuzPCqWIf9HlAjdi31XNHKi8qc4uXZTV9YA.wiGA9T0alwQp1T4Tpg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <47FE3EBE.6060303@rogers.com> Date: Thu, 10 Apr 2008 12:22:22 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Steven Blake References: <1207791282.10491.35.camel@tachyon> In-Reply-To: <1207791282.10491.35.camel@tachyon> Cc: pcn Subject: Re: [PCN] PCN response to ITU-T liaison X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org My internet connection is so poor tonight I haven't been able to finish downloading my messages. It's pretty late at night where I am at the moment, so I figure I'd better respond to this one regardless of what else follows in the list and get to bed. As I argued in our meeting with management, the broad structure of PCN has been set. What is the essential subject matter for the PCN WG is more on the level of detail when considering how to apply PCN in a RACF-controlled environment. I agree that the ITU-T should proceed with caution, and clearly should not produce a final document before the PCN WG has delivered. I also agree that the ITU-T's initial work should be on requirements, to the benefit of both themselves and the PCN WG. However, I also believe that because the ITU-T is building a framework around PCN rather than working on the protocol itself, it may well be possible that the ITU-T can accomplish some design work in advance of completion of PCN design. Bottom line: rather than "premature for the ITU-T to begin work ..." I think it reasonable to say "be advisable for the ITU-T to use caution in their work ...". Steven Blake wrote: > ITU-T Study Group 11 sent the PCN working a liaison statement in > February, titled: "Intended work on the application of PCN in a > RACF-controlled environment". The statement is available at: > > https://datatracker.ietf.org/liaison/423/ > > The chairs have drafted the following liaison response. We would like > to have working group consensus on this response before sending it to > SG11. Please send comments to the list within the next two weeks. > > ------------------------- > > To: ITU-T Study Group 11 > > Thank you for your liaison from your Seoul meeting on > your intent to utilize PCN in a RACF-controlled environment. > > At this time, key details of the PCN architecture, such as packet > encoding, interior node marking behaviors, and edge node computations > and communication flows, still remain to be decided. Hence it would be > premature for the ITU-T to begin work on the use of PCN in a > RACF-controlled environment. > > We encourage you to continue monitoring developments in the PCN working > group, and to keep us informed as you investigate the requirements of > using the IETF PCN architecture and protocols in a RACF-controlled > environment. > > Thank you, > > Scott Bradner and Steven Blake, PCN working group co-chairs > > > > // Steve > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Apr 20 10:12:21 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708CA3A6BF4; Sun, 20 Apr 2008 10:12:21 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 925543A6BB5 for ; Sun, 20 Apr 2008 10:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4F+EMEJCE-WW for ; Sun, 20 Apr 2008 10:12:18 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id B38633A6B08 for ; Sun, 20 Apr 2008 10:12:18 -0700 (PDT) Received: from cpe-071-077-051-004.nc.res.rr.com ([71.77.51.4]) by elom.tchmachines.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jnd5T-00076k-1t; Sun, 20 Apr 2008 13:12:23 -0400 From: Steven Blake To: "Geib, Ruediger" In-Reply-To: <1B6169C658325341A3B8066E23919E1C0113514A@S4DE8PSAANK.mitte.t-com.de> References: <1207791282.10491.35.camel@tachyon> <1B6169C658325341A3B8066E23919E1C0113514A@S4DE8PSAANK.mitte.t-com.de> Date: Sun, 20 Apr 2008 13:12:23 -0400 Message-Id: <1208711543.3483.6.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: pcn@ietf.org Subject: Re: [PCN] PCN response to ITU-T liaison X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On Thu, 2008-04-10 at 10:15 +0200, Geib, Ruediger wrote: > Steve, > > I have no objections to the proposed liaison response text. > > A question is, which architecture is assumed to support RACF. > I'm not an expert there, but I wouldn't wonder if it is a > centralised functionality. And the alternative reference > document to be found in the ITU doc point to this direction > (COPS, H.248 and DIAMETER). I don't regard this as a bad > thing per se, as I didn't finally make up my mind on the > best possible solution (Joe's last proposal on marking > however requires on path signaling). What I want to say is, > we should be careful here to avoid ITU to put architectural > constraints on our work. Ruediger, I believe the ITU-T work assumes some centralized component(s) in the architecture. On the other hand, I don't believe that what they have in mind at the moment imposes any architectural constraints on PCN. Your point is well taken. Note: I will be (mostly) off line over the next week. Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Apr 20 10:14:21 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB21E3A6DF1; Sun, 20 Apr 2008 10:14:21 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06E993A6DF1 for ; Sun, 20 Apr 2008 10:14:21 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lc-+LHbNhxSH for ; Sun, 20 Apr 2008 10:14:20 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 3C0483A6DC7 for ; Sun, 20 Apr 2008 10:14:20 -0700 (PDT) Received: from cpe-071-077-051-004.nc.res.rr.com ([71.77.51.4]) by elom.tchmachines.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jnd7R-0007DW-ME; Sun, 20 Apr 2008 13:14:25 -0400 From: Steven Blake To: Tom Taylor In-Reply-To: <47FE3EBE.6060303@rogers.com> References: <1207791282.10491.35.camel@tachyon> <47FE3EBE.6060303@rogers.com> Date: Sun, 20 Apr 2008 13:14:26 -0400 Message-Id: <1208711666.3483.10.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: pcn Subject: Re: [PCN] PCN response to ITU-T liaison X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On Thu, 2008-04-10 at 12:22 -0400, Tom Taylor wrote: > My internet connection is so poor tonight I haven't been able to finish > downloading my messages. It's pretty late at night where I am at the moment, so > I figure I'd better respond to this one regardless of what else follows in the > list and get to bed. > > As I argued in our meeting with management, the broad structure of PCN has been > set. What is the essential subject matter for the PCN WG is more on the level of > detail when considering how to apply PCN in a RACF-controlled environment. I > agree that the ITU-T should proceed with caution, and clearly should not produce > a final document before the PCN WG has delivered. I also agree that the ITU-T's > initial work should be on requirements, to the benefit of both themselves and > the PCN WG. However, I also believe that because the ITU-T is building a > framework around PCN rather than working on the protocol itself, it may well be > possible that the ITU-T can accomplish some design work in advance of completion > of PCN design. > > Bottom line: rather than "premature for the ITU-T to begin work ..." I think it > reasonable to say "be advisable for the ITU-T to use caution in their work ...". Tom, I don't object to this re-phrasing. Note: I will be (mostly) off line over the next week. Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Apr 20 10:41:42 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CDB23A6D46; Sun, 20 Apr 2008 10:41:42 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3DEE3A6C88 for ; Sun, 20 Apr 2008 10:41:40 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuV6YkuNQN9J for ; Sun, 20 Apr 2008 10:41:39 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id DD52828C23B for ; Sun, 20 Apr 2008 10:40:59 -0700 (PDT) Received: from cpe-071-077-051-004.nc.res.rr.com ([71.77.51.4]) by elom.tchmachines.com with esmtpa (Exim 4.68) (envelope-from ) id 1JndXF-0007CC-BR for pcn@ietf.org; Sun, 20 Apr 2008 13:41:05 -0400 From: Steven Blake To: pcn In-Reply-To: <1206983895.3561.12.camel@neutrino> References: <1206983895.3561.12.camel@neutrino> Date: Sun, 20 Apr 2008 13:41:05 -0400 Message-Id: <1208713265.3483.27.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On Mon, 2008-03-31 at 13:18 -0400, Steven Blake wrote: > Here are the remaining three questions that were taken during the IETF > 71 meeting: > > Q4: Should the standards-track PCN scheme require (as a MUST implement > feature) that interior PCN routers support Excess-Rate marking, > according to the particular method of handling already marked > packets and drops described in Anna Charny's presentation? > http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf > > Q5: Should the standards-track PCN scheme require (as a MUST implement > feature) that interior PCN routers support Threshold marking (in > addition to Excess-Rate marking), according to the particular method > described in Philip Eardley's presentation on Tuesday? > http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf > > Q6: If presented with sufficient evidence in a timely fashion, would > the PCN wg entertain the option of modifying the interior router > Excess-Rate marking behavior for the standards-track PCN scheme (as > described in question 4)? > > According to the draft meeting minutes, Q4 was accepted 8-0 (my notes > have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0. The feedback from the list for Q4 and Q5 seems to match up closely with the results in the meeting (not surprising, as it was mostly the same individuals commenting). I counted one dissent for Q4 and one for Q5. The feedback for Q6 was a mixture of abstain and Yes with caveats. If and when someone wants to propose modifications to the Excess-Rate marking behavior, we can see if there is interest to discuss it on the list, but I *strongly encourage* that any such discussion needs to happen before the Dublin meeting. We seem to have consensus to go forward with a standards-track proposal supporting two encoding states, with Excess-Rate and Threshold marking as MUST implement features. In addition, we are open to work on one or more experimental-track proposals (as a lower priority acitivity) that are extensions of the standards-track proposal, using an additional encoding state. This is a call for volunteers to start working on drafts for the standards-track interior node detection, (in-band) PCN encoding, egress-ingress feedback protocol, and boundary node mechanisms, as spelled out in the PCN charter. Note: I will be (mostly) off line for the rest of the week. Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Apr 21 09:41:46 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA28E28C273; Mon, 21 Apr 2008 09:41:46 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C192B28C279 for ; Mon, 21 Apr 2008 09:41:45 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m82cdFIUuWel for ; Mon, 21 Apr 2008 09:41:44 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id D502028C273 for ; Mon, 21 Apr 2008 09:41:43 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Apr 2008 17:41:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Apr 2008 17:41:44 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B3475A@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <1208713265.3483.27.camel@tachyon> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Consensus questions: Q4, Q5, and Q6 Thread-Index: AcijDdEhZTGFLwePTTiggUM/QqQ5UgAwCZpA From: To: X-OriginalArrivalTime: 21 Apr 2008 16:41:45.0340 (UTC) FILETIME=[95E40BC0:01C8A3CE] Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On the subject of Qu 4: Don't want to re-open this question, but I thought a bit more at the preferential dropping issue, ie if a PCN-node is overloaded and has to drop PCN-packets, should it preferentially drop any that are already PCN-marked (PCN-excess-rate-marked) - or preferentially drop ones that are not marked - or just randomly drop. (The first of these is where the WG consensus lies, and is also where this email ends up.) The preferential dropping behaviour matters when there's at least one pre-congested node 'before' the overloaded node ("two bottlenecks") The ideal answer depends on what the edge behaviour is: * the CL/SM edge mechanism measures the sustainable rate (the rate of unmarked pkts), and terminates rate above this. So ideally PCN-nodes should preferentially drop pkts that already PCN-(termination-)marked, otherwise too much PCN-traffic will be terminated if there are two bottlenecks. * The excess rate & EMFT mechanisms measure (react to) PCN-marked pkts. So ideally PCN-nodes should preferentially drop pkts that not PCN-(termination-)marked, otherwise PCN-traffic will be terminated slower if there are two bottlenecks. However, it would be good if the PCN-node behaviour allowed some flexibility in terms of the edge behaviour (at least we seem to have been implicitly assuming this). Their pros/cons are: * CL/SM edge behaviour: can terminate the right amount in a single shot (but can also terminate slower, if that's preferred); requires one msg from egress to ingress to indicate termination; but has to measure rates at both egress and ingress * Excess rate: in general terminates slower & so requires several msgs; requires rate measurement at the egress but not ingress * EMFT: doesn't need to measure any rate, but terminates slower and needs a msg for each flow that's terminated Consider two cases in more detail. [1] the operator sets the PCN-upper-rate at 95% of PCN-max-rate; [2] the operator sets the PCN-upper-rate at 50% of PCN-max-rate There's the PCN-upper-rate above which pkts are PCN-excess-rate-marked and the PCN-max-rate above which PCN-pkts are dropped. For case [1], with a single bottleneck that's overloaded (say at 5* PCN-max-rate), ie dropping pkts as well as marking pkts: * the CL/SM edge mechanism can terminate the right amount in one go. Termination is just as fast as when the bottleneck is pre-congested but not overloaded. * the excess rate mechanism measures the 5% of marked pkts. It terminates this amount - the link is now overloaded at 4.95* PCN-max-rate. This makes termination about 100* slower. * With EMFT, if the edge sees a marked pkt then it terminates this flow with some probability. This is similar to the previous case, so again termination is much much slower. However, it should be possible to speed up termination a bit by terminating a marked flow with a greater probability; the caution is that this increases the chances of over-terminating, because of the time lag after a termination decision before the rate reduces.) For case [2], the difference is not quite as great - termination is about 10* slower. Conclusion: an operator who wants to use its capacity "aggressively" by setting the PCN-upper-rate at 95% of PCN-max-rate must use the CL/SM edge mechanism. Now let's consider the two bottleneck case, with the first marking and the second dropping pkts. We only need to compare edge behaviours in case [2]. * if the overloaded node preferentially drop pkts that are already marked, then the result is (max) 50% are unmarked, 50% marked and the rest are dropped (0.5* PCN-max-rate unmarked = PCN-upper-rate; 0.5* PCN-max-rate marked; 4* PCN-max-rate dropped). This is exactly the same as in the single bottleneck case. Hence: o again, the CL/SM edge mechanism can terminate the right amount in one go. o Again, Excess rate /EMFT terminates at the same slow speed as in the single bottleneck case * if the overloaded node preferentially drop pkts that are unmarked, then the result is all pkts are marked and the rest are dropped (1* PCN-max-rate marked; 4* PCN-max-rate dropped) o the CL/SM edge mechanism no longer works. All pkts are marked, so the sustainable rate is 0 & so it terminates all flows. o Excess rate /EMFT terminates about twice as fast as in the single bottleneck case (but still about 5* slower than the CL/SM mechanism achieves above) * if the overloaded node randomly drops pkts that are already marked, then the result is roughly 10% are unmarked, 90% marked and the rest are dropped (0.1* PCN-max-rate unmarked; 0.9* PCN-max-rate marked; 4* PCN-max-rate dropped) o the CL/SM edge mechanism terminates 5* too much (sustainable rate is only 20% of what it really is) o Excess rate /EMFT terminates towards twice as fast as in the single bottleneck case (but still over 5* slower than the CL/SM mechanism achieves above) Conclusion: * if the overloaded node preferentially drop pkts that are unmarked, then the CL/SM edge behaviour is not possible - so this option can be excluded. * if the overloaded node randomly drops pkts that are already marked, then the CL/SM edge mechanism terminates far too much. The CL/SM mechanism could be deliberately slowed down in order to reduce the risk of over-termination. However, this creates a penalty of slower termination in the single bottleneck case. The operator also needs to guess what the highest level of overload is/ The above is intended to be purely descriptive. Now to give my opinion. I believe it means that the standard should specify that an overloaded node SHOULD preferentially drop pkts that are already excess-rate marked: * it gives the operator as much freedom as possible on setting the PCN-upper-rate in relation to the PCN-max-rate. Otherwise it cannot set PCN-upper-rate close to PCN-max-rate. * It allows an operator to achieve termination to the correct rate in a single shot (providing they're prepared to do the work of measuring rates at egress & ingress). Otherwise they must *always* slow down termination, in case there are two bottlenecks when there could be far too much termination. * It allows an operator to achieve termination with a simpler mechanism like EMFT, albeit somewhat slower than would be achieved by different preferential dropping behaviour. However, such an operator has already accepted that, in the case where even one node is overloaded, termination will be much slower than with a CL/SM edge behaviour. In other words, such an operator has made the decision that the simpler edge mechanism (in terms of not having to measure rates) is important enough that they don't mind termination being slower than ideal if there's an overloaded node. Comments? Phil/ > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Steven Blake > Sent: 20 April 2008 18:41 > To: pcn > Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 > > On Mon, 2008-03-31 at 13:18 -0400, Steven Blake wrote: > > Here are the remaining three questions that were taken during the IETF > > 71 meeting: > > > > Q4: Should the standards-track PCN scheme require (as a MUST implement > > feature) that interior PCN routers support Excess-Rate marking, > > according to the particular method of handling already marked > > packets and drops described in Anna Charny's presentation? > > http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf > > > > Q5: Should the standards-track PCN scheme require (as a MUST implement > > feature) that interior PCN routers support Threshold marking (in > > addition to Excess-Rate marking), according to the particular method > > described in Philip Eardley's presentation on Tuesday? > > http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf > > > > Q6: If presented with sufficient evidence in a timely fashion, would > > the PCN wg entertain the option of modifying the interior router > > Excess-Rate marking behavior for the standards-track PCN scheme (as > > described in question 4)? > > > > According to the draft meeting minutes, Q4 was accepted 8-0 (my notes > > have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0. > > The feedback from the list for Q4 and Q5 seems to match up closely with > the results in the meeting (not surprising, as it was mostly the same > individuals commenting). I counted one dissent for Q4 and one for Q5. > > The feedback for Q6 was a mixture of abstain and Yes with caveats. If > and when someone wants to propose modifications to the Excess-Rate > marking behavior, we can see if there is interest to discuss it on the > list, but I *strongly encourage* that any such discussion needs to > happen before the Dublin meeting. > > We seem to have consensus to go forward with a standards-track proposal > supporting two encoding states, with Excess-Rate and Threshold marking > as MUST implement features. In addition, we are open to work on one or > more experimental-track proposals (as a lower priority acitivity) that > are extensions of the standards-track proposal, using an additional > encoding state. > > This is a call for volunteers to start working on drafts for the > standards-track interior node detection, (in-band) PCN encoding, > egress-ingress feedback protocol, and boundary node mechanisms, as > spelled out in the PCN charter. > > Note: I will be (mostly) off line for the rest of the week. > > > Regards, > > // Steve > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Apr 21 10:32:43 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF76728C436; Mon, 21 Apr 2008 10:32:43 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCACD28C433 for ; Mon, 21 Apr 2008 10:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkueiJx9MzBc for ; Mon, 21 Apr 2008 10:32:38 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 9A34328C439 for ; Mon, 21 Apr 2008 10:32:04 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id C2FB419AB49; Mon, 21 Apr 2008 19:32:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id B693519AB35; Mon, 21 Apr 2008 19:32:09 +0200 (CEST) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 7A28B19AA51; Mon, 21 Apr 2008 19:32:08 +0200 (CEST) Message-ID: <480CCF68.4010507@informatik.uni-wuerzburg.de> Date: Mon, 21 Apr 2008 19:31:20 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: philip.eardley@bt.com References: <75A199C5D243C741BF3D3F1EBCEF9BA503B3475A@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B3475A@E03MVZ1-UKDY.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, as your analysis showed, CL/SM require preferential dropping of marked packets. Other termination methods required preferential marking of unmarked packets. If PCN marking should be optimized for CL/SM at the expense of other solutions, preferential dropping of marked packets it the way to go. But this kind of marking is hardly of any use for other termination methods in challenging situations. So, if other solutions should not be excluded, preferential dropping of unmarked packets is also required as an option. Then it is probably also wise to have another option that does not do any preferential drop. The decision on preferential dropping limits the potential use of PCN marking or the number of architectural options. Regards, Michael philip.eardley@bt.com wrote: > On the subject of Qu 4: > Don't want to re-open this question, but I thought a bit more at the > preferential dropping issue, ie if a PCN-node is overloaded and has to > drop PCN-packets, should it preferentially drop any that are already > PCN-marked (PCN-excess-rate-marked) - or preferentially drop ones that > are not marked - or just randomly drop. (The first of these is where the > WG consensus lies, and is also where this email ends up.) > > The preferential dropping behaviour matters when there's at least one > pre-congested node 'before' the overloaded node ("two bottlenecks") > > The ideal answer depends on what the edge behaviour is: > * the CL/SM edge mechanism measures the sustainable rate (the rate > of unmarked pkts), and terminates rate above this. So ideally PCN-nodes > should preferentially drop pkts that already PCN-(termination-)marked, > otherwise too much PCN-traffic will be terminated if there are two > bottlenecks. > * The excess rate & EMFT mechanisms measure (react to) PCN-marked > pkts. So ideally PCN-nodes should preferentially drop pkts that not > PCN-(termination-)marked, otherwise PCN-traffic will be terminated > slower if there are two bottlenecks. > > However, it would be good if the PCN-node behaviour allowed some > flexibility in terms of the edge behaviour (at least we seem to have > been implicitly assuming this). Their pros/cons are: > * CL/SM edge behaviour: can terminate the right amount in a single > shot (but can also terminate slower, if that's preferred); requires one > msg from egress to ingress to indicate termination; but has to measure > rates at both egress and ingress > * Excess rate: in general terminates slower & so requires several > msgs; requires rate measurement at the egress but not ingress > * EMFT: doesn't need to measure any rate, but terminates slower > and needs a msg for each flow that's terminated > > Consider two cases in more detail. [1] the operator sets the > PCN-upper-rate at 95% of PCN-max-rate; [2] the operator sets the > PCN-upper-rate at 50% of PCN-max-rate There's the PCN-upper-rate above > which pkts are PCN-excess-rate-marked and the PCN-max-rate above which > PCN-pkts are dropped. > > For case [1], with a single bottleneck that's overloaded (say at 5* > PCN-max-rate), ie dropping pkts as well as marking pkts: > * the CL/SM edge mechanism can terminate the right amount in one > go. Termination is just as fast as when the bottleneck is pre-congested > but not overloaded. > * the excess rate mechanism measures the 5% of marked pkts. It > terminates this amount - the link is now overloaded at 4.95* > PCN-max-rate. This makes termination about 100* slower. > * With EMFT, if the edge sees a marked pkt then it terminates this > flow with some probability. This is similar to the previous case, so > again termination is much much slower. However, it should be possible to > speed up termination a bit by terminating a marked flow with a greater > probability; the caution is that this increases the chances of > over-terminating, because of the time lag after a termination decision > before the rate reduces.) > > For case [2], the difference is not quite as great - termination is > about 10* slower. > Conclusion: an operator who wants to use its capacity "aggressively" by > setting the PCN-upper-rate at 95% of PCN-max-rate must use the CL/SM > edge mechanism. > > Now let's consider the two bottleneck case, with the first marking and > the second dropping pkts. We only need to compare edge behaviours in > case [2]. > * if the overloaded node preferentially drop pkts that are already > marked, then the result is (max) 50% are unmarked, 50% marked and the > rest are dropped (0.5* PCN-max-rate unmarked = PCN-upper-rate; 0.5* > PCN-max-rate marked; 4* PCN-max-rate dropped). This is exactly the same > as in the single bottleneck case. Hence: > o again, the CL/SM edge mechanism can terminate the right amount > in one go. > o Again, Excess rate /EMFT terminates at the same slow speed as in > the single bottleneck case > * if the overloaded node preferentially drop pkts that are > unmarked, then the result is all pkts are marked and the rest are > dropped (1* PCN-max-rate marked; 4* PCN-max-rate dropped) > o the CL/SM edge mechanism no longer works. All pkts are marked, > so the sustainable rate is 0 & so it terminates all flows. > o Excess rate /EMFT terminates about twice as fast as in the > single bottleneck case (but still about 5* slower than the CL/SM > mechanism achieves above) > * if the overloaded node randomly drops pkts that are already > marked, then the result is roughly 10% are unmarked, 90% marked and the > rest are dropped (0.1* PCN-max-rate unmarked; 0.9* PCN-max-rate marked; > 4* PCN-max-rate dropped) > o the CL/SM edge mechanism terminates 5* too much (sustainable > rate is only 20% of what it really is) > o Excess rate /EMFT terminates towards twice as fast as in the > single bottleneck case (but still over 5* slower than the CL/SM > mechanism achieves above) > > Conclusion: > * if the overloaded node preferentially drop pkts that are > unmarked, then the CL/SM edge behaviour is not possible - so this option > can be excluded. > * if the overloaded node randomly drops pkts that are already > marked, then the CL/SM edge mechanism terminates far too much. The CL/SM > mechanism could be deliberately slowed down in order to reduce the risk > of over-termination. However, this creates a penalty of slower > termination in the single bottleneck case. The operator also needs to > guess what the highest level of overload is/ > > The above is intended to be purely descriptive. Now to give my opinion. > I believe it means that the standard should specify that an overloaded > node SHOULD preferentially drop pkts that are already excess-rate > marked: > * it gives the operator as much freedom as possible on setting the > PCN-upper-rate in relation to the PCN-max-rate. Otherwise it cannot set > PCN-upper-rate close to PCN-max-rate. > * It allows an operator to achieve termination to the correct rate > in a single shot (providing they're prepared to do the work of measuring > rates at egress & ingress). Otherwise they must *always* slow down > termination, in case there are two bottlenecks when there could be far > too much termination. > * It allows an operator to achieve termination with a simpler > mechanism like EMFT, albeit somewhat slower than would be achieved by > different preferential dropping behaviour. However, such an operator has > already accepted that, in the case where even one node is overloaded, > termination will be much slower than with a CL/SM edge behaviour. In > other words, such an operator has made the decision that the simpler > edge mechanism (in terms of not having to measure rates) is important > enough that they don't mind termination being slower than ideal if > there's an overloaded node. > > > Comments? > Phil/ > > >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >> Steven Blake >> Sent: 20 April 2008 18:41 >> To: pcn >> Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 >> >> On Mon, 2008-03-31 at 13:18 -0400, Steven Blake wrote: >> >>> Here are the remaining three questions that were taken during the >>> > IETF > >>> 71 meeting: >>> >>> Q4: Should the standards-track PCN scheme require (as a MUST >>> > implement > >>> feature) that interior PCN routers support Excess-Rate marking, >>> according to the particular method of handling already marked >>> packets and drops described in Anna Charny's presentation? >>> http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf >>> >>> Q5: Should the standards-track PCN scheme require (as a MUST >>> > implement > >>> feature) that interior PCN routers support Threshold marking (in >>> addition to Excess-Rate marking), according to the particular >>> > method > >>> described in Philip Eardley's presentation on Tuesday? >>> http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf >>> >>> Q6: If presented with sufficient evidence in a timely fashion, would >>> the PCN wg entertain the option of modifying the interior router >>> Excess-Rate marking behavior for the standards-track PCN scheme >>> > (as > >>> described in question 4)? >>> >>> According to the draft meeting minutes, Q4 was accepted 8-0 (my >>> > notes > >>> have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0. >>> >> The feedback from the list for Q4 and Q5 seems to match up closely >> > with > >> the results in the meeting (not surprising, as it was mostly the same >> individuals commenting). I counted one dissent for Q4 and one for Q5. >> >> The feedback for Q6 was a mixture of abstain and Yes with caveats. If >> and when someone wants to propose modifications to the Excess-Rate >> marking behavior, we can see if there is interest to discuss it on the >> list, but I *strongly encourage* that any such discussion needs to >> happen before the Dublin meeting. >> >> We seem to have consensus to go forward with a standards-track >> > proposal > >> supporting two encoding states, with Excess-Rate and Threshold marking >> as MUST implement features. In addition, we are open to work on one >> > or > >> more experimental-track proposals (as a lower priority acitivity) that >> are extensions of the standards-track proposal, using an additional >> encoding state. >> >> This is a call for volunteers to start working on drafts for the >> standards-track interior node detection, (in-band) PCN encoding, >> egress-ingress feedback protocol, and boundary node mechanisms, as >> spelled out in the PCN charter. >> >> Note: I will be (mostly) off line for the rest of the week. >> >> >> Regards, >> >> // Steve >> >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn >> > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Apr 22 00:34:01 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF02728C449; Tue, 22 Apr 2008 00:34:01 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1336528C45E for ; Tue, 22 Apr 2008 00:34:01 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfXZLK09rtBH for ; Tue, 22 Apr 2008 00:33:59 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 08E8628C449 for ; Tue, 22 Apr 2008 00:33:58 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Tue, 22 Apr 2008 09:34:03 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Apr 2008 09:33:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Apr 2008 09:35:46 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C012306DF@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B3475A@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Consensus questions: Q4, Q5, and Q6 thread-index: AcijDdEhZTGFLwePTTiggUM/QqQ5UgAwCZpAAB3SJWA= References: <1208713265.3483.27.camel@tachyon> <75A199C5D243C741BF3D3F1EBCEF9BA503B3475A@E03MVZ1-UKDY.domain1.systemhost.net> From: "Geib, Ruediger" To: , X-OriginalArrivalTime: 22 Apr 2008 07:33:48.0769 (UTC) FILETIME=[34572D10:01C8A44B] Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, if I got your 5 times max rate scenario right, apart from marking issues applications will face a packet loss of around 80%. If that is true, a discussion of "reaction speed" may have to consider end user reaction too (I guess, after a couple of seconds it should). Am I right, you are assuming a network with a high degree of meshing in a WAN and a simultaneous loss of allmost all WAN interfaces of a router for your scenario? The other case I could figure out was a badly engineered network where traffic destined for link with a higher gedree of aggregation is pushed back onto a link with a significantly lower degree of aggregation. I'd assume that tier1/2 carrier networks are engineered to avoid the latter. Regards, Rudiger | -----Original Message----- | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | Behalf Of philip.eardley@bt.com | Sent: Monday, April 21, 2008 6:42 PM | To: pcn@ietf.org | Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 | | On the subject of Qu 4: | Don't want to re-open this question, but I thought a bit more | at the preferential dropping issue, ie if a PCN-node is | overloaded and has to drop PCN-packets, should it | preferentially drop any that are already PCN-marked | (PCN-excess-rate-marked) - or preferentially drop ones that | are not marked - or just randomly drop. (The first of these | is where the WG consensus lies, and is also where this email ends up.) | | The preferential dropping behaviour matters when there's at | least one pre-congested node 'before' the overloaded node | ("two bottlenecks") | | The ideal answer depends on what the edge behaviour is: | * the CL/SM edge mechanism measures the sustainable rate (the rate | of unmarked pkts), and terminates rate above this. So ideally | PCN-nodes should preferentially drop pkts that already | PCN-(termination-)marked, otherwise too much PCN-traffic will | be terminated if there are two bottlenecks. | * The excess rate & EMFT mechanisms measure (react to) PCN-marked | pkts. So ideally PCN-nodes should preferentially drop pkts | that not PCN-(termination-)marked, otherwise PCN-traffic will | be terminated slower if there are two bottlenecks. | | However, it would be good if the PCN-node behaviour allowed | some flexibility in terms of the edge behaviour (at least we | seem to have been implicitly assuming this). Their pros/cons are: | * CL/SM edge behaviour: can terminate the right amount in a single | shot (but can also terminate slower, if that's preferred); | requires one msg from egress to ingress to indicate | termination; but has to measure rates at both egress and ingress | * Excess rate: in general terminates slower & so requires several | msgs; requires rate measurement at the egress but not ingress | * EMFT: doesn't need to measure any rate, but terminates slower | and needs a msg for each flow that's terminated | | Consider two cases in more detail. [1] the operator sets the | PCN-upper-rate at 95% of PCN-max-rate; [2] the operator sets | the PCN-upper-rate at 50% of PCN-max-rate There's the | PCN-upper-rate above which pkts are PCN-excess-rate-marked | and the PCN-max-rate above which PCN-pkts are dropped. | | For case [1], with a single bottleneck that's overloaded (say | at 5* PCN-max-rate), ie dropping pkts as well as marking pkts: | * the CL/SM edge mechanism can terminate the right amount in one | go. Termination is just as fast as when the bottleneck is | pre-congested but not overloaded. | * the excess rate mechanism measures the 5% of marked pkts. It | terminates this amount - the link is now overloaded at 4.95* | PCN-max-rate. This makes termination about 100* slower. | * With EMFT, if the edge sees a marked pkt then it terminates this | flow with some probability. This is similar to the previous | case, so again termination is much much slower. However, it | should be possible to speed up termination a bit by | terminating a marked flow with a greater probability; the | caution is that this increases the chances of | over-terminating, because of the time lag after a termination | decision before the rate reduces.) | | For case [2], the difference is not quite as great - | termination is about 10* slower. | Conclusion: an operator who wants to use its capacity | "aggressively" by setting the PCN-upper-rate at 95% of | PCN-max-rate must use the CL/SM edge mechanism. | | Now let's consider the two bottleneck case, with the first | marking and the second dropping pkts. We only need to compare | edge behaviours in case [2]. | * if the overloaded node preferentially drop pkts that are already | marked, then the result is (max) 50% are unmarked, 50% marked | and the rest are dropped (0.5* PCN-max-rate unmarked = | PCN-upper-rate; 0.5* PCN-max-rate marked; 4* PCN-max-rate | dropped). This is exactly the same as in the single | bottleneck case. Hence: | o again, the CL/SM edge mechanism can terminate the right amount | in one go. | o Again, Excess rate /EMFT terminates at the same slow speed as in | the single bottleneck case | * if the overloaded node preferentially drop pkts that are | unmarked, then the result is all pkts are marked and the rest | are dropped (1* PCN-max-rate marked; 4* PCN-max-rate dropped) | o the CL/SM edge mechanism no longer works. All pkts are marked, | so the sustainable rate is 0 & so it terminates all flows. | o Excess rate /EMFT terminates about twice as fast as in the | single bottleneck case (but still about 5* slower than the | CL/SM mechanism achieves above) | * if the overloaded node randomly drops pkts that are already | marked, then the result is roughly 10% are unmarked, 90% | marked and the rest are dropped (0.1* PCN-max-rate unmarked; | 0.9* PCN-max-rate marked; | 4* PCN-max-rate dropped) | o the CL/SM edge mechanism terminates 5* too much (sustainable | rate is only 20% of what it really is) | o Excess rate /EMFT terminates towards twice as fast as in the | single bottleneck case (but still over 5* slower than the | CL/SM mechanism achieves above) | | Conclusion: | * if the overloaded node preferentially drop pkts that are | unmarked, then the CL/SM edge behaviour is not possible - so | this option can be excluded. | * if the overloaded node randomly drops pkts that are already | marked, then the CL/SM edge mechanism terminates far too | much. The CL/SM mechanism could be deliberately slowed down | in order to reduce the risk of over-termination. However, | this creates a penalty of slower termination in the single | bottleneck case. The operator also needs to guess what the | highest level of overload is/ | | The above is intended to be purely descriptive. Now to give | my opinion. | I believe it means that the standard should specify that an | overloaded node SHOULD preferentially drop pkts that are | already excess-rate | marked: | * it gives the operator as much freedom as possible on setting the | PCN-upper-rate in relation to the PCN-max-rate. Otherwise it | cannot set PCN-upper-rate close to PCN-max-rate. | * It allows an operator to achieve termination to the correct rate | in a single shot (providing they're prepared to do the work | of measuring rates at egress & ingress). Otherwise they must | *always* slow down termination, in case there are two | bottlenecks when there could be far too much termination. | * It allows an operator to achieve termination with a simpler | mechanism like EMFT, albeit somewhat slower than would be | achieved by different preferential dropping behaviour. | However, such an operator has already accepted that, in the | case where even one node is overloaded, termination will be | much slower than with a CL/SM edge behaviour. In other words, | such an operator has made the decision that the simpler edge | mechanism (in terms of not having to measure rates) is | important enough that they don't mind termination being | slower than ideal if there's an overloaded node. | | | Comments? | Phil/ | | > -----Original Message----- | > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | Behalf Of | > Steven Blake | > Sent: 20 April 2008 18:41 | > To: pcn | > Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 | > | > On Mon, 2008-03-31 at 13:18 -0400, Steven Blake wrote: | > > Here are the remaining three questions that were taken during the | IETF | > > 71 meeting: | > > | > > Q4: Should the standards-track PCN scheme require (as a MUST | implement | > > feature) that interior PCN routers support | Excess-Rate marking, | > > according to the particular method of handling already marked | > > packets and drops described in Anna Charny's presentation? | > > http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf | > > | > > Q5: Should the standards-track PCN scheme require (as a MUST | implement | > > feature) that interior PCN routers support Threshold | marking (in | > > addition to Excess-Rate marking), according to the particular | method | > > described in Philip Eardley's presentation on Tuesday? | > > http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf | > > | > > Q6: If presented with sufficient evidence in a timely | fashion, would | > > the PCN wg entertain the option of modifying the | interior router | > > Excess-Rate marking behavior for the standards-track | PCN scheme | (as | > > described in question 4)? | > > | > > According to the draft meeting minutes, Q4 was accepted 8-0 (my | notes | > > have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0. | > | > The feedback from the list for Q4 and Q5 seems to match up closely | with | > the results in the meeting (not surprising, as it was | mostly the same | > individuals commenting). I counted one dissent for Q4 and | one for Q5. | > | > The feedback for Q6 was a mixture of abstain and Yes with | caveats. If | > and when someone wants to propose modifications to the Excess-Rate | > marking behavior, we can see if there is interest to | discuss it on the | > list, but I *strongly encourage* that any such discussion needs to | > happen before the Dublin meeting. | > | > We seem to have consensus to go forward with a standards-track | proposal | > supporting two encoding states, with Excess-Rate and | Threshold marking | > as MUST implement features. In addition, we are open to work on one | or | > more experimental-track proposals (as a lower priority | acitivity) that | > are extensions of the standards-track proposal, using an additional | > encoding state. | > | > This is a call for volunteers to start working on drafts for the | > standards-track interior node detection, (in-band) PCN encoding, | > egress-ingress feedback protocol, and boundary node mechanisms, as | > spelled out in the PCN charter. | > | > Note: I will be (mostly) off line for the rest of the week. | > | > | > Regards, | > | > // Steve | > | > _______________________________________________ | > PCN mailing list | > PCN@ietf.org | > https://www.ietf.org/mailman/listinfo/pcn | _______________________________________________ | PCN mailing list | PCN@ietf.org | https://www.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Apr 22 01:13:15 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47B2F3A6A6A; Tue, 22 Apr 2008 01:13:15 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 812903A6A6A for ; Tue, 22 Apr 2008 01:13:13 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UG901wPG2sk for ; Tue, 22 Apr 2008 01:13:12 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id C826A3A696E for ; Tue, 22 Apr 2008 01:13:11 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m3M8D7SD000555; Tue, 22 Apr 2008 10:13:11 +0200 (MEST) From: "Georgios Karagiannis" To: , References: <75A199C5D243C741BF3D3F1EBCEF9BA503B3475A@E03MVZ1-UKDY.domain1.systemhost.net> <480CCF68.4010507@informatik.uni-wuerzburg.de> Date: Tue, 22 Apr 2008 10:13:13 +0200 Message-ID: <000301c8a450$b8f65730$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <480CCF68.4010507@informatik.uni-wuerzburg.de> Thread-Index: Acij1cbg8k80P+2lQ+aKPHfz/JfVRgAesRqA X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 22 Apr 2008 10:13:12 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi all I agree with Michael, see below: "if other solutions should not be excluded, preferential dropping of unmarked packets is also required as an option. Then it is probably also wise to have another option that does not do any preferential drop. The decision on preferential dropping limits the potential use of PCN marking or the number of architectural options." Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Michael Menth > Sent: maandag 21 april 2008 19:31 > To: philip.eardley@bt.com > Cc: pcn@ietf.org > Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 > > Hi Phil, > > as your analysis showed, CL/SM require preferential dropping > of marked packets. Other termination methods required > preferential marking of unmarked packets. If PCN marking > should be optimized for CL/SM at the expense of other > solutions, preferential dropping of marked packets it the way > to go. But this kind of marking is hardly of any use for > other termination methods in challenging situations. > > So, if other solutions should not be excluded, preferential > dropping of unmarked packets is also required as an option. > Then it is probably also wise to have another option that > does not do any preferential drop. The decision on > preferential dropping limits the potential use of PCN marking > or the number of architectural options. > > Regards, > > Michael > > philip.eardley@bt.com wrote: > > On the subject of Qu 4: > > Don't want to re-open this question, but I thought a bit > more at the > > preferential dropping issue, ie if a PCN-node is overloaded > and has to > > drop PCN-packets, should it preferentially drop any that > are already > > PCN-marked (PCN-excess-rate-marked) - or preferentially > drop ones that > > are not marked - or just randomly drop. (The first of these > is where > > the WG consensus lies, and is also where this email ends up.) > > > > The preferential dropping behaviour matters when there's at > least one > > pre-congested node 'before' the overloaded node ("two bottlenecks") > > > > The ideal answer depends on what the edge behaviour is: > > * the CL/SM edge mechanism measures the sustainable rate (the rate > > of unmarked pkts), and terminates rate above this. So ideally > > PCN-nodes should preferentially drop pkts that already > > PCN-(termination-)marked, otherwise too much PCN-traffic will be > > terminated if there are two bottlenecks. > > * The excess rate & EMFT mechanisms measure (react to) PCN-marked > > pkts. So ideally PCN-nodes should preferentially drop pkts that not > > PCN-(termination-)marked, otherwise PCN-traffic will be terminated > > slower if there are two bottlenecks. > > > > However, it would be good if the PCN-node behaviour allowed some > > flexibility in terms of the edge behaviour (at least we > seem to have > > been implicitly assuming this). Their pros/cons are: > > * CL/SM edge behaviour: can terminate the right amount in a single > > shot (but can also terminate slower, if that's preferred); requires > > one msg from egress to ingress to indicate termination; but has to > > measure rates at both egress and ingress > > * Excess rate: in general terminates slower & so requires several > > msgs; requires rate measurement at the egress but not ingress > > * EMFT: doesn't need to measure any rate, but terminates slower > > and needs a msg for each flow that's terminated > > > > Consider two cases in more detail. [1] the operator sets the > > PCN-upper-rate at 95% of PCN-max-rate; [2] the operator sets the > > PCN-upper-rate at 50% of PCN-max-rate There's the > PCN-upper-rate above > > which pkts are PCN-excess-rate-marked and the PCN-max-rate > above which > > PCN-pkts are dropped. > > > > For case [1], with a single bottleneck that's overloaded (say at 5* > > PCN-max-rate), ie dropping pkts as well as marking pkts: > > * the CL/SM edge mechanism can terminate the right amount in one > > go. Termination is just as fast as when the bottleneck is > > pre-congested but not overloaded. > > * the excess rate mechanism measures the 5% of marked pkts. It > > terminates this amount - the link is now overloaded at 4.95* > > PCN-max-rate. This makes termination about 100* slower. > > * With EMFT, if the edge sees a marked pkt then it terminates this > > flow with some probability. This is similar to the previous > case, so > > again termination is much much slower. However, it should > be possible > > to speed up termination a bit by terminating a marked flow with a > > greater probability; the caution is that this increases the > chances of > > over-terminating, because of the time lag after a > termination decision > > before the rate reduces.) > > > > For case [2], the difference is not quite as great - termination is > > about 10* slower. > > Conclusion: an operator who wants to use its capacity > "aggressively" > > by setting the PCN-upper-rate at 95% of PCN-max-rate must use the > > CL/SM edge mechanism. > > > > Now let's consider the two bottleneck case, with the first > marking and > > the second dropping pkts. We only need to compare edge > behaviours in > > case [2]. > > * if the overloaded node preferentially drop pkts that are already > > marked, then the result is (max) 50% are unmarked, 50% > marked and the > > rest are dropped (0.5* PCN-max-rate unmarked = PCN-upper-rate; 0.5* > > PCN-max-rate marked; 4* PCN-max-rate dropped). This is exactly the > > same as in the single bottleneck case. Hence: > > o again, the CL/SM edge mechanism can terminate the right amount > > in one go. > > o Again, Excess rate /EMFT terminates at the same slow speed as in > > the single bottleneck case > > * if the overloaded node preferentially drop pkts that are > > unmarked, then the result is all pkts are marked and the rest are > > dropped (1* PCN-max-rate marked; 4* PCN-max-rate dropped) > > o the CL/SM edge mechanism no longer works. All pkts are marked, > > so the sustainable rate is 0 & so it terminates all flows. > > o Excess rate /EMFT terminates about twice as fast as in the > > single bottleneck case (but still about 5* slower than the CL/SM > > mechanism achieves above) > > * if the overloaded node randomly drops pkts that are already > > marked, then the result is roughly 10% are unmarked, 90% marked and > > the rest are dropped (0.1* PCN-max-rate unmarked; 0.9* PCN-max-rate > > marked; > > 4* PCN-max-rate dropped) > > o the CL/SM edge mechanism terminates 5* too much (sustainable > > rate is only 20% of what it really is) > > o Excess rate /EMFT terminates towards twice as fast as in the > > single bottleneck case (but still over 5* slower than the CL/SM > > mechanism achieves above) > > > > Conclusion: > > * if the overloaded node preferentially drop pkts that are > > unmarked, then the CL/SM edge behaviour is not possible - so this > > option can be excluded. > > * if the overloaded node randomly drops pkts that are already > > marked, then the CL/SM edge mechanism terminates far too much. The > > CL/SM mechanism could be deliberately slowed down in order > to reduce > > the risk of over-termination. However, this creates a penalty of > > slower termination in the single bottleneck case. The operator also > > needs to guess what the highest level of overload is/ > > > > The above is intended to be purely descriptive. Now to give > my opinion. > > I believe it means that the standard should specify that an > overloaded > > node SHOULD preferentially drop pkts that are already excess-rate > > marked: > > * it gives the operator as much freedom as possible on setting the > > PCN-upper-rate in relation to the PCN-max-rate. Otherwise it cannot > > set PCN-upper-rate close to PCN-max-rate. > > * It allows an operator to achieve termination to the correct rate > > in a single shot (providing they're prepared to do the work of > > measuring rates at egress & ingress). Otherwise they must *always* > > slow down termination, in case there are two bottlenecks when there > > could be far too much termination. > > * It allows an operator to achieve termination with a simpler > > mechanism like EMFT, albeit somewhat slower than would be > achieved by > > different preferential dropping behaviour. However, such an > operator > > has already accepted that, in the case where even one node is > > overloaded, termination will be much slower than with a CL/SM edge > > behaviour. In other words, such an operator has made the > decision that > > the simpler edge mechanism (in terms of not having to > measure rates) > > is important enough that they don't mind termination being > slower than > > ideal if there's an overloaded node. > > > > > > Comments? > > Phil/ > > > > > >> -----Original Message----- > >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > On Behalf Of > >> Steven Blake > >> Sent: 20 April 2008 18:41 > >> To: pcn > >> Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 > >> > >> On Mon, 2008-03-31 at 13:18 -0400, Steven Blake wrote: > >> > >>> Here are the remaining three questions that were taken during the > >>> > > IETF > > > >>> 71 meeting: > >>> > >>> Q4: Should the standards-track PCN scheme require (as a MUST > >>> > > implement > > > >>> feature) that interior PCN routers support > Excess-Rate marking, > >>> according to the particular method of handling already marked > >>> packets and drops described in Anna Charny's presentation? > >>> http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf > >>> > >>> Q5: Should the standards-track PCN scheme require (as a MUST > >>> > > implement > > > >>> feature) that interior PCN routers support Threshold > marking (in > >>> addition to Excess-Rate marking), according to the particular > >>> > > method > > > >>> described in Philip Eardley's presentation on Tuesday? > >>> http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf > >>> > >>> Q6: If presented with sufficient evidence in a timely > fashion, would > >>> the PCN wg entertain the option of modifying the > interior router > >>> Excess-Rate marking behavior for the standards-track > PCN scheme > >>> > > (as > > > >>> described in question 4)? > >>> > >>> According to the draft meeting minutes, Q4 was accepted 8-0 (my > >>> > > notes > > > >>> have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0. > >>> > >> The feedback from the list for Q4 and Q5 seems to match up closely > >> > > with > > > >> the results in the meeting (not surprising, as it was > mostly the same > >> individuals commenting). I counted one dissent for Q4 and > one for Q5. > >> > >> The feedback for Q6 was a mixture of abstain and Yes with > caveats. > >> If and when someone wants to propose modifications to the > Excess-Rate > >> marking behavior, we can see if there is interest to discuss it on > >> the list, but I *strongly encourage* that any such > discussion needs > >> to happen before the Dublin meeting. > >> > >> We seem to have consensus to go forward with a standards-track > >> > > proposal > > > >> supporting two encoding states, with Excess-Rate and Threshold > >> marking as MUST implement features. In addition, we are > open to work > >> on one > >> > > or > > > >> more experimental-track proposals (as a lower priority acitivity) > >> that are extensions of the standards-track proposal, using an > >> additional encoding state. > >> > >> This is a call for volunteers to start working on drafts for the > >> standards-track interior node detection, (in-band) PCN encoding, > >> egress-ingress feedback protocol, and boundary node mechanisms, as > >> spelled out in the PCN charter. > >> > >> Note: I will be (mostly) off line for the rest of the week. > >> > >> > >> Regards, > >> > >> // Steve > >> > >> _______________________________________________ > >> PCN mailing list > >> PCN@ietf.org > >> https://www.ietf.org/mailman/listinfo/pcn > >> > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > > > -- > Dr. Michael Menth, Assistant Professor > University of Wuerzburg, Institute of Computer Science Am > Hubland, D-97074 Wuerzburg, Germany, room B206 > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > mailto:menth@informatik.uni-wuerzburg.de > http://www3.informatik.uni-wuerzburg.de/research/ngn > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Apr 22 01:40:06 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ACF128C413; Tue, 22 Apr 2008 01:40:06 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4861728C449 for ; Tue, 22 Apr 2008 01:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzekdXrfDB0U for ; Tue, 22 Apr 2008 01:40:03 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 024523A6A57 for ; Tue, 22 Apr 2008 01:40:02 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Apr 2008 09:40:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Apr 2008 09:40:07 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B3475F@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <000301c8a450$b8f65730$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Consensus questions: Q4, Q5, and Q6 Thread-Index: Acij1cbg8k80P+2lQ+aKPHfz/JfVRgAesRqAAACgk7A= From: To: , X-OriginalArrivalTime: 22 Apr 2008 08:40:07.0936 (UTC) FILETIME=[781BE000:01C8A454] Cc: pcn@ietf.org Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Arghh, I really didn't want to re-open the consensus question, I'm an idiot. Anyway, > > as your analysis showed, CL/SM require preferential dropping > > of marked packets. Other termination methods required > > preferential marking of unmarked packets. If PCN marking > > should be optimized for CL/SM at the expense of other > > solutions, preferential dropping of marked packets it the way > > to go. But this kind of marking is hardly of any use for > > other termination methods in challenging situations. This is not an accurate summary of my email. Rather: with preferential dropping of marked packets, CL/SM works well ; and Excess rate /EMFT still work OK [terminate slower than would do if preferentially dropped unmarked pkts, but in any case much slower than CL/SM. Ie for an operator doing excess rate/EMFT, speed of termination isn't their most important criterion] Best wishes, phil > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 22 April 2008 09:13 > To: menth@informatik.uni-wuerzburg.de; Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org > Subject: RE: [PCN] Consensus questions: Q4, Q5, and Q6 > > Hi all > > I agree with Michael, see below: > "if other solutions should not be excluded, preferential > dropping of unmarked packets is also required as an option. > Then it is probably also wise to have another option that > does not do any preferential drop. The decision on > preferential dropping limits the potential use of PCN marking > or the number of architectural options." > > Best regards, > Georgios > > > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > > Behalf Of Michael Menth > > Sent: maandag 21 april 2008 19:31 > > To: philip.eardley@bt.com > > Cc: pcn@ietf.org > > Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 > > > > Hi Phil, > > > > as your analysis showed, CL/SM require preferential dropping > > of marked packets. Other termination methods required > > preferential marking of unmarked packets. If PCN marking > > should be optimized for CL/SM at the expense of other > > solutions, preferential dropping of marked packets it the way > > to go. But this kind of marking is hardly of any use for > > other termination methods in challenging situations. > > > > So, if other solutions should not be excluded, preferential > > dropping of unmarked packets is also required as an option. > > Then it is probably also wise to have another option that > > does not do any preferential drop. The decision on > > preferential dropping limits the potential use of PCN marking > > or the number of architectural options. > > > > Regards, > > > > Michael > > > > philip.eardley@bt.com wrote: > > > On the subject of Qu 4: > > > Don't want to re-open this question, but I thought a bit > > more at the > > > preferential dropping issue, ie if a PCN-node is overloaded > > and has to > > > drop PCN-packets, should it preferentially drop any that > > are already > > > PCN-marked (PCN-excess-rate-marked) - or preferentially > > drop ones that > > > are not marked - or just randomly drop. (The first of these > > is where > > > the WG consensus lies, and is also where this email ends up.) > > > > > > The preferential dropping behaviour matters when there's at > > least one > > > pre-congested node 'before' the overloaded node ("two bottlenecks") > > > > > > The ideal answer depends on what the edge behaviour is: > > > * the CL/SM edge mechanism measures the sustainable rate (the rate > > > of unmarked pkts), and terminates rate above this. So ideally > > > PCN-nodes should preferentially drop pkts that already > > > PCN-(termination-)marked, otherwise too much PCN-traffic will be > > > terminated if there are two bottlenecks. > > > * The excess rate & EMFT mechanisms measure (react to) PCN-marked > > > pkts. So ideally PCN-nodes should preferentially drop pkts that not > > > PCN-(termination-)marked, otherwise PCN-traffic will be terminated > > > slower if there are two bottlenecks. > > > > > > However, it would be good if the PCN-node behaviour allowed some > > > flexibility in terms of the edge behaviour (at least we > > seem to have > > > been implicitly assuming this). Their pros/cons are: > > > * CL/SM edge behaviour: can terminate the right amount in a single > > > shot (but can also terminate slower, if that's preferred); requires > > > one msg from egress to ingress to indicate termination; but has to > > > measure rates at both egress and ingress > > > * Excess rate: in general terminates slower & so requires several > > > msgs; requires rate measurement at the egress but not ingress > > > * EMFT: doesn't need to measure any rate, but terminates slower > > > and needs a msg for each flow that's terminated > > > > > > Consider two cases in more detail. [1] the operator sets the > > > PCN-upper-rate at 95% of PCN-max-rate; [2] the operator sets the > > > PCN-upper-rate at 50% of PCN-max-rate There's the > > PCN-upper-rate above > > > which pkts are PCN-excess-rate-marked and the PCN-max-rate > > above which > > > PCN-pkts are dropped. > > > > > > For case [1], with a single bottleneck that's overloaded (say at 5* > > > PCN-max-rate), ie dropping pkts as well as marking pkts: > > > * the CL/SM edge mechanism can terminate the right amount in one > > > go. Termination is just as fast as when the bottleneck is > > > pre-congested but not overloaded. > > > * the excess rate mechanism measures the 5% of marked pkts. It > > > terminates this amount - the link is now overloaded at 4.95* > > > PCN-max-rate. This makes termination about 100* slower. > > > * With EMFT, if the edge sees a marked pkt then it terminates this > > > flow with some probability. This is similar to the previous > > case, so > > > again termination is much much slower. However, it should > > be possible > > > to speed up termination a bit by terminating a marked flow with a > > > greater probability; the caution is that this increases the > > chances of > > > over-terminating, because of the time lag after a > > termination decision > > > before the rate reduces.) > > > > > > For case [2], the difference is not quite as great - termination is > > > about 10* slower. > > > Conclusion: an operator who wants to use its capacity > > "aggressively" > > > by setting the PCN-upper-rate at 95% of PCN-max-rate must use the > > > CL/SM edge mechanism. > > > > > > Now let's consider the two bottleneck case, with the first > > marking and > > > the second dropping pkts. We only need to compare edge > > behaviours in > > > case [2]. > > > * if the overloaded node preferentially drop pkts that are already > > > marked, then the result is (max) 50% are unmarked, 50% > > marked and the > > > rest are dropped (0.5* PCN-max-rate unmarked = PCN-upper-rate; 0.5* > > > PCN-max-rate marked; 4* PCN-max-rate dropped). This is exactly the > > > same as in the single bottleneck case. Hence: > > > o again, the CL/SM edge mechanism can terminate the right amount > > > in one go. > > > o Again, Excess rate /EMFT terminates at the same slow speed as in > > > the single bottleneck case > > > * if the overloaded node preferentially drop pkts that are > > > unmarked, then the result is all pkts are marked and the rest are > > > dropped (1* PCN-max-rate marked; 4* PCN-max-rate dropped) > > > o the CL/SM edge mechanism no longer works. All pkts are marked, > > > so the sustainable rate is 0 & so it terminates all flows. > > > o Excess rate /EMFT terminates about twice as fast as in the > > > single bottleneck case (but still about 5* slower than the CL/SM > > > mechanism achieves above) > > > * if the overloaded node randomly drops pkts that are already > > > marked, then the result is roughly 10% are unmarked, 90% marked and > > > the rest are dropped (0.1* PCN-max-rate unmarked; 0.9* PCN-max-rate > > > marked; > > > 4* PCN-max-rate dropped) > > > o the CL/SM edge mechanism terminates 5* too much (sustainable > > > rate is only 20% of what it really is) > > > o Excess rate /EMFT terminates towards twice as fast as in the > > > single bottleneck case (but still over 5* slower than the CL/SM > > > mechanism achieves above) > > > > > > Conclusion: > > > * if the overloaded node preferentially drop pkts that are > > > unmarked, then the CL/SM edge behaviour is not possible - so this > > > option can be excluded. > > > * if the overloaded node randomly drops pkts that are already > > > marked, then the CL/SM edge mechanism terminates far too much. The > > > CL/SM mechanism could be deliberately slowed down in order > > to reduce > > > the risk of over-termination. However, this creates a penalty of > > > slower termination in the single bottleneck case. The operator also > > > needs to guess what the highest level of overload is/ > > > > > > The above is intended to be purely descriptive. Now to give > > my opinion. > > > I believe it means that the standard should specify that an > > overloaded > > > node SHOULD preferentially drop pkts that are already excess-rate > > > marked: > > > * it gives the operator as much freedom as possible on setting the > > > PCN-upper-rate in relation to the PCN-max-rate. Otherwise it cannot > > > set PCN-upper-rate close to PCN-max-rate. > > > * It allows an operator to achieve termination to the correct rate > > > in a single shot (providing they're prepared to do the work of > > > measuring rates at egress & ingress). Otherwise they must *always* > > > slow down termination, in case there are two bottlenecks when there > > > could be far too much termination. > > > * It allows an operator to achieve termination with a simpler > > > mechanism like EMFT, albeit somewhat slower than would be > > achieved by > > > different preferential dropping behaviour. However, such an > > operator > > > has already accepted that, in the case where even one node is > > > overloaded, termination will be much slower than with a CL/SM edge > > > behaviour. In other words, such an operator has made the > > decision that > > > the simpler edge mechanism (in terms of not having to > > measure rates) > > > is important enough that they don't mind termination being > > slower than > > > ideal if there's an overloaded node. > > > > > > > > > Comments? > > > Phil/ > > > > > > > > >> -----Original Message----- > > >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > > On Behalf Of > > >> Steven Blake > > >> Sent: 20 April 2008 18:41 > > >> To: pcn > > >> Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 > > >> > > >> On Mon, 2008-03-31 at 13:18 -0400, Steven Blake wrote: > > >> > > >>> Here are the remaining three questions that were taken during the > > >>> > > > IETF > > > > > >>> 71 meeting: > > >>> > > >>> Q4: Should the standards-track PCN scheme require (as a MUST > > >>> > > > implement > > > > > >>> feature) that interior PCN routers support > > Excess-Rate marking, > > >>> according to the particular method of handling already marked > > >>> packets and drops described in Anna Charny's presentation? > > >>> http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf > > >>> > > >>> Q5: Should the standards-track PCN scheme require (as a MUST > > >>> > > > implement > > > > > >>> feature) that interior PCN routers support Threshold > > marking (in > > >>> addition to Excess-Rate marking), according to the particular > > >>> > > > method > > > > > >>> described in Philip Eardley's presentation on Tuesday? > > >>> http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf > > >>> > > >>> Q6: If presented with sufficient evidence in a timely > > fashion, would > > >>> the PCN wg entertain the option of modifying the > > interior router > > >>> Excess-Rate marking behavior for the standards-track > > PCN scheme > > >>> > > > (as > > > > > >>> described in question 4)? > > >>> > > >>> According to the draft meeting minutes, Q4 was accepted 8-0 (my > > >>> > > > notes > > > > > >>> have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0. > > >>> > > >> The feedback from the list for Q4 and Q5 seems to match up closely > > >> > > > with > > > > > >> the results in the meeting (not surprising, as it was > > mostly the same > > >> individuals commenting). I counted one dissent for Q4 and > > one for Q5. > > >> > > >> The feedback for Q6 was a mixture of abstain and Yes with > > caveats. > > >> If and when someone wants to propose modifications to the > > Excess-Rate > > >> marking behavior, we can see if there is interest to discuss it on > > >> the list, but I *strongly encourage* that any such > > discussion needs > > >> to happen before the Dublin meeting. > > >> > > >> We seem to have consensus to go forward with a standards-track > > >> > > > proposal > > > > > >> supporting two encoding states, with Excess-Rate and Threshold > > >> marking as MUST implement features. In addition, we are > > open to work > > >> on one > > >> > > > or > > > > > >> more experimental-track proposals (as a lower priority acitivity) > > >> that are extensions of the standards-track proposal, using an > > >> additional encoding state. > > >> > > >> This is a call for volunteers to start working on drafts for the > > >> standards-track interior node detection, (in-band) PCN encoding, > > >> egress-ingress feedback protocol, and boundary node mechanisms, as > > >> spelled out in the PCN charter. > > >> > > >> Note: I will be (mostly) off line for the rest of the week. > > >> > > >> > > >> Regards, > > >> > > >> // Steve > > >> > > >> _______________________________________________ > > >> PCN mailing list > > >> PCN@ietf.org > > >> https://www.ietf.org/mailman/listinfo/pcn > > >> > > > _______________________________________________ > > > PCN mailing list > > > PCN@ietf.org > > > https://www.ietf.org/mailman/listinfo/pcn > > > > > > > -- > > Dr. Michael Menth, Assistant Professor > > University of Wuerzburg, Institute of Computer Science Am > > Hubland, D-97074 Wuerzburg, Germany, room B206 > > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > > mailto:menth@informatik.uni-wuerzburg.de > > http://www3.informatik.uni-wuerzburg.de/research/ngn > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Apr 22 01:41:21 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 193CE3A6A25; Tue, 22 Apr 2008 01:41:21 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E832A3A6840 for ; Tue, 22 Apr 2008 01:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Q3ctAY2xp0c for ; Tue, 22 Apr 2008 01:41:18 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id D38C13A6A25 for ; Tue, 22 Apr 2008 01:41:17 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Apr 2008 09:41:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Apr 2008 09:41:22 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34760@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1C012306DF@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Consensus questions: Q4, Q5, and Q6 Thread-Index: AcijDdEhZTGFLwePTTiggUM/QqQ5UgAwCZpAAB3SJWAAA8/HQA== From: To: , X-OriginalArrivalTime: 22 Apr 2008 08:41:23.0371 (UTC) FILETIME=[A51257B0:01C8A454] Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Rudiger, You're right, the scenario is a very extreme one & I didn't include end user reaction effects Thanks, Phil. > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 22 April 2008 08:36 > To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org > Subject: RE: [PCN] Consensus questions: Q4, Q5, and Q6 > > Hi Phil, > > if I got your 5 times max rate scenario right, apart from marking > issues applications will face a packet loss of around 80%. If that > is true, a discussion of "reaction speed" may have to consider > end user reaction too (I guess, after a couple of seconds it > should). > > Am I right, you are assuming a network with a high degree of > meshing in a WAN and a simultaneous loss of allmost all WAN > interfaces of a router for your scenario? The other case I could > figure out was a badly engineered network where traffic destined > for link with a higher gedree of aggregation is pushed back onto > a link with a significantly lower degree of aggregation. I'd > assume that tier1/2 carrier networks are engineered to avoid > the latter. > > Regards, > > Rudiger > > | -----Original Message----- > | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > | Behalf Of philip.eardley@bt.com > | Sent: Monday, April 21, 2008 6:42 PM > | To: pcn@ietf.org > | Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 > | > | On the subject of Qu 4: > | Don't want to re-open this question, but I thought a bit more > | at the preferential dropping issue, ie if a PCN-node is > | overloaded and has to drop PCN-packets, should it > | preferentially drop any that are already PCN-marked > | (PCN-excess-rate-marked) - or preferentially drop ones that > | are not marked - or just randomly drop. (The first of these > | is where the WG consensus lies, and is also where this email ends up.) > | > | The preferential dropping behaviour matters when there's at > | least one pre-congested node 'before' the overloaded node > | ("two bottlenecks") > | > | The ideal answer depends on what the edge behaviour is: > | * the CL/SM edge mechanism measures the sustainable rate (the rate > | of unmarked pkts), and terminates rate above this. So ideally > | PCN-nodes should preferentially drop pkts that already > | PCN-(termination-)marked, otherwise too much PCN-traffic will > | be terminated if there are two bottlenecks. > | * The excess rate & EMFT mechanisms measure (react to) PCN-marked > | pkts. So ideally PCN-nodes should preferentially drop pkts > | that not PCN-(termination-)marked, otherwise PCN-traffic will > | be terminated slower if there are two bottlenecks. > | > | However, it would be good if the PCN-node behaviour allowed > | some flexibility in terms of the edge behaviour (at least we > | seem to have been implicitly assuming this). Their pros/cons are: > | * CL/SM edge behaviour: can terminate the right amount in a single > | shot (but can also terminate slower, if that's preferred); > | requires one msg from egress to ingress to indicate > | termination; but has to measure rates at both egress and ingress > | * Excess rate: in general terminates slower & so requires several > | msgs; requires rate measurement at the egress but not ingress > | * EMFT: doesn't need to measure any rate, but terminates slower > | and needs a msg for each flow that's terminated > | > | Consider two cases in more detail. [1] the operator sets the > | PCN-upper-rate at 95% of PCN-max-rate; [2] the operator sets > | the PCN-upper-rate at 50% of PCN-max-rate There's the > | PCN-upper-rate above which pkts are PCN-excess-rate-marked > | and the PCN-max-rate above which PCN-pkts are dropped. > | > | For case [1], with a single bottleneck that's overloaded (say > | at 5* PCN-max-rate), ie dropping pkts as well as marking pkts: > | * the CL/SM edge mechanism can terminate the right amount in one > | go. Termination is just as fast as when the bottleneck is > | pre-congested but not overloaded. > | * the excess rate mechanism measures the 5% of marked pkts. It > | terminates this amount - the link is now overloaded at 4.95* > | PCN-max-rate. This makes termination about 100* slower. > | * With EMFT, if the edge sees a marked pkt then it terminates this > | flow with some probability. This is similar to the previous > | case, so again termination is much much slower. However, it > | should be possible to speed up termination a bit by > | terminating a marked flow with a greater probability; the > | caution is that this increases the chances of > | over-terminating, because of the time lag after a termination > | decision before the rate reduces.) > | > | For case [2], the difference is not quite as great - > | termination is about 10* slower. > | Conclusion: an operator who wants to use its capacity > | "aggressively" by setting the PCN-upper-rate at 95% of > | PCN-max-rate must use the CL/SM edge mechanism. > | > | Now let's consider the two bottleneck case, with the first > | marking and the second dropping pkts. We only need to compare > | edge behaviours in case [2]. > | * if the overloaded node preferentially drop pkts that are already > | marked, then the result is (max) 50% are unmarked, 50% marked > | and the rest are dropped (0.5* PCN-max-rate unmarked = > | PCN-upper-rate; 0.5* PCN-max-rate marked; 4* PCN-max-rate > | dropped). This is exactly the same as in the single > | bottleneck case. Hence: > | o again, the CL/SM edge mechanism can terminate the right amount > | in one go. > | o Again, Excess rate /EMFT terminates at the same slow speed as in > | the single bottleneck case > | * if the overloaded node preferentially drop pkts that are > | unmarked, then the result is all pkts are marked and the rest > | are dropped (1* PCN-max-rate marked; 4* PCN-max-rate dropped) > | o the CL/SM edge mechanism no longer works. All pkts are marked, > | so the sustainable rate is 0 & so it terminates all flows. > | o Excess rate /EMFT terminates about twice as fast as in the > | single bottleneck case (but still about 5* slower than the > | CL/SM mechanism achieves above) > | * if the overloaded node randomly drops pkts that are already > | marked, then the result is roughly 10% are unmarked, 90% > | marked and the rest are dropped (0.1* PCN-max-rate unmarked; > | 0.9* PCN-max-rate marked; > | 4* PCN-max-rate dropped) > | o the CL/SM edge mechanism terminates 5* too much (sustainable > | rate is only 20% of what it really is) > | o Excess rate /EMFT terminates towards twice as fast as in the > | single bottleneck case (but still over 5* slower than the > | CL/SM mechanism achieves above) > | > | Conclusion: > | * if the overloaded node preferentially drop pkts that are > | unmarked, then the CL/SM edge behaviour is not possible - so > | this option can be excluded. > | * if the overloaded node randomly drops pkts that are already > | marked, then the CL/SM edge mechanism terminates far too > | much. The CL/SM mechanism could be deliberately slowed down > | in order to reduce the risk of over-termination. However, > | this creates a penalty of slower termination in the single > | bottleneck case. The operator also needs to guess what the > | highest level of overload is/ > | > | The above is intended to be purely descriptive. Now to give > | my opinion. > | I believe it means that the standard should specify that an > | overloaded node SHOULD preferentially drop pkts that are > | already excess-rate > | marked: > | * it gives the operator as much freedom as possible on setting the > | PCN-upper-rate in relation to the PCN-max-rate. Otherwise it > | cannot set PCN-upper-rate close to PCN-max-rate. > | * It allows an operator to achieve termination to the correct rate > | in a single shot (providing they're prepared to do the work > | of measuring rates at egress & ingress). Otherwise they must > | *always* slow down termination, in case there are two > | bottlenecks when there could be far too much termination. > | * It allows an operator to achieve termination with a simpler > | mechanism like EMFT, albeit somewhat slower than would be > | achieved by different preferential dropping behaviour. > | However, such an operator has already accepted that, in the > | case where even one node is overloaded, termination will be > | much slower than with a CL/SM edge behaviour. In other words, > | such an operator has made the decision that the simpler edge > | mechanism (in terms of not having to measure rates) is > | important enough that they don't mind termination being > | slower than ideal if there's an overloaded node. > | > | > | Comments? > | Phil/ > | > | > -----Original Message----- > | > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > | Behalf Of > | > Steven Blake > | > Sent: 20 April 2008 18:41 > | > To: pcn > | > Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6 > | > > | > On Mon, 2008-03-31 at 13:18 -0400, Steven Blake wrote: > | > > Here are the remaining three questions that were taken during the > | IETF > | > > 71 meeting: > | > > > | > > Q4: Should the standards-track PCN scheme require (as a MUST > | implement > | > > feature) that interior PCN routers support > | Excess-Rate marking, > | > > according to the particular method of handling already marked > | > > packets and drops described in Anna Charny's presentation? > | > > http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf > | > > > | > > Q5: Should the standards-track PCN scheme require (as a MUST > | implement > | > > feature) that interior PCN routers support Threshold > | marking (in > | > > addition to Excess-Rate marking), according to the particular > | method > | > > described in Philip Eardley's presentation on Tuesday? > | > > http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf > | > > > | > > Q6: If presented with sufficient evidence in a timely > | fashion, would > | > > the PCN wg entertain the option of modifying the > | interior router > | > > Excess-Rate marking behavior for the standards-track > | PCN scheme > | (as > | > > described in question 4)? > | > > > | > > According to the draft meeting minutes, Q4 was accepted 8-0 (my > | notes > | > > have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0. > | > > | > The feedback from the list for Q4 and Q5 seems to match up closely > | with > | > the results in the meeting (not surprising, as it was > | mostly the same > | > individuals commenting). I counted one dissent for Q4 and > | one for Q5. > | > > | > The feedback for Q6 was a mixture of abstain and Yes with > | caveats. If > | > and when someone wants to propose modifications to the Excess-Rate > | > marking behavior, we can see if there is interest to > | discuss it on the > | > list, but I *strongly encourage* that any such discussion needs to > | > happen before the Dublin meeting. > | > > | > We seem to have consensus to go forward with a standards-track > | proposal > | > supporting two encoding states, with Excess-Rate and > | Threshold marking > | > as MUST implement features. In addition, we are open to work on one > | or > | > more experimental-track proposals (as a lower priority > | acitivity) that > | > are extensions of the standards-track proposal, using an additional > | > encoding state. > | > > | > This is a call for volunteers to start working on drafts for the > | > standards-track interior node detection, (in-band) PCN encoding, > | > egress-ingress feedback protocol, and boundary node mechanisms, as > | > spelled out in the PCN charter. > | > > | > Note: I will be (mostly) off line for the rest of the week. > | > > | > > | > Regards, > | > > | > // Steve > | > > | > _______________________________________________ > | > PCN mailing list > | > PCN@ietf.org > | > https://www.ietf.org/mailman/listinfo/pcn > | _______________________________________________ > | PCN mailing list > | PCN@ietf.org > | https://www.ietf.org/mailman/listinfo/pcn > | _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Apr 29 07:40:34 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E09B28C26C; Tue, 29 Apr 2008 07:40:34 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A29333A6933 for ; Tue, 29 Apr 2008 07:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_ASCII0=1.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rA-GTBTSUL4I for ; Tue, 29 Apr 2008 07:40:24 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 4CF7D28C263 for ; Tue, 29 Apr 2008 07:40:24 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Apr 2008 15:40:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Apr 2008 15:40:25 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34793@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCN Marking behaviour draft Thread-Index: AciqBvYMkALL4m5ATeiUkDCafRgG3Q== From: To: X-OriginalArrivalTime: 29 Apr 2008 14:40:26.0275 (UTC) FILETIME=[F688DF30:01C8AA06] Subject: [PCN] PCN Marking behaviour draft X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1299624124==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1299624124== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AA06.F6242184" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AA06.F6242184 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I've just posted a draft which tries to specify the marking behaviour for PCN nodes. =20 It's based on an update of the emails I sent shortly before the last IETF. Updates include adjusting as a result of the WG consensus call on Steven's Questions 1 to 6. Many thanks to Joe, Michael & Anna who've made suggestions and comments about it. Overall I think it's much improved compared to the emails. =20 Comments please! =20 Thanks Phil/. =20 =20 =20 -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: 29 April 2008 15:33 To: Eardley,PL,Philip,CXR9 R Subject: New Version Notification for draft-eardley-pcn-marking-behaviour-00=20 =20 =20 A new version of I-D, draft-eardley-pcn-marking-behaviour-00.txt has been successfuly submitted by Philip Eardley and posted to the IETF repository. =20 Filename: draft-eardley-pcn-marking-behaviour Revision: 00 Title: Marking behaviour of PCN-nodes Creation_date: 2008-04-29 WG ID: Independent Submission Number_of_pages: 15 =20 Abstract: This document standardises the two marking behaviours of PCN-nodes: threshold marking and excess traffic marking. Threshold marking marks all PCN-packets if the PCN traffic rate is greater than a first configured rate. Excess traffic marking marks a proportion of PCN- packets, such that the amount marked equals the traffic rate in excess of a second configured rate.Requirements Language =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. =20 =20 =20 The IETF Secretariat. =20 =20 =20 ------_=_NextPart_001_01C8AA06.F6242184 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

I’ve just posted a draft which tries to = specify the marking behaviour for PCN nodes.

 

It’s based on an update of the emails I = sent shortly before the last IETF. Updates include adjusting as a result of = the WG consensus call on Steven’s Questions 1 to 6. Many thanks to Joe, = Michael & Anna who’ve made suggestions and comments about it. Overall = I think it’s much improved compared to the emails.

 

Comments please!

 

Thanks

Phil/.

 

 

 

-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
Sent: 29 April 2008 15:33
To: Eardley,PL,Philip,CXR9 R
Subject: New Version Notification for = draft-eardley-pcn-marking-behaviour-00

 

 

A new version of I-D, draft-eardley-pcn-marking-behaviour-00.txt = has been successfuly submitted by Philip Eardley and posted to the IETF = repository.

 

Filename:   = draft-eardley-pcn-marking-behaviour

Revision:   00

Title:          = ; =20 Marking behaviour of PCN-nodes

Creation_date:    2008-04-29

WG = ID:           =20 Independent Submission

Number_of_pages: 15

 

Abstract:

This document standardises the two marking behaviours of = PCN-nodes:

threshold marking and excess traffic marking.  Threshold = marking

marks all PCN-packets if the PCN traffic rate is greater than a = first

configured rate.  Excess traffic marking marks a proportion = of PCN-

packets, such that the amount marked equals the traffic rate = in

excess of a second configured rate.Requirements = Language

 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT",

"SHOULD", "SHOULD NOT", = "RECOMMENDED", "MAY", and "OPTIONAL" in this

document are to be interpreted as described in RFC 2119 = [RFC2119].

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;         

 

 

The IETF Secretariat.

 

 

 

=00 ------_=_NextPart_001_01C8AA06.F6242184-- --===============1299624124== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1299624124==--