From pcn-bounces@ietf.org Tue Sep 04 12:17:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISb5h-0005Pi-Ms; Tue, 04 Sep 2007 12:17:25 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1ISb5f-0005PO-LW for pcn-confirm+ok@megatron.ietf.org; Tue, 04 Sep 2007 12:17:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISb5f-0005PG-AS for pcn@ietf.org; Tue, 04 Sep 2007 12:17:23 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISb5e-0005hY-Rt for pcn@ietf.org; Tue, 04 Sep 2007 12:17:23 -0400 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 l84GHJU09605; Tue, 4 Sep 2007 16:17:20 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Sep 2007 12:17:18 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646511F3865C@zcarhxm1.corp.nortel.com> In-Reply-To: <5.2.1.1.2.20070830085617.03efed38@pop3.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-babiarz-pcn-3sm-00 pseudocode nit Thread-Index: Acfq3WXzubgNwhsSRIyfUUjAhOAWeAEK9YWQ References: <5.2.1.1.2.20070830085617.03efed38@pop3.jungle.bt.co.uk> From: "Jozef Babiarz" To: "Bob Briscoe" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: pcn@ietf.org Subject: [PCN] RE: draft-babiarz-pcn-3sm-00 pseudocode nit X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Bob,=20 We selected this approach to reduce the number of instructions. Our original rational was, since the pseudo-code in the "if" statement does not subtract packet.size there is no need to set TB.fill =3D 0. We believe there would be no meaningful difference between leaving the TB at TB.fill versus empty since the TB is less than the size of the packet from being empty and we are doing threshold marking. We also assumed that TB.threshold is several times larger than the size of the largest packet.=20 Let us know if you disagree and we can add TB.fill =3D 0; line to the example pseudo-code. =20 Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk]=20 Sent: August 30, 2007 4:11 AM To: Babiarz, Jozef (CAR:0S03) Cc: pcn@ietf.org Subject: draft-babiarz-pcn-3sm-00 pseudocode nit Joe, In the admission marking pseudo-code in draft-babiarz-pcn-3sm-00 S.2.2.2,=20 if a packet arrives that is larger than the current depth of the token=20 bucket, you correctly mark the packet with admission stop marking, but I think you've omitted to empty the bucket to zero as well. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ if (TB.fill < packet.size) TB.fill =3D 0; // BB: Suggested amendment packet.mark =3D AS; else TB.fill =3D TB.fill - packet.size; if (TB.fill < TB.threshold) packet.mark =3D AS; endif endif /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Bob ________________________________________________________________________ ____ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 05 09:25:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISusj-0008QP-V9; Wed, 05 Sep 2007 09:25:21 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1ISusi-0008MG-HU for pcn-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 09:25:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISush-0008Ll-Q7 for pcn@ietf.org; Wed, 05 Sep 2007 09:25:19 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISusg-0003NK-II for pcn@ietf.org; Wed, 05 Sep 2007 09:25:19 -0400 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 l85DPFq15370; Wed, 5 Sep 2007 13:25:16 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: [PCN] RE: draft-babiarz-pcn-3sm-00 pseudocode nit Date: Wed, 5 Sep 2007 09:25:10 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646511FB8E95@zcarhxm1.corp.nortel.com> In-Reply-To: <5.2.1.1.2.20070904191255.03b0eda0@pop3.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: [PCN] RE: draft-babiarz-pcn-3sm-00 pseudocode nit Thread-Index: AcfvMKzSbDzPZuIXRQaeL2EnFI6LXAAjs7jA References: <9671A92C3C8B5744BC97F855F7CB646511F38679@zcarhxm1.corp.nor tel.com> <5.2.1.1.2.20070904191255.03b0eda0@pop3.jungle.bt.co.uk> From: "Jozef Babiarz" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: PCN IETF list X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Bob,=20 No problem, added the one line to S.2.2.2 TB.fill =3D 0; // BB: Suggested amendment Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk]=20 Sent: September 4, 2007 4:18 PM To: Babiarz, Jozef (CAR:0S03) Cc: PCN IETF list Subject: Re: FW: [PCN] RE: draft-babiarz-pcn-3sm-00 pseudocode nit Joe, OK, I understand the desire to reduce the no. of instructions, and that=20 this accuracy isn't deadly important. But it's in the smaller branch and the less typically used branch of the two anyway. So it doesn't reduce the max intructions per packet, nor even=20 the typical instructions per packet. It only saves one instruction for a packet arriving in one fairly rare case. It just gives a TB with a depth that isn't predictable - instead the depth=20 is approximately the same but the exact depth experienced depends on the history of previously arrived packets. Larger packets tend to see a TB with=20 slightly less depth (probabilistically) than smaller ones, because whenever=20 a larger packet arrives at a bucket with fill less than the packet's size,=20 it invokes this approximate code, while a smaller packet won't, necessarily. I doubt there's a huge problem doing that. The only problem I can think of=20 is it will be less easy to verify experimentally against an analytical=20 model of the bucket. As I said, a nit that we don't really need to talk about at the IETF - I wouldn't expect us to have to standardise whether or not this happens! [PS - tho my jungle mail @ seems OK now, I'll look into why it bounced - let me know if you get a bounce again.] Bob At 17:23 04/09/2007, Jozef Babiarz wrote: >Bob, I'm forwarding you this email as I got a bounce from >rbriscoe@jungle.bt.co.uk > >Regards, Joe >email:babiarz@nortel.com >Telephone:613-763-6098 > >-----Original Message----- >From: Babiarz, Jozef (CAR:0S03) >Sent: September 4, 2007 12:17 PM >To: Bob Briscoe >Cc: pcn@ietf.org >Subject: [PCN] RE: draft-babiarz-pcn-3sm-00 pseudocode nit > >Bob, >We selected this approach to reduce the number of instructions. >Our original rational was, since the pseudo-code in the "if" statement >does not subtract packet.size there is no need to set TB.fill =3D 0. We >believe there would be no meaningful difference between leaving the TB >at TB.fill versus empty since the TB is less than the size of the packet >from being empty and we are doing threshold marking. We also assumed >that TB.threshold is several times larger than the size of the largest >packet. > >Let us know if you disagree and we can add TB.fill =3D 0; line to the >example pseudo-code. > >Regards, Joe >email:babiarz@nortel.com >Telephone:613-763-6098 >-----Original Message----- >From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] >Sent: August 30, 2007 4:11 AM >To: Babiarz, Jozef (CAR:0S03) >Cc: pcn@ietf.org >Subject: draft-babiarz-pcn-3sm-00 pseudocode nit > >Joe, > >In the admission marking pseudo-code in draft-babiarz-pcn-3sm-00 >S.2.2.2, >if a packet arrives that is larger than the current depth of the token >bucket, you correctly mark the packet with admission stop marking, but I > >think you've omitted to empty the bucket to zero as well. > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > if (TB.fill < packet.size) > TB.fill =3D 0; // BB: Suggested amendment > packet.mark =3D AS; > else > TB.fill =3D TB.fill - packet.size; > if (TB.fill < TB.threshold) > packet.mark =3D AS; > endif > endif >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > >Bob > > >_______________________________________________________________________ _ >____ >Bob Briscoe, Networks Research Centre, BT >Research >B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 >645196 > > > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn ________________________________________________________________________ ____ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Sep 06 13:14:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITKwP-0008VZ-Ao; Thu, 06 Sep 2007 13:14:53 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1ITKwN-0008VU-Qr for pcn-confirm+ok@megatron.ietf.org; Thu, 06 Sep 2007 13:14:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITKwN-0008VM-Gx for pcn@ietf.org; Thu, 06 Sep 2007 13:14:51 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITKwL-0005AD-Ty for pcn@ietf.org; Thu, 06 Sep 2007 13:14:51 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 18:14:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN architecture new section on tunnelling Date: Thu, 6 Sep 2007 18:14:48 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC4A3@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <6439282641581441A36F7F6F83ED2ED201DB9B29@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture new section on tunnelling Thread-Index: AcfevdVkvekXSAdHR5aLqYZsjoBFagERiMywAiU4pNABQ+08sA== From: To: X-OriginalArrivalTime: 06 Sep 2007 17:14:48.0648 (UTC) FILETIME=[6DD9D480:01C7F0A9] X-Spam-Score: -1.0 (-) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Ruediger, In-line - thanks phil > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 31 August 2007 07:46 > To: Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org > Subject: RE: [PCN] PCN architecture new section on tunnelling >=20 > Phil, >=20 > is the mentioned "knowing what the PCN-ingress-node is, done > at the signaling level" described in more detail in one of > the documents already? [phil] http://www.watersprings.org/pub/id/draft-lefaucheur-rsvp-ecn-01.txt [& http://www.watersprings.org/pub/id/draft-briscoe-tsvwg-cl-architecture-0 4.txt] - I think try to do this, with rsvp as the signalling example >=20 > RSVP is not supposed to be tunneled to all places. If a PCN > related RSVP message is tunneled through a PCN ingress router, > the tunnel terminates in the middle of a PCN domain and the > RSVP message continues through a PCN domain egress, I'd > regard this as a security incident. May be the message should > simply be ignored - dropping is another alternative. The > possibility to insert RSVP (or other signaling messages) that > way requires authentication for the signaling between PCN > ingress and egress nodes. [phil] yes you're right. in this case where the ingress doesn't see the rsvp msg, then presumably adm ctrl isn't triggered so the flow wouldn't be admitted.=20 >=20 > Regards, >=20 > Ruediger >=20 > |-----Original Message----- > |From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > |Sent: Monday, August 20, 2007 10:46 AM > |To: menth@informatik.uni-wuerzburg.de; babiarz@nortel.com > |Cc: pcn@ietf.org > |Subject: RE: [PCN] PCN architecture new section on tunnelling > | > | > |Michael > | > |Good points. To me your tunnelling analysis is another example of > |multi-path; like ECMP it's quite tricky for PCN. > | > |for flow termination, this can be solved by terminating flows that are > |actually marked (3sm-draft is one example, the Briscoe-cl-architecture > |gave another). > | > |For adm ctrl, the solutions seem to be: > |- tunnel all traffic between PCN-ingress-node and PCN-egress-node (I > | think this works for your tunnelling examples as well as for ECMP) > |- accept the adm decision is approximate; > |- do probing for each flow admission > | > |in terms of knowing what the PCN-ingress-node is (so that you > |know where to do policing to enforce the adm decision), wouldn't > |this still be done at the signalling level? I suppose the > |question is then what happens if eg rsvp is tunnelled? > | > |phil > | > |> -----Original Message----- > |> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > |> Sent: 14 August 2007 22:52 > |> To: Jozef Babiarz > |> Cc: Eardley,PL,Philip,CXR9 R; pcn@ietf.org > |> Subject: Re: [PCN] PCN architecture new section on tunnelling > |> > |> Hi, > |> > |> Imagine a packet is tunneled from node A to some other node B, it is > |> decapsulated there and forwarded to destination C. Then, the traffic > |> takes the route from A over B to C. > |> 1st problem: how do we find the ingress node X of the packet at its > |PCN > |> egress Y? > |> 2nd problem: provided that we know the ingress node X, the > |path from A > |> over B to C does not necessarily coincide with normal IP routed path > |> from the corresponding PCN ingress X to egress Y. If those > |packets are > |> admission marked, they may cause admission stop for traffic from X to > |Y > |> although they take a different path. > |> > |> Thus, the problem is that we associate the > |admission-stop-marking with > |> the path from the ingress to the egress of the packet. If the packet > |> took a different path than by typical IP routing, the interpretation > |of > |> the PCN information is leads to the wrong conclusions. Similar > |problems > |> occur with excess-traffic-marked packets if the corresponding PCN > |> information is associated with the path. The marked flow termination > |> (MFT) from the 3sm-draft associates the marking with the flow and can > |> cope well with arbitrarily routed flows. > |> > |> Possible solution: the marking from X to B needs to be evaluated at B > |> and be associated with the path from X to B, and the marking received > |> from B to Y needs to be evaluated at Y and be associated > |with the path > |> from B to Y. > |> > |> I just want to say: tunneling with tunnel endpoints in PCN > |networks is > |> not yet understood. > |> > |> Best wishes, > |> > |> Michael > |> > |> Jozef Babiarz wrote: > |> > > |> > Phil, please see my comment below demarked with [Joe]. > |> > > |> > /Regards, Joe/ > |> > email:babiarz@nortel.com > |> > Telephone:613-763-6098 > |> > > |> > > |--------------------------------------------------------------- > |--------- > |> > > |> > *From:* philip.eardley@bt.com [mailto:philip.eardley@bt.com] > |> > *Sent:* August 8, 2007 6:14 PM > |> > *To:* pcn@ietf.org > |> > *Subject:* [PCN] PCN architecture new section on tunnelling > |> > > |> > This is to flag up that I wrote a new sub-section (in Section 5, > |> > Detailed functional architecture) about tunelling: > |> > > |> > 5.8. Tunnelling > |> > > |> > It is possible that tunnels terminate at a PCN-node. It is > |important > |> > > |> > that any PCN-marking is preserved after decapsulation, so > |that it is > |> > > |> > still seen by the PCN-egress-node. To ensure this, on decapsulation > |> > > |> > the following rules are applied: > |> > > |> > o the PCN-marking state of the inner and outer headers are compared > |> > > |> > o if the inner header's marking state is more severe then it is > |> > > |> > preserved > |> > > |> > o if the outer header's marking state is more severe then it is > |> > > |> > copied onto the inner header > |> > > |> > o NB the order of increasing severity is: unmarked; > |PCN-marking with > |> > > |> > first encoding (ie associated with the PCN-lower-rate); PCN- > |> > > |> > marking with second encoding (ie associated with the PCN-upper- > |> > > |> > rate) > |> > > |> > Similarly, if encapsulation is done within the PCN-domain, then the > |> > > |> > following rule is applied: > |> > > |> > * any PCN-marking is copied into the outer header > |> > > |> > [Joe] The above may introduce unnecessary information leakage. Why > |not > |> > just at the encapsulation point mark all packets as unmarked. The > |> > decapsulation point can sort them out. Just realizes that excess > |rate > |> > marking approach will not work unless PCN-marking information is > |> > copied from inner to outer headers when encapsulating. [end] > |> > > |> > [Joe] I'm assuming for time being that "PCN nonce" (similar to ECN > |> > nonce) is out of scope as we are not sure if it's need for PCN. If > |not > |> > than the "PCN nonce" would also need to be copied to outer header. > |[end] > |> > > |> > Tunnelling considerations also depend on which header bits the PCN > |WG > |> > > |> > decides to use. If the ECN bits are used then > |> > > |> > [I-D.briscoe-tsvwg-ecn-tunnel] applies; the rules above conform to > |> > > |> > its spirit. If the DSCP field is used then [RFC2983] needs to be > |> > > |> > considered carefully. > |> > > |> > An operator may wish to tunnel PCN-traffic from > |PCN-ingress-nodes to > |> > > |> > PCN-egress-nodes, in which case the rules above aren't needed. The > |> > > |> > potential reasons for doing such tunnelling are: the > |PCN-egress-node > |> > > |> > then automatically knows the address of the relevant > |PCN-ingress-node > |> > > |> > for a flow; even if ECMP is running, all PCN-packets on a > |particular > |> > > |> > ingress-egress-aggregate follow the same path. But it also has > |> > > |> > drawbacks: additional overhead in terms of bandwidth and > |processing; > |> > > |> > and the effective elimination of ECMP as a load balancing > |mechanism. > |> > > |> > > |--------------------------------------------------------------- > |--------- > |> > > |> > _______________________________________________ > |> > PCN mailing list > |> > PCN@ietf.org > |> > https://www1.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://www1.ietf.org/mailman/listinfo/pcn > | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Sep 06 13:28:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITL9b-0003LT-3h; Thu, 06 Sep 2007 13:28:31 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1ITL9a-0003F9-8u for pcn-confirm+ok@megatron.ietf.org; Thu, 06 Sep 2007 13:28:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITL9Z-0003Dq-TA for pcn@ietf.org; Thu, 06 Sep 2007 13:28:29 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITL9Y-0005Zd-9b for pcn@ietf.org; Thu, 06 Sep 2007 13:28:29 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 18:28:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] RE: ECN & EF Date: Thu, 6 Sep 2007 18:28:27 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC4A4@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] RE: ECN & EF Thread-Index: AcfqdLGmAktGVKJASv+bTuN99cGX+AGNXvKQ From: To: X-OriginalArrivalTime: 06 Sep 2007 17:28:27.0311 (UTC) FILETIME=[55CFE3F0:01C7F0AB] X-Spam-Score: 0.8 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Looking at the various comments in this thread, my proposal is to amend the architecture draft so it says David's option b) below, and mention Ruediger's "CBR-like" case - plus add (by way of explanation) a reference back to Assumption 2 (real time appls generating inelastic traffic).=20 Ok? Phil/ > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: 29 August 2007 20:42 > To: Black_David@emc.com > Cc: Eardley,PL,Philip,CXR9 R; pcn@ietf.org > Subject: Re: [PCN] RE: ECN & EF >=20 > AF is proposed for video because video has variable traffic and one > might want to mark frames of lower delivery importance with a higher > drop probability. Think layered codecs and the difference between I > frames and other types of frames. That said, I would be hard pressed > to recommend it for voice unless the other characteristics were such > that the math in RFC 3247 was supported. >=20 > What PHB one uses is all about what the characteristics of the > intended applications are. I would be pretty hesitant to use PCN in > an environment where you couldn't run an entire session and perhaps > several in the margin zone - if suddenly adding 10% more sessions > simultaneously when things are at the edge is going to disrupt > existing sessions, the margins are too tight. For that reason, I > think part of this discussion has got to be "for what application" > and the testing has to include testing it with that application in > live environments. >=20 > On Aug 29, 2007, at 12:20 PM, Black_David@emc.com wrote: >=20 > > Phil, > > > > EF PHB has the right properties for this traffic, but it's not the > > only way to get them. I think the decision on the table is: > > a) It has to be the EF PHB, vs. > > b) It has to be similar to the EF PHB, but need not be > > exactly the EF PHB. > > For the latter, over-provisioned AF may be another way to do this. > > > > I don't have a strong opinion on which alternative we choose, but > > one of them does have to be chosen. > > > > Thanks, > > --David > > > >> -----Original Message----- > >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > >> Sent: Wednesday, August 29, 2007 3:45 AM > >> To: steven.blake@ericsson.com > >> Cc: pcn@ietf.org > >> Subject: [PCN] RE: ECN & EF > >> > >> Steven, > >> Thanks - my perspective is in-line > >> phil > >> > >>> -----Original Message----- > >>> From: Steven Blake [mailto:steven.blake@ericsson.com] > >>> Sent: 24 August 2007 23:06 > >>> To: Eardley,PL,Philip,CXR9 R > >>> Cc: pcn@ietf.org > >>> Subject: ECN & EF > >>> > >>> [Chair hat off] > >>> > >>> Philip et. al., > >>> > >>> I see that in Sec. 3.5 of the architecture draft, you assume: > >>> > >>> - Packets with ECN CE markings arriving at a PCN ingress router > >>> are automatically dropped. > >>> > >>> - EF PHB is assumed for all PCN-managed traffic. > >>> > >>> I asked previously if we needed to make the first > >> assumption when ECN > >>> header bits are NOT being used to signal PCN markings. As > >> far as I know > >>> the answer is no. So I would suggest you either (a) write up a > >>> rationale for assuming this, or (b) mention that it is only an issue > >>> when re-using the ECN bits for PCN marking (which we haven't decided > >>> yet). > >> > >> Yes, I think your option b) is true. I'll modify this section > >> to say this. > >> > >>> > >>> Regarding the second assumption, it might or might not be a sensible > >>> idea in most circumstances, but I cannot think of a > >> rationale as to why > >>> it is required. So I suggest that you also come up with a > >> rationale for > >>> this assumption, or weaken the statement in the draft. > >> > >> It's basically Assumption 2 (Section 3.2), "We assume that PCN- > >> packets > >> come from real time applications > >> generating inelastic traffic [Shenker] like voice and > >> video requiring > >> low delay, jitter and packet loss, for example the Controlled Load > >> Service, [RFC2211], and the Telephony service class, [RFC4594]." > >> > >> I don't think the EF PHB is intended to say anything > >> different (is that > >> true?), although you could argue they're not the same. > >> > >> The justification in S3.2 says: "This > >> assumption is to help focus the effort where it looks like > >> PCN would > >> be most useful, ie the sorts of applications where per > >> flow QoS is a > >> known requirement." > >> > >> this is true, although personally I think there's more to it > >> than that - > >> we don't really understand how the 'Many flows' assumption > >> (Section 3.3) > >> works for rate adaptive traffic. Compared with VBR traffic, rate > >> adaptive tends to have much coarser changes of rate (bigger jumps, > >> sticks at new rate for longer time), which probably makes it > >> harder to > >> get nicely behaving aggregated traffic. The other thing for rate > >> adaptive traffic is to imagine if the PCN-domain is the part of the > >> end-to-end path with the bandwidth constraint. One could imagine > >> after > >> flows had been admitted that the rates start adapting upwards. There > >> would be no pkt drops to trigger the sources to adapt their rates > >> downwards, and so flow termination would eventually kick in. > >> I think the > >> safety margins you'd need to allow would be greater than for VBR > >> sources. However, we haven't (as far as I know) investigated how much > >> harder rate adaptive sources would be for PCN than VBR ones > >> (whether you > >> just have to be more cautious and allow bigger safety margins, or > >> whether it doesn't really work). Hence the assumption in S3.2. > >> > >> So my suggestion would be to keep the statement about EF PHB but > >> add a > >> reference to S3.2 and say something like "it isn't intended > >> to be saying > >> anything different to this" > >> > >> Comments? > >> > >> > >>> > >>> > >>> Regards, > >>> > >>> = =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 > >>> Ericsson/Redback Networks +1 919-472-9913 > >> > >> > >> > >> _______________________________________________ > >> PCN mailing list > >> PCN@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pcn > >> > >> > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Sep 07 18:48:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITmcg-0006ib-62; Fri, 07 Sep 2007 18:48:22 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1ITmce-0006aR-H2 for pcn-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 18:48:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITmce-0006Ya-4x for pcn@ietf.org; Fri, 07 Sep 2007 18:48:20 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITmcd-0002v2-Mq for pcn@ietf.org; Fri, 07 Sep 2007 18:48:20 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l87MswWe023032 for ; Fri, 7 Sep 2007 17:54:58 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 17:48:18 -0500 Received: from [147.117.169.108] ([147.117.169.108]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 17:48:18 -0500 From: Steven Blake To: pcn Content-Type: multipart/mixed; boundary="=-U9qfM/J8Hr+Pe2CPFWwp" Organization: Ericsson IP Infrastructure Date: Fri, 07 Sep 2007 18:48:18 -0400 Message-Id: <1189205298.25316.75.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-OriginalArrivalTime: 07 Sep 2007 22:48:18.0521 (UTC) FILETIME=[2F13E490:01C7F1A1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Subject: [PCN] [Fwd: Nomcom 2007-8: Nominations Close on Sep 10, 2007] X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org --=-U9qfM/J8Hr+Pe2CPFWwp Content-Type: text/plain Content-Transfer-Encoding: 7bit FYI =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 --=-U9qfM/J8Hr+Pe2CPFWwp Content-Disposition: inline Content-Description: Forwarded message - Nomcom 2007-8: Nominations Close on Sep 10, 2007 Content-Type: message/rfc822 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw720.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 14:55:17 -0500 Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 14:55:17 -0500 Received: from esealmw127.eemea.ericsson.se ([130.100.184.162]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 21:55:15 +0200 Received: from mailgw8.ericsson.se ([193.180.251.59]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 21:55:15 +0200 Received: from mailgw8.ericsson.se (unknown [127.0.0.1]) by mailgw8.ericsson.se (Symantec Mail Security) with ESMTP id 41A1810A1F; Fri, 7 Sep 2007 21:55:14 +0200 (CEST) X-AuditID: c1b4fb3b-af675bb0000007dc-7f-46e1ac0d159f Received: from megatron.ietf.org (lists.ietf.ORG [156.154.16.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgw8.ericsson.se (Symantec Mail Security) with ESMTP id E15DF11050; Fri, 7 Sep 2007 21:52:44 +0200 (CEST) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITjsb-0006ns-IT; Fri, 07 Sep 2007 15:52:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITjsY-0006Ua-3P; Fri, 07 Sep 2007 15:52:34 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITjsW-00027j-QH; Fri, 07 Sep 2007 15:52:34 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l87JqT0H017541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 7 Sep 2007 12:52:30 -0700 Received: from [10.50.69.196] (qconnect-10-50-69-196.qualcomm.com [10.50.69.196]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l87JqSO1025798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Sep 2007 12:52:29 -0700 Message-ID: <46E1AC01.3050800@qualcomm.com> Date: Fri, 07 Sep 2007 12:52:33 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ietf-announce@ietf.org, wgchairs@ietf.org, IESG IESG , IAB IAB Content-Type: text/plain; charset=ISO-8859-15; format=flowed X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: Nomcom 2007-8: Nominations Close on Sep 10, 2007 X-BeenThere: wgchairs@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working Group Chairs List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: wgchairs-bounces@ietf.org X-Brightmail-Tracker: AAAAAA== Return-Path: wgchairs-bounces@ietf.org X-OriginalArrivalTime: 07 Sep 2007 19:55:15.0459 (UTC) FILETIME=[024A5D30:01C7F189] Content-Transfer-Encoding: 7bit WGchairs, IESG and IAB members Please forward this request to the lists you manage and request feedback and nominations. All, Here is the link to nominate: https://tools.ietf.org/group/nomcom/07/nominate You may also send nominations or comments via email to nomcom07@ietf.org or ldondeti@qualcomm.com. We have received very few nominations (1, 2, 2, 2, 3, 4, 8, 8, 19) and even fewer accepted (1-2 people in each area, IAB acceptances is 4 at last count). I request the community to provide feedback on the incumbents (send email or send notes via the web page). 1) If you think that the incumbent is doing a good job a) provide feedback AND b) nominate similar people just in case there is strong negative feedback on the incumbent 2) If you think the incumbent can do somethings better a) provide feedback AND b) nominate someone who you think might do better Candidates, if time commitment is the only issue, please indicate that to the nomcom and accept the nominations. thanks, Lakshminath --=-U9qfM/J8Hr+Pe2CPFWwp 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://www1.ietf.org/mailman/listinfo/pcn --=-U9qfM/J8Hr+Pe2CPFWwp-- From pcn-bounces@ietf.org Tue Sep 11 07:36:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV42d-0001Ng-3B; Tue, 11 Sep 2007 07:36:27 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IV42c-0001Kv-30 for pcn-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 07:36:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV42b-0001J5-P2 for pcn@ietf.org; Tue, 11 Sep 2007 07:36:25 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV42a-0008BZ-Eg for pcn@ietf.org; Tue, 11 Sep 2007 07:36:25 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l8BBaOYw004824 for ; Tue, 11 Sep 2007 06:36:24 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 06:36:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Sep 2007 06:36:22 -0500 Message-ID: In-Reply-To: <1189205298.25316.75.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LC-PCN version 01 uploaded Thread-Index: AcfxoTfiMvYaDfTgQ9adZz5poNI4WwCxk0Og References: <1189205298.25316.75.camel@neutrino> From: "Anurag Bhargava (RL/TNT)" To: "pcn" X-OriginalArrivalTime: 11 Sep 2007 11:36:23.0945 (UTC) FILETIME=[FB5EC790:01C7F467] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [PCN] LC-PCN version 01 uploaded X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hello, FYI - We have uploaded a new version of the PCN draft. The major changes are some clarification and adopting to the Architecture draft terminology. "LC-PCN: The Load Control PCN Solution", Lars Westberg, 5-Sep-07,=20 =20 Please let me know if you have any questions. Thanks, -Anurag Bhargava, Ph.D. _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Sep 13 11:27:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVqbA-0001FI-B6; Thu, 13 Sep 2007 11:27:20 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IVqb9-0001F1-3u for pcn-confirm+ok@megatron.ietf.org; Thu, 13 Sep 2007 11:27:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVqb8-0001Et-PF for pcn@ietf.org; Thu, 13 Sep 2007 11:27:18 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVqb7-0007hp-AK for pcn@ietf.org; Thu, 13 Sep 2007 11:27:18 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 16:27:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] LC-PCN version 01 uploaded Date: Thu, 13 Sep 2007 16:27:15 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC4E4@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] LC-PCN version 01 uploaded Thread-Index: AcfxoTfiMvYaDfTgQ9adZz5poNI4WwCxk0OgAGsQTGA= From: To: , X-OriginalArrivalTime: 13 Sep 2007 15:27:16.0755 (UTC) FILETIME=[911D5630:01C7F61A] X-Spam-Score: -1.0 (-) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Anurag Thanks for the revised draft, I can understand it much better. Here are some questions /misunderstandings. Let me summarise to make sure I understand it right. - two encodings are used. one ('PCN-marking') is used for both adm ctrl & termination to indicate the excess traffic. If a PCN-interior-node is PCN-marking some pkts, then it marks all other pkts with another encoding ('affected marking') - the 'PCN-marking' algorithm has several regimes: * when traffic rate is below PCN-lower-rate, no pkts are marked=20 * as the traffic rate climbs above the PCN-lower-rate, an increasing number of pkts are marked (marking rate =3D excess rate divided by N) = [adm ctrl state] * at some rate (PCN-lower-rate + adm-offset-rate), then pkts are marked at the same rate, even if the traffic rate climbs higher [adm ctrl state] * when the traffic rate reaches the PCN-upper-rate, additional pkts are marked (additional marking rate =3D excess rate above PCN-upper-rate divided by N) [termination ctrl state] * if pkts arrive already PCN-marked, then the node measures the rate of pkts already marked & works out what excess rate this corresponds to, and only marks additional pkts if its own excess rate is even higher.=20 * the PCN-egress-node measures the rate of PCN-marked pkts and determines whether the overloaded node is in adm ctrl state or termination ctrl state Questions: - I don't understand the point of doing PCN-marking in the adm ctrl state. When it comes to making an adm decision, you send a (single) probe pkt - if it's PCN-marked or affected-marked then you block the call. So when a node's in the adm ctrl state, it could just do affected-marking of all pkts. Wouldn't that work just as well? - with you current algo, imagine there are two paths through the nw:=20 A-B-X-D A-M-N-X-D If B & N are both in adm ctrl state then they both will do PCN-marking. At the PCN-egress-node the PCN-marking rate may be high enough that it believes termination is needed. Are there topologies/scenarios where this could happen? I think your multicongestion_error parameter in S3.4 is connected to this problem; I didn't find your discussion about it convincing - the 'affected marking' is claimed to solve ECMP issues. However, the same affected marking is used in both adm ctrl state & termination ctrl state - I don't think this works. Imagine that a node [node-1] on one path is in adm ctrl state & a node [node-2] on another path is in termination ctrl state. Therefore flows are terminated, and only flows that are being PCN-marked or affected-marked are terminated. However this could lead to flows being terminated that go through node-1; node-2 will still be just as badly overloaded.=20 - in the termination algorithm, S4.2.2, the "termination_offset_rate" factor makes no sense to me - the parameters PCN_lower_rate_egress & PCN_upper_rate_egress are expressed in the wrong units (you have conditions like signalled_overload_rate > PCN_lower_rate_egress; the former is a rate, the latter a % so some tweaking is needed to convert the latter into a rate) best wishes phil/ > -----Original Message----- > From: Anurag Bhargava (RL/TNT) [mailto:anurag.bhargava@ericsson.com] > Sent: 11 September 2007 12:36 > To: pcn > Subject: [PCN] LC-PCN version 01 uploaded >=20 > Hello, > FYI - We have uploaded a new version of the PCN draft. The major > changes are some clarification and adopting to the Architecture draft > terminology. >=20 > "LC-PCN: The Load Control PCN Solution", Lars Westberg, 5-Sep-07, > >=20 > Please let me know if you have any questions. >=20 > Thanks, > -Anurag Bhargava, Ph.D. >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Sep 13 23:45:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW27z-0000Nf-2D; Thu, 13 Sep 2007 23:45:59 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IW27x-0000NW-NC for pcn-confirm+ok@megatron.ietf.org; Thu, 13 Sep 2007 23:45:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW27x-0000NO-9t for pcn@ietf.org; Thu, 13 Sep 2007 23:45:57 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IW27t-0007lr-UX for pcn@ietf.org; Thu, 13 Sep 2007 23:45:57 -0400 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 l8E3jRt02379; Fri, 14 Sep 2007 03:45:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking Date: Thu, 13 Sep 2007 23:45:22 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB64651220E275@zcarhxm1.corp.nortel.com> In-Reply-To: <5.2.1.1.2.20070828142632.03935488@pop3.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking Thread-Index: AcfrPccZxuX6Y2GXTSqkmjxrN07GMgLPFP+A References: <6439282641581441A36F7F6F83ED2ED201DB9AB7@S4DE8PSAAFQ.mitte.t-com.de> <6439282641581441A36F7F6F83ED2ED201DB9AB7@S4DE8PSAAFQ.mitte.t-com.de> <5.2.1.1.2.20070828142632.03935488@pop3.jungle.bt.co.uk> From: "Jozef Babiarz" To: "Bob Briscoe" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97e6af02e147a62c66cd1427f9d2887f Cc: pcn@ietf.org, l.andrew@ieee.org, eeschan@cityu.edu.hk, "Geib, Ruediger" X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0277131912==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0277131912== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F681.AFDB2906" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F681.AFDB2906 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bob, Sorry for the delay in resending to your questions. First, I agree with your comments in email to Ruediger, dated Wed 29/08/2007 and would like to emphasize that defining marking that is dimensionless, will allow PCN system to scale. (ie marking meaning pre-congestion state or condition rather than certain rate).=20 On your point that marking should rise gradually then get steeper as the reference rate is approached and rapidly saturate at some point (the reference rate). We need to discuss further. It's not that I'm against this idea, I just do not see how practically we can take advantage of it to control over admission under flash crowd conditions. (more on this topic later in the email) >Joe, >At 15:17 27/08/2007, Jozef Babiarz wrote: >>I think there is a bit more to this issue than just different levels of >>pre-congestion. >> >>For admission control the challenge for PCN is to find out how much new >>traffic can be added on to a specific link or path and not to determine >>the level of congestion. >I agree that the AC challenge for PCN is to find how much new traffic can=20 >be added, but surely not just for a specific link. The full challenge is=20 >for any single ingress edge node to know how much it can add. But it has to=20 >accept the fact that it doesn't know how many other ingress nodes are=20 >competing to add traffic to the same link. (See previous response to=20 >Ruediger - although I don't think you're asking for the same thing, but it=20 >sounds like you are). >more... >>The purpose of admission control is to prevent >>congestion of the service class on link that forwards PCN traffic. PCN >>is deployed in Diffserv networks, with the understanding that PCN >>traffic is forwarded using priority scheduling. >> >>Voice with silence suppression plus calls naturally ending as well new >>calls being added generates highly variable traffic. The marking by >>interior node to indicate that PCN admission threshold is exceeded or >>not, needs to be quick to reflect true traffic levels. >Agreed >>Analysis of the >>marking density and control of response to the marking can be handled at >>the edges. The proposed marking scheme in draft-babiarz-pcn-3sm-00.txt >>for admission control, produces the following behavior, when PCN traffic >>is fare below the admission stop threshold, no packets are marked. As >>the variable traffic increases and some packets exceed the token bucket >>rate (admission stop threshold) they are marked. If additional new >>traffic is allowed to be admitted on to the link, more packets will >>exceed the token bucket rate therefore marking density increases >>possibly until all packets are marked. However, for pure and stable CBR >>traffic you will get a step marking (on-off) where the transition from >>no marking to all packets marked being quick. >I'm not sure which you you are saying is more desirable: [Joe] My thinking is that the ingress node, the one that is controlling admission of new flows needs to know if it can or can not admit new flow, simply yes or no. My assumption is that the ingress node only has limited view of traffic rate and characteristics of the new flow to be admitted, like what would be specified for a VoIP or video conferencing service.=20 I think your suggesting that we provide the ingress node an early warning that traffic is approaching the configured admissible threshold when an egress node sees some marking. The ingress node uses some policy or algorithm to control the admission of new flows when the path is close to admissible threshold. Providing three levels (stop-light methodology) green admit, orange admit with caution, and red stop? >- the outcome with variable traffic (a gradual transition from 0-100% >marking) >- or the outcome for CBR traffic (a step change)? >I think you're saying that a gradual transition is desirable, but that even=20 >with on-off marking you get a gradual transition as long as there's=20 >variation in the traffic, which there usually is. >(See later for my view) [Joe] Yes, with the threshold marking define in 3sm draft you get a transition form no marking to 100% marking. The transition depends on variation of the traffic and settings of the token bucket, size and marking threshold. > >>My view is that PCN should work equally well regardless of the number of >>flows in an ingress-egress aggregate from one to many flows, >Agreed. >>as well >>should work without the need for ingress-egress aggregation concept. >If you mean by this, that a new flow shouldn't need to use information from=20 >existing flows in an aggregate, I agree. That's a performance enhancement,=20 >not an essential function. [Joe] Yes, plus for first flow of aggregate or if the deployment does not use ingress-egress aggregation concepts through tunneling or other methods. >>The >>so called on-off marking approach is not that dependent on the rate of >>ingress-egress traffic meaning that edge node will be able to determine >>if new flow should be admitted based on low bit rate (probe or single >>voice flow) or high bit rate flow(s) passing through the pre-congested >>link. >I think I am agreeing with you in everything you say, except on one point=20 >(if I understand you right). So I'll restate everything I believe, tagged=20 >with whether we're agreeing or disagreeing, to try to reach closure, as >we've been going round these issues for some time (pre-PCN w-g). >Agreement?: A gradual transition in interior admission marking is desirable=20 >as the boundary nodes can always turn this into a threshold or use it in=20 >innovative ways, to be determined. [Joe] Generally in agreement. Not sure if gradual transition is that important. Concern that I have is that links with different rates and different traffic types will affect the behavior of gradual transition from 0-100%. A link that has its admissible threshold configured at 5 Mbps and another at 400 Mbps will produce different range of gradual transition. How is the egress node to determine how close the traffic is to admissible threshold?=20 >Agreement?: Whether the transition is gradual is a serious issue, because a=20 >distributed measurement-based admission control (DMBAC) system like PCN >admits traffic one round trip before it knows whether it should have done.=20 >So in a flash crowd (mass calling event) admissions can overshoot if the=20 >interior admission marking only flips from 0-100% at the last instant.=20 >Whereas if the interior nodes give a gradual increase, the boundary nodes=20 >can use the early warning contingency to be more conservative when >necessary. [Joe] Yes agree. However we will need to quantify this with simulations. Need to point out that for some traffic there is the issue of the start of media packets is delayed (until person answers the phone) after the admission decisions was made.=20 >Agreement: We hope and expect that traffic levels will be variable because=20 >of silence suppression etc. Then step (on-off) marking on interior nodes=20 >will be sufficient. It will still lead to a gradual increase in admission=20 >marking as the token bucket level goes back and forth across the step,=20 >because it will stay increasingly on the marking side the closer the=20 >average rate gets to the 'PCN lower rate' ("admission stop threshold" in=20 >your terms). [Joe] Even for voice traffic without silence suppression the token bucket can be made small and with the arrivals and natural termination will generate traffic variability.=20 >Agreement: It would be sufficient to standardise step marking (on-off e.g.=20 >3sm) as a minimum requirement for admission control. [Joe] Yes. We should only standardize the marking behavior and not a specific algorithm. >Agreement: This would leave one case of pure and stable CBR traffic that=20 >would not give a smooth rise in marking, but would toggle from 0 to 100% on=20 >the addition of the last flow. [Joe] In theory yes, in practices there is transition point where some packets are marked before 100% marking. However the transition point may be fast. In a multi service network were other (non PCN) traffic will introduce variability to the true CBR traffic. This is why we always have de-jitter buffers even for CBR codecs >Disagreement?: Stable CBR-like traffic won't necessarily be unusual in=20 >certain networks. It is certainly possible (tho unlikely) that a particular=20 >link may be fed by a large proportion of CBR codecs without silence=20 >suppression (e.g. where a network itself deploys a load of cheap codecs for=20 >PSTN-emulation). But much more likely are links where the total traffic is=20 >CBR-like even tho each flow is variable, due to statistical aggregation of=20 >very many variable flows. [Joe] CBR sourced flows will be common and so will large PSTN gateways in networks for a long time. I think the issue that your are raising is that these PSTN gateways mostly generate CBR voice traffic and there will be very little other traffic on the link to introduce traffic variability, accept for flows starting and ending? I agree, it's a valid scenario. >Disagreement?: The algo shouldn't have to rely on the traffic being=20 >variable to behave in the way we want. Ramp marking (as in the body of=20 >draft-briscoe-twvwg-cl-phb-03.txt) creates a gradual increase in marking=20 >even for CBR-like traffic. Then the marking algo gives a more gradual=20 >transition WHATEVER the traffic (unless it's locally shaped to be absolutly=20 >pure CBR). [Joe] My view is that the defined marking behavior (algorithm) should not rely on traffic being CBR or VBR-like. It needs to work equally well for both types.=20 I think the area where we may disagree on is does gradual transition or any transition of marking versus on-off address the flash crowd (mass calling event) as can be expected in telephony. Currently, I do not believe that the gradual transition (RAMP) marking approach or on/off as in 3sm address this because the flow is admitted by the network at the control plain, telephone rings and not until it is answered before any media packets are sent through the network. The time between when the ingress node (or the network) makes the decision to admit and time when the newly admitted flows will send packets can be several seconds.=20 My view is that early warning through transition marking will not provide sufficient protection against over-admission. Admission control is distributed and the ingress nodes do not know how many flows have been admitted but are not sending any packets just yet. So I'm not convinced that it adds real value for controlling over-admission. >The following ASCII art illustrates this. Even for step marking, the curve=20 >of marking probability against mean arrival rate is smoother for traffic=20 >with more variance, but if the traffic doesn't have enough variance, you=20 >can push the curve smoother by using a ramp algo. The flatter the ramp, the=20 >smoother the curve. ^_ |p, mean marking probability | | | | !| | !| | !| | ;| | ,;| | ,;| | |;| | |;| | variance ;;| | of total PCN / || | traffic on link, | || | v , || | OR +--- . || | slope of ramp |\ , || | | \ / || | _/ || | __/ \ || | ,--^^ \ || mean | __,,,,----^^^^ \_/ | arrival | /| ______._,_=3D_=3D_=3D_____,,,,,,,,,,......----^\ | = rate, +---/ | /----------------------------------------------+------------->_ |/ X x PCN lower rate >Agreement: A gradual increase in marking will sometimes lead to a flow=20 >being denied that could have been admitted. But that's unavoidable anyway=20 >if some flows are variable - we even had that trade-off to an extent even=20 >in Intserv-style admission control. However, ramp marking makes the range=20 >of rates over which you get under-admission wider than it was with just >natural traffic variability. [Joe] Agree. For admission control, I believe that we need to develop methods that minimize this effect. From simulation results that I have done to date leads me to believe that it's better to allow faster response, as it improves utilization meaning more flows can be supported especially when we have high aggregation as flows are terminating and new flows being added at rate of several flows per second. >Agreement?: >* For a link with a large number of flows with high statistical=20 >multiplexing, the benefit of artifically creating a gradual increase using=20 >ramp marking outweighs the cost. You get early warning of a flash crowd but=20 >miss the odd flow unnecessarily (when the system hits its admission limit,=20 >which should be rare anyway). [Joe] On large links with many small flows flash crowd is of less concern. However, we should not assume that large links will always have many small flows. Large link could have few large flows. The other issue that I would like to raise is that we have not discussed a potential denial of service attack on the network. New flows are setup and admitted but no media packets are sent for an extended period of time and then all at once media packets are sent. I believe we need to protect against this.=20 Not sure if you need gradual transition (RAMP) marking or will just simple transitional marking as in 3sm do? See later in email link to simulation results. Yes RAMP marking provides early warning that you're approaching admissible threshold, however I do not think that early warning is sufficient of a mechanism to provide protection against over-admission or admission control DoS attacks.=20 >* For a link only carrying a small number of flows within its PCN lower >rate, the cost of ramp marking in under-admissions outweighs its benefit.=20 >Note, this needen't be a low capacity link - it might be a high capacity=20 >link with a few large flows. >* For a link in between - with high number of flows but not high enough >stat mux to smooth to CBR-like, the traffic variance may give enough of a=20 >gradual increase to handle flash crowds without needing to add more=20 >smoothness using ramp marking (ie cost of ramp under-admissions outweights=20 >benefit of more smoothness when you've got enough anyway). >Agreement?: Note: links with a few flows fall outside the PCN charter, but=20 >that shouldn't stop us prefering solutions that handle such links, all=20 >other issues being equal. [Joe] Agree. >Agreement?: If I'm right in all this, I believe we should allow and=20 >encourage (but not mandate) vendors to implement ramp marking on machines=20 >targeted for PCN interior nodes (ie SHOULD implement ramp). Then ramp is=20 >available if it's needed, but can be turned off if it isn't. [Joe] I'm not against RAMP marking. We need to verify that it really adds value ie, it does provide sufficient protection against over-admission due to flash crowd, DoS attacks, etc. The selection of algorithm should be left up to the equipment vendor.=20 Bob, have you done any simulations to quantify the performance? If not, I will see if we can run some simulations with RAMP and compare it to on/off in 3sm.=20 >Agreement?: But we should advise that step marking is the best solution (ie=20 >SHOULD deploy step) if there's enough variability in the traffic anyway (or=20 >only a few flows are expected on the link). [Joe] I think that we should state the "step marking" (need to write the behavior for step marking) is a minimum requirement with gradual transitional (ramp) marking optional. We need simulation results to quantify benefits of "ramp marking" for admission control.=20 >Agreement?: But ramp marking is hard to do on much current hardware. So >it's useful that it's not a MUST. However, if an operator needs ramp=20 >marking (a risk of flash crowds and links with smoothly aggregated traffic)=20 >we should caution that inability to deploy ramp is NOT a good reason for=20 >not deploying it. [Joe] See above. Agree. >Disagreement: You imply that, with low packet probing rates, step (on-off)=20 >marking can determine whether to admit a new flow faster than ramp. Given=20 >both have a range over which they mark packets probabilistically, I don't=20 >believe this is the way to state the distinction between them. Certainly=20 >ramp marks packets probabilistically over a wider range of loads. But, for=20 >either algo, the ingress boundary node doesn't know whether an interior >node is within this range or not when it probes. So it has to send as many=20 >probes in both cases in case an interior node might be in its probabilistic=20 >range of marking. [Joe] I see your point and agree. I was thinking that there are only two conditions, admit or stop admit that is sent to ingress node. During the transition or early warning if a probe has one or more packets marked the decision is to not admit the new flow. Also the density of marking to trigger stop admission can be made service class dependent.=20 My view of probing is that the ingress nodes sends small packets every 20 or 100ms until the admitted flow starts sending media packets. For ingress-egress paths that have no packets flowing. There are two phases to admission control. First probing is used to verify during the application signalling phase that a new flow can be admitted. If during the application signalling phase probe packets are marketed, admission of new flow can be blocked by information passed to the control plain. However if no marking is detected application signalling is informed to proceed. Probing continues until the admitted flow starts sending packets. If during the second phase probe packets become 100% marked, the flow is blocked at the network layer and a message is sent to the application control layer indicating flow admission was blocked. This condition should happen very infrequently but it provides protection against flash crowds and attacks on admission control system.=20 >Disagreement?: In fact, ramp actually gives a much quicker probing time >than step: >* Step: If the queue is above the step 5% of the time due to traffic=20 >variation, over a *long* time period it will indeed mark 5% of probes. BUT=20 >over a *short* period it will mark all the probes the same (queue length=20 >correlation over time). >* Ramp: If the queue is varying around the point on the ramp that is doing=20 >5% marking, it will mark each probe with ~5% probability, independently of=20 >how it marked previous ones. >So, with either algo you have to send the same number of probes, but with=20 >ramp you can send them back-to-back, while with step you get hardly any >more information unless you send them spaced over a long time period (ie a=20 >few seconds). Hence ramp should be much quicker to probe. [Joe] OK I agree that probing can be made to work with ramp. To quantify performance differences, we would have to do simulations.=20 Bob, my view on the differences between the admission stop marking (on/off or step) in 3sm draft and RAMP. The 3sm marking approach for admission control uses a very simple token bucket algorithm and marking transition form 0 to 100% is based on rate variation over the measured admissible threshold. The marking density is directly depended on rate changes. The RAMP marking approach has an added function where at the admission threshold there is an algorithm that marks packet based on probability.=20 Do you agree as these are the major differences? Do you have an RAMP algorithm that you can send us so that we can simulate to see the difference in performance? >Pls say whether you agree or disagree with each point, so we can home in on=20 >exactly why we keep both going round this loop. [Joe] Below is a link to simulation results of admission control using 3sm marking. http://standards.nortel.com/pcn/Admit_Cont_CBR.pdf=20 This simulation is of CBR only traffic with the admissible threshold set to 16 Mbps or 200 CBR flows. This simulation shows rate variation that CBR voice traffic generates and behavior of 3sm marking for admission control. - AS-clear timer =3D 0.1 sec. means blocking of new flows last for 100ms after "block admission signal" was received. - Orange trace is the admitted traffic rate on the link. - Pink trace shows number of flows admitted and active.=20 - Red trace shows cumulative number of flows blocked. To understand the results here is additional information. Simulation setup: - The flow arrival is 7.5 flows/sec. - Mean holding time of flow is 60 seconds. - Offered load on average is 36 Mbps or 450 flows. - Flow arrival uses Poisson distribution. - No probing is used in these simulations. - Media delay limit =3D 0 sec. means start of sending packets is not delayed. - Media delay limit =3D 10 sec. means start of sending packets is = delayed randomly between 0 and 10 seconds. -All flows belong to one aggregate. Admission Control: In simulations, when egress detects a packet marked, it sends "block admission signal" to ingress. The block admission signal blocks admission of new flows for a period of time, programmable 100ms or 1 sec. after which time if no block admission signal were received new flows are admitted. The delay from marking of packet and sending of block admission signal is programmable and we simulate with 2 and 200ms as the RTT. Also here is a link to more simulation results with different scenarios. Admission control results starting on page 13.=20 http://standards.nortel.com/pcn/3sM-Simulation-1.pdf Regards, Joe. >Cheers >Bob email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk]=20 Sent: August 30, 2007 3:41 PM To: Babiarz, Jozef (CAR:0S03) Cc: Geib, Ruediger; l.andrew@ieee.org; pcn@ietf.org; eeschan@cityu.edu.hk Subject: RE: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking Joe, At 15:17 27/08/2007, Jozef Babiarz wrote: >I think there is a bit more to this issue than just different levels of >pre-congestion. > >For admission control the challenge for PCN is to find out how much new >traffic can be added on to a specific link or path and not to determine >the level of congestion. I agree that the AC challenge for PCN is to find how much new traffic can=20 be added, but surely not just for a specific link. The full challenge is for any single ingress edge node to know how much it can add. But it has to=20 accept the fact that it doesn't know how many other ingress nodes are=20 competing to add traffic to the same link. (See previous response to=20 Ruediger - although I don't think you're asking for the same thing, but it=20 sounds like you are). more... >The purpose of admission control is to prevent >congestion of the service class on link that forwards PCN traffic. PCN >is deployed in Diffserv networks, with the understanding that PCN >traffic is forwarded using priority scheduling. > >Voice with silence suppression plus calls naturally ending as well new >calls being added generates highly variable traffic. The marking by >interior node to indicate that PCN admission threshold is exceeded or >not, needs to be quick to reflect true traffic levels. Agreed >Analysis of the >marking density and control of response to the marking can be handled at >the edges. The proposed marking scheme in draft-babiarz-pcn-3sm-00.txt >for admission control, produces the following behavior, when PCN traffic >is fare below the admission stop threshold, no packets are marked. As >the variable traffic increases and some packets exceed the token bucket >rate (admission stop threshold) they are marked. If additional new >traffic is allowed to be admitted on to the link, more packets will >exceed the token bucket rate therefore marking density increases >possibly until all packets are marked. However, for pure and stable CBR >traffic you will get a step marking (on-off) where the transition from >no marking to all packets marked being quick. I'm not sure which you you are saying is more desirable: - the outcome with variable traffic (a gradual transition from 0-100% marking) - or the outcome for CBR traffic (a step change)? I think you're saying that a gradual transition is desirable, but that even=20 with on-off marking you get a gradual transition as long as there's=20 variation in the traffic, which there usually is. (See later for my view) > >My view is that PCN should work equally well regardless of the number of >flows in an ingress-egress aggregate from one to many flows, Agreed. >as well >should work without the need for ingress-egress aggregation concept. If you mean by this, that a new flow shouldn't need to use information from=20 existing flows in an aggregate, I agree. That's a performance enhancement,=20 not an essential function. >The >so called on-off marking approach is not that dependent on the rate of >ingress-egress traffic meaning that edge node will be able to determine >if new flow should be admitted based on low bit rate (probe or single >voice flow) or high bit rate flow(s) passing through the pre-congested >link. I think I am agreeing with you in everything you say, except on one point=20 (if I understand you right). So I'll restate everything I believe, tagged=20 with whether we're agreeing or disagreeing, to try to reach closure, as=20 we've been going round these issues for some time (pre-PCN w-g). Agreement?: A gradual transition in interior admission marking is desirable=20 as the boundary nodes can always turn this into a threshold or use it in innovative ways, to be determined. Agreement?: Whether the transition is gradual is a serious issue, because a=20 distributed measurement-based admission control (DMBAC) system like PCN=20 admits traffic one round trip before it knows whether it should have done.=20 So in a flash crowd (mass calling event) admissions can overshoot if the interior admission marking only flips from 0-100% at the last instant.=20 Whereas if the interior nodes give a gradual increase, the boundary nodes=20 can use the early warning contingency to be more conservative when necessary. Agreement: We hope and expect that traffic levels will be variable because=20 of silence suppression etc. Then step (on-off) marking on interior nodes will be sufficient. It will still lead to a gradual increase in admission=20 marking as the token bucket level goes back and forth across the step,=20 because it will stay increasingly on the marking side the closer the=20 average rate gets to the 'PCN lower rate' ("admission stop threshold" in your terms). Agreement: It would be sufficient to standardise step marking (on-off e.g.=20 3sm) as a minimum requirement for admission control. Agreement: This would leave one case of pure and stable CBR traffic that would not give a smooth rise in marking, but would toggle from 0 to 100% on=20 the addition of the last flow. Disagreement?: Stable CBR-like traffic won't necessarily be unusual in=20 certain networks. It is certainly possible (tho unlikely) that a particular=20 link may be fed by a large proportion of CBR codecs without silence=20 suppression (e.g. where a network itself deploys a load of cheap codecs for=20 PSTN-emulation). But much more likely are links where the total traffic is=20 CBR-like even tho each flow is variable, due to statistical aggregation of=20 very many variable flows. Disagreement?: The algo shouldn't have to rely on the traffic being=20 variable to behave in the way we want. Ramp marking (as in the body of=20 draft-briscoe-twvwg-cl-phb-03.txt) creates a gradual increase in marking even for CBR-like traffic. Then the marking algo gives a more gradual=20 transition WHATEVER the traffic (unless it's locally shaped to be absolutly=20 pure CBR). The following ASCII art illustrates this. Even for step marking, the curve=20 of marking probability against mean arrival rate is smoother for traffic with more variance, but if the traffic doesn't have enough variance, you can push the curve smoother by using a ramp algo. The flatter the ramp, the=20 smoother the curve. ^_ |p, mean marking probability | | | | !| | !| | !| | ;| | ,;| | ,;| | |;| | |;| | variance ;;| | of total PCN / || | traffic on link, | || | v , || | OR +--- . || | slope of ramp |\ , || | | \ / || | _/ || | __/ \ || | ,--^^ \ || mean | __,,,,----^^^^ \_/ | arrival | /| ______._,_=3D_=3D_=3D_____,,,,,,,,,,......----^\ | = rate, +---/ | /----------------------------------------------+------------->_ |/ X x PCN lower rate Agreement: A gradual increase in marking will sometimes lead to a flow=20 being denied that could have been admitted. But that's unavoidable anyway=20 if some flows are variable - we even had that trade-off to an extent even=20 in Intserv-style admission control. However, ramp marking makes the range=20 of rates over which you get under-admission wider than it was with just=20 natural traffic variability. Agreement?: * For a link with a large number of flows with high statistical=20 multiplexing, the benefit of artifically creating a gradual increase using=20 ramp marking outweighs the cost. You get early warning of a flash crowd but=20 miss the odd flow unnecessarily (when the system hits its admission limit,=20 which should be rare anyway). * For a link only carrying a small number of flows within its PCN lower=20 rate, the cost of ramp marking in under-admissions outweighs its benefit.=20 Note, this needen't be a low capacity link - it might be a high capacity link with a few large flows. * For a link in between - with high number of flows but not high enough=20 stat mux to smooth to CBR-like, the traffic variance may give enough of a=20 gradual increase to handle flash crowds without needing to add more=20 smoothness using ramp marking (ie cost of ramp under-admissions outweights=20 benefit of more smoothness when you've got enough anyway). Agreement?: Note: links with a few flows fall outside the PCN charter, but=20 that shouldn't stop us prefering solutions that handle such links, all=20 other issues being equal. Agreement?: If I'm right in all this, I believe we should allow and=20 encourage (but not mandate) vendors to implement ramp marking on machines=20 targeted for PCN interior nodes (ie SHOULD implement ramp). Then ramp is available if it's needed, but can be turned off if it isn't. Agreement?: But we should advise that step marking is the best solution (ie=20 SHOULD deploy step) if there's enough variability in the traffic anyway (or=20 only a few flows are expected on the link). Agreement?: But ramp marking is hard to do on much current hardware. So=20 it's useful that it's not a MUST. However, if an operator needs ramp=20 marking (a risk of flash crowds and links with smoothly aggregated traffic)=20 we should caution that inability to deploy ramp is NOT a good reason for not deploying it. Disagreement: You imply that, with low packet probing rates, step (on-off)=20 marking can determine whether to admit a new flow faster than ramp. Given=20 both have a range over which they mark packets probabilistically, I don't=20 believe this is the way to state the distinction between them. Certainly ramp marks packets probabilistically over a wider range of loads. But, for=20 either algo, the ingress boundary node doesn't know whether an interior=20 node is within this range or not when it probes. So it has to send as many=20 probes in both cases in case an interior node might be in its probabilistic=20 range of marking. Disagreement?: In fact, ramp actually gives a much quicker probing time=20 than step: * Step: If the queue is above the step 5% of the time due to traffic=20 variation, over a *long* time period it will indeed mark 5% of probes. BUT=20 over a *short* period it will mark all the probes the same (queue length correlation over time). * Ramp: If the queue is varying around the point on the ramp that is doing=20 5% marking, it will mark each probe with ~5% probability, independently of=20 how it marked previous ones. So, with either algo you have to send the same number of probes, but with=20 ramp you can send them back-to-back, while with step you get hardly any=20 more information unless you send them spaced over a long time period (ie a=20 few seconds). Hence ramp should be much quicker to probe. Pls say whether you agree or disagree with each point, so we can home in on=20 exactly why we keep both going round this loop. Cheers Bob >Regards, Joe >email:babiarz@nortel.com >Telephone:613-763-6098 >-----Original Message----- >From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] >Sent: August 24, 2007 3:09 AM >To: l.andrew@ieee.org; rbriscoe@jungle.bt.co.uk >Cc: pcn@ietf.org; eeschan@cityu.edu.hk >Subject: RE: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking > >Lachlan, Bob, > >you both seem to agree that ramp marking is the best solution. >Picking up Lachlan's pretty sound arguments on different thresholds >for different types of incoming calls - what you describe is >estimating the available (not consumed) PCN bandwidth rather than >just a "pre congestion notification", I think. >If there's a simple solution to realize this idea, PCN should >investigate it. This could be helpful if there's a new call to be >admitted and no PCN flow exists between two gateways. The question >then would be, whether a certain bandwidth is available, rather >than "any congestion visible". ToDo: * an edge ingress node needs to use its own knowledge of its own rate=20 contribution to the problem (x). 0 <=3D p <=3D 1 Bob >Regards, > >Ruediger > > >|Lachlan wrote: >|I believe that the marking scheme should carry as much information as >|possible about the network state, and that thresholding should be done >|as late as possible (at the decision-making end-points). The more >|information the decision-making entity has, better the decisions it >|can make. >| >|If things like thresholding are done where the admission decisions are >|made, there is also a smoother upgrade path for changes in the >|admission rules. For example, an operator may want to apply different >|thresholds applied to different types of incoming calls. If routers >|provide a single threshold, this can't be implemented at a later >|stage. Similarly, an operator may want to admit a certain percentage >|of traffic dependent on the congestion level, rather than admitting >|all or none. > >|Bob wrote: >|[BB] The problem we were trying to solve with ramp marking was the >|reverse: >|we were looking for a marking algo that produced a smooth increase in >|marking over a wider range of loads. The edge nodes can always turn a >|smooth rise into a toggle at a specific threshold marking level. > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn ________________________________________________________________________ ____ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196=20 ------_=_NextPart_001_01C7F681.AFDB2906 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [PCN] draft-eardley-pcn-architecture-00.txt on-off = marking

Bob,

Sorry for the delay in resending to your = questions.

First, I agree with your comments in email to = Ruediger, dated Wed 29/08/2007 and would like to emphasize that defining = marking that is dimensionless, will allow PCN system to scale. (ie = marking meaning pre-congestion state or condition rather than certain = rate).

On your point that marking should rise gradually = then get steeper as the reference rate is approached and rapidly = saturate at some point (the reference rate). We need to discuss further. = It’s not that I’m against this idea, I just do not see how = practically we can take advantage of it to control over admission under = flash crowd conditions. (more on this topic later in the = email)

>Joe,

>At 15:17 27/08/2007, Jozef Babiarz = wrote:

>>I think there is a bit more to this issue than = just different levels of

>>pre-congestion.

>>

>>For admission control the challenge for PCN is = to find out how much new

>>traffic can be added on to a specific link or = path and not to determine

>>the level of congestion.

>I agree that the AC challenge for PCN is to find = how much new traffic can

>be added, but surely not just for a specific link. = The full challenge is

>for any single ingress edge node to know how much = it can add. But it has to

>accept the fact that it doesn't know how many other = ingress nodes are

>competing to add traffic to the same link. (See = previous response to

>Ruediger - although I don't think you're asking for = the same thing, but it

>sounds like you are).

>more...

>>The purpose of admission control is to = prevent

>>congestion of the service class on link that = forwards PCN traffic. PCN

>>is deployed in Diffserv networks, with the = understanding that PCN

>>traffic is forwarded using priority = scheduling.

>>

>>Voice with silence suppression plus calls = naturally ending as well new

>>calls being added generates highly variable = traffic. The marking by

>>interior node to indicate that PCN admission = threshold is exceeded or

>>not, needs to be quick to reflect true traffic = levels.

>Agreed

>>Analysis of the

>>marking density and control of response to the = marking can be handled at

>>the edges. The proposed marking scheme in = draft-babiarz-pcn-3sm-00.txt

>>for admission control, produces the following = behavior, when PCN traffic

>>is fare below the admission stop threshold, no = packets are marked. As

>>the variable traffic increases and some packets = exceed the token bucket

>>rate (admission stop threshold) they are = marked. If additional new

>>traffic is allowed to be admitted on to the = link, more packets will

>>exceed the token bucket rate therefore marking = density increases

>>possibly until all packets are marked. However, = for pure and stable CBR

>>traffic you will get a step marking (on-off) = where the transition from

>>no marking to all packets marked being = quick.

>I'm not sure which you you are saying is more = desirable:

[Joe] My thinking is that the ingress node, the one that is = controlling admission of new flows needs to know if it can or can not = admit new flow, simply yes or no. My assumption is that the ingress node = only has limited view of traffic rate and characteristics of the new = flow to be admitted, like what would be specified for a VoIP or video conferencing = service. =

I think your suggesting that we provide the ingress = node an early warning that traffic is approaching the configured = admissible threshold when an egress node sees some marking. The ingress = node uses some policy or algorithm to control the admission of new flows = when the path is close to admissible threshold. Providing three levels = (stop-light methodology) green admit, orange admit with caution, and red = stop?

>- the outcome with variable traffic (a gradual = transition from 0-100% >marking)

>- or the outcome for CBR traffic (a step = change)?

>I think you're saying that a gradual transition is = desirable, but that even

>with on-off marking you get a gradual transition as = long as there's

>variation in the traffic, which there usually = is.

>(See later for my view)

[Joe] Yes, with the threshold marking define in = 3sm draft you get a transition form no marking to 100% marking. The = transition depends on variation of the traffic and settings of the token = bucket, size and marking threshold.

>

>>My view is that PCN should work equally well = regardless of the number of

>>flows in an ingress-egress aggregate from one = to many flows,

>Agreed.

>>as well

>>should work without the need for ingress-egress = aggregation concept.

>If you mean by this, that a new flow shouldn't need = to use information from

>existing flows in an aggregate, I agree. That's a = performance enhancement,

>not an essential function.

[Joe] Yes, plus for = first flow of aggregate or if the deployment does not use ingress-egress = aggregation concepts through tunneling or other = methods.

>>The

>>so called on-off marking approach is not that = dependent on the rate of

>>ingress-egress traffic meaning that edge node = will be able to determine

>>if new flow should be admitted based on low bit = rate (probe or single

>>voice flow) or high bit rate flow(s) passing = through the pre-congested

>>link.

>I think I am agreeing with you in everything you = say, except on one point

>(if I understand you right). So I'll restate = everything I believe, tagged

>with whether we're agreeing or disagreeing, to try = to reach closure, as

>we've been going round these issues for some time = (pre-PCN w-g).

>Agreement?: A gradual transition in interior = admission marking is desirable

>as the boundary nodes can always turn this into a = threshold or use it in

>innovative ways, to be = determined.

[Joe] Generally in agreement. Not sure if = gradual transition is that important. Concern that I have is that links with = different rates and different traffic types will affect = the behavior = of gradual transition = from = 0-100%. A = link that has its admissible threshold configured at 5 Mbps and another = at 400 Mbps will produce different range of gradual transition. How is = the egress node to determine how close the traffic is to admissible = threshold?

>Agreement?: Whether the transition is gradual is a = serious issue, because a

>distributed measurement-based admission control = (DMBAC) system like PCN

>admits traffic one round trip before it knows = whether it should have done.

>So in a flash crowd (mass calling event) admissions = can overshoot if the

>interior admission marking only flips from 0-100% = at the last instant.

>Whereas if the interior nodes give a gradual = increase, the boundary nodes

>can use the early warning contingency to be more = conservative when >necessary.

[Joe] Yes agree. However we will need to = quantify this with simulations. Need to point out that for some traffic = there is the issue of = the start of = media = packets is = delayed = (until person = answers the phone) after the admission decisions was made.

>Agreement: We hope and expect that traffic levels = will be variable because

>of silence suppression etc. Then step (on-off) = marking on interior nodes

>will be sufficient. It will still lead to a gradual = increase in admission

>marking as the token bucket level goes back and = forth across the step,

>because it will stay increasingly on the marking = side the closer the

>average rate gets to the 'PCN lower rate' = ("admission stop threshold" in

>your terms).

[Joe] Even for voice traffic without = silence suppression the token bucket can be made small and with the = arrivals and natural termination will generate traffic variability. =

>Agreement: It would be sufficient to standardise = step marking (on-off e.g.

>3sm) as a minimum requirement for admission = control.

[Joe] Yes. We should only standardize the = marking behavior and not a specific algorithm.

>Agreement: This would leave one case of pure and = stable CBR traffic that

>would not give a smooth rise in marking, but would = toggle from 0 to 100% on

>the addition of the last flow.

[Joe] In theory yes, in = practices there is transition = point where some packets are marked before 100% marking. However the = transition point may be fast. In a multi service = network were other (non PCN) traffic will introduce variability to the = true CBR traffic. This is why we always have de-jitter buffers even for = CBR codecs

>Disagreement?: Stable CBR-like traffic won't = necessarily be unusual in

>certain networks. It is certainly possible (tho = unlikely) that a particular

>link may be fed by a large proportion of CBR codecs = without silence

>suppression (e.g. where a network itself deploys a = load of cheap codecs for

>PSTN-emulation). But much more likely are links = where the total traffic is

>CBR-like even tho each flow is variable, due to = statistical aggregation of

>very many variable flows.

[Joe] CBR sourced flows will be common and = so will large PSTN gateways in networks for a long time. I think the = issue that your are raising is that these PSTN gateways mostly generate = CBR voice traffic and = there will be = very = little other traffic on = the link to introduce traffic variability, accept for flows starting and = ending? I = agree, = it’s = a valid scenario.

>Disagreement?: The algo shouldn't have to rely on = the traffic being

>variable to behave in the way we want. Ramp marking = (as in the body of

>draft-briscoe-twvwg-cl-phb-03.txt) creates a = gradual increase in marking

>even for CBR-like traffic. Then the marking algo = gives a more gradual

>transition WHATEVER the traffic (unless it's = locally shaped to be absolutly

>pure CBR).

[Joe] My view is that the defined marking = behavior (algorithm) should not rely on traffic being CBR or VBR-like. = It needs to work equally well for both types.

I think the area where = we may disagree on is does gradual transition or any transition of = marking versus on-off address the flash crowd (mass calling event) as = can be expected in telephony.

Currently, I do not believe that the gradual = transition (RAMP) marking approach or on/off as in 3sm address this = because the flow is admitted by the network at the control plain, = telephone rings and not until it is answered before any media packets = are sent through the network. The time between when the ingress node (or = the network) makes the decision to admit and time when the newly = admitted flows will send packets can be several seconds. =

My view is that early = warning through transition marking will not provide sufficient = protection against over-admission. Admission control is distributed and = the ingress nodes do not know how many flows have been admitted but are = not sending any packets just yet. So I’m not convinced that it = adds real value for controlling over-admission.

>The following ASCII art illustrates this. Even for = step marking, the curve

>of marking probability against mean arrival rate is = smoother for traffic

>with more variance, but if the traffic doesn't have = enough variance, you

>can push the curve smoother by using a ramp algo. = The flatter the ramp, the

>smoother the curve.

^_

|p, mean marking = probability          &n= bsp;           &nb= sp;    |

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

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

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

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

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

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

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

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

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

|           &= nbsp;           &n= bsp;            = variance        ;;|

|           &= nbsp;           &n= bsp;        of total = PCN       / ||

|           &= nbsp;           &n= bsp;     traffic on = link,      | ||

|           &= nbsp;           &n= bsp;           &nb= sp;       = v       , ||

|           &= nbsp;           &n= bsp;     = OR            = ; +---  .  ||

|           &= nbsp;           &n= bsp;     slope of ramp  |\    = ,  ||

|           &= nbsp;           &n= bsp;           &nb= sp;        | \  /   = ||

|           &= nbsp;           &n= bsp;           &nb= sp;           = _/    ||

|           &= nbsp;           &n= bsp;           &nb= sp;        __/ \    = ||

|           &= nbsp;           &n= bsp;           &nb= sp;   ,--^^     \   = ||           = mean

|           &= nbsp;           &n= bsp; = __,,,,----^^^^          = ; \_/ |        = arrival

|    /|    = ______._,_=3D_=3D_=3D_____,,,,,,,,,,......----^\  = |           = rate,

+---/ | = /----------------------------------------------+------------->_=

      = |/            = ;            =             &= nbsp;          = X            =   x

           &n= bsp;           &nb= sp;           &nbs= p;          PCN lower = rate


>Agreement: A gradual increase in marking will = sometimes lead to a flow

>being denied that could have been admitted. But = that's unavoidable anyway

>if some flows are variable - we even had that = trade-off to an extent even

>in Intserv-style admission control. However, ramp = marking makes the range

>of rates over which you get under-admission wider = than it was with just

>natural traffic variability.

[Joe] Agree. For admission control, I believe that we = need to develop methods that minimize this effect. From simulation = results that I have done to date leads me to believe that it’s better to = allow faster response, as it improves utilization meaning more flows can = be supported especially when we have high aggregation as flows are = terminating and new flows being added at rate of several flows per second.

>Agreement?:

>* For a link with a large number of flows with high = statistical

>multiplexing, the benefit of artifically creating a = gradual increase using

>ramp marking outweighs the cost. You get early = warning of a flash crowd but

>miss the odd flow unnecessarily (when the system = hits its admission limit,

>which should be rare anyway).

[Joe] On large links with many small flows = flash crowd is of less concern. However, we should not assume that large = links will always have many small flows. Large link could have few large = flows. The other issue that I would like to raise is that we have not discussed a = potential denial of service attack on the network. New flows are setup = and admitted but no media packets are sent for an = extended = period = of time and then all at = once media packets are sent. I believe we need to protect against this.

Not sure if you need = gradual transition (RAMP) marking or will just simple transitional = marking as in 3sm do? See later in email link to simulation results. Yes = RAMP marking provides early warning that you’re approaching = admissible threshold, however I do not think that early warning is = sufficient of a mechanism to provide protection against over-admission = or admission control DoS attacks.

>* For a link only carrying a small number of flows = within its PCN lower

>rate, the cost of ramp marking in under-admissions = outweighs its benefit.

>Note, this needen't be a low capacity link - it = might be a high capacity

>link with a few large flows.

>* For a link in between - with high number of flows = but not high enough

>stat mux to smooth to CBR-like, the traffic = variance may give enough of a

>gradual increase to handle flash crowds without = needing to add more

>smoothness using ramp marking (ie cost of ramp = under-admissions outweights

>benefit of more smoothness when you've got enough = anyway).

>Agreement?: Note: links with a few flows fall = outside the PCN charter, but

>that shouldn't stop us prefering solutions that = handle such links, all

>other issues being equal.

[Joe] Agree.

>Agreement?: If I'm right in all this, I believe we = should allow and

>encourage (but not mandate) vendors to implement = ramp marking on machines

>targeted for PCN interior nodes (ie SHOULD = implement ramp). Then ramp is

>available if it's needed, but can be turned off if = it isn't.

[Joe] I’m not = against = RAMP = marking. We = need to verify that it really adds value ie, it does provide sufficient = protection against over-admission due to flash crowd, DoS attacks, etc. = The selection of algorithm should be left up to the equipment = vendor. =

Bob, have you done any = simulations to quantify the performance? If not, I will see if we can = run some simulations = with RAMP and compare it to on/off in 3sm.

>Agreement?: But we should advise that step marking = is the best solution (ie

>SHOULD deploy step) if there's enough variability = in the traffic anyway (or

>only a few flows are expected on the = link).

[Joe] I think that we should state the = “step = marking” (need to write the behavior for step = marking) = is a minimum requirement with gradual transitional = (ramp) marking optional.  = We need simulation = results to quantify benefits of “ramp marking” for admission = control. =

>Agreement?: But ramp marking is hard to do on much = current hardware. So

>it's useful that it's not a MUST. However, if an = operator needs ramp

>marking (a risk of flash crowds and links with = smoothly aggregated traffic)

>we should caution that inability to deploy ramp is = NOT a good reason for

>not deploying it.

[Joe] See above. = Agree.

>Disagreement: You imply that, with low packet = probing rates, step (on-off)

>marking can determine whether to admit a new flow = faster than ramp. Given

>both have a range over which they mark packets = probabilistically, I don't

>believe this is the way to state the distinction = between them. Certainly

>ramp marks packets probabilistically over a wider = range of loads. But, for

>either algo, the ingress boundary node doesn't know = whether an interior

>node is within this range or not when it probes. So = it has to send as many

>probes in both cases in case an interior node might = be in its probabilistic

>range of marking.

[Joe] I see your point and = agree. = I was thinking = that there are = only two conditions, admit or stop admit that is sent to ingress = node. During the = transition or = early warning if a = probe has one or more packets marked the decision is to not admit the = new flow. = Also = the density of = marking = to trigger stop = admission = can be made = service class dependent.

My view of probing is = that the ingress nodes sends small packets every 20 or 100ms until the = admitted flow starts = sending = media packets. For ingress-egress paths that have no packets flowing. = There are two phases to admission control. First = probing = is used = to verify during the = application signalling phase that a new flow can be = admitted. = If during = the application = signalling = phase probe packets are = marketed, = admission of new flow can be = blocked = by = information passed to the control plain. However if no marking is detected = application signalling is informed to proceed. Probing continues until the admitted flow = starts sending packets. If during the second phase probe = packets = become 100% marked, the flow is blocked at the network layer = and a message is sent to the application control = layer indicating flow = admission was = blocked. = This condition should happen very infrequently but it provides = protection against flash crowds and attacks on admission control = system. =

>Disagreement?: In fact, ramp actually gives a much = quicker probing time

>than step:

>* Step: If the queue is above the step 5% of the = time due to traffic

>variation, over a *long* time period it will indeed = mark 5% of probes. BUT

>over a *short* period it will mark all the probes = the same (queue length

>correlation over time).

>* Ramp: If the queue is varying around the point on = the ramp that is doing

>5% marking, it will mark each probe with ~5% = probability, independently of

>how it marked previous ones.

>So, with either algo you have to send the same = number of probes, but with

>ramp you can send them back-to-back, while with = step you get hardly any

>more information unless you send them spaced over a = long time period (ie a

>few seconds). Hence ramp should be much quicker to = probe.

[Joe] OK I agree that probing can be made to work with ramp. To = quantify performance differences, we would have to do = simulations. =

Bob, my view on the = differences between the admission stop marking (on/off or step) in 3sm = draft and RAMP.

The 3sm marking approach for admission control uses = a very simple token bucket algorithm and marking transition form 0 to = 100% is based on rate variation over the measured admissible threshold. = The marking density is directly depended on rate = changes.

The RAMP marking approach has an added function = where at the admission threshold there is an algorithm that marks packet = based on = probability. =

Do you agree as these are the major = differences?

Do you have an RAMP algorithm that you can = send = us so = that we can simulate to see the difference in = performance?

>Pls say whether you agree or disagree with each = point, so we can home in on

>exactly why we keep both going round this = loop.

[Joe] Below is a link to simulation = results of admission control using 3sm marking. = http://standards.nortel.com/pcn/Admit_Cont_CBR.pdf= =

This simulation is of CBR only traffic with the = admissible threshold set to 16 = Mbps or 200 CBR flows. = This simulation shows rate variation that CBR voice traffic generates = and behavior of 3sm marking for admission control.

- AS-clear timer =3D 0.1 sec. means blocking of = new flows last for 100ms after “block admission signal” was received.

- Orange trace is the admitted traffic rate on the link.

- Pink trace shows number of flows admitted and active. =

- Red trace shows cumulative number of flows = blocked.

To understand the results here is additional = information.

Simulation = setup:

- The flow arrival is 7.5 = flows/sec.

- Mean holding time of flow is 60 = seconds.

- Offered load on average is 36 Mbps or 450 = flows.

- Flow arrival uses Poisson = distribution.

- No probing is used in these = simulations.

- Media delay limit =3D 0 sec. means start = of sending packets is not delayed.

- Media delay limit =3D 10 sec. means start = of sending packets is delayed randomly between 0 and 10 = seconds.

-All flows belong to one = aggregate.

Admission Control:

In simulations, when egress detects a packet = marked, it sends “block admission signal” to ingress. The = block admission signal blocks admission of new flows for a period of = time, programmable 100ms or 1 sec. after which time if no block = admission signal were received new flows are admitted. The delay from = marking of packet and sending of block admission signal is programmable = and we simulate with 2 and 200ms as the RTT.

Also here is a link to = more simulation results with different scenarios. Admission control = results starting on page 13.

http://standards.nortel.com/pcn/3sM-Simulation-1.pdf

Regards, Joe.

>Cheers


>Bob

email:babiarz@nortel.com

Telephone:613-763-6098

-----Original Message-----
From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk<= /A>]
Sent: August 30, 2007 3:41 PM
To: Babiarz, Jozef (CAR:0S03)
Cc: Geib, Ruediger; l.andrew@ieee.org; pcn@ietf.org; = eeschan@cityu.edu.hk
Subject: RE: [PCN] draft-eardley-pcn-architecture-00.txt on-off = marking

Joe,

At = 15:17 27/08/2007, Jozef Babiarz wrote:

>I think there is a bit more to this issue than just different = levels of

>pre-congestion.

>

>For admission control the challenge for PCN is to find out how = much new

>traffic can be added on to a specific link or path and not to = determine

>the level of congestion.

I = agree that the AC challenge for PCN is to find how much new traffic can =

be = added, but surely not just for a specific link. The full challenge is =

for any single ingress edge node to know how much it can add. But = it has to

accept the fact that it doesn't know how many other ingress nodes = are

competing to add traffic to the same link. (See previous response = to

Ruediger - although I don't think you're asking for the same thing, = but it

sounds like you are).

more...

>The purpose of admission control is to = prevent

>congestion of the service class on link that forwards PCN = traffic. PCN

>is deployed in Diffserv networks, with the understanding that = PCN

>traffic is forwarded using priority = scheduling.

>

>Voice with silence suppression plus calls naturally ending as = well new

>calls being added generates highly variable traffic. The = marking by

>interior node to indicate that PCN admission threshold is = exceeded or

>not, needs to be quick to reflect true traffic = levels.

Agreed

>Analysis of the

>marking density and control of response to the marking can be = handled at

>the edges. The proposed marking scheme in = draft-babiarz-pcn-3sm-00.txt

>for admission control, produces the following behavior, when = PCN traffic

>is fare below the admission stop threshold, no packets are = marked. As

>the variable traffic increases and some packets exceed the = token bucket

>rate (admission stop threshold) they are marked. If additional = new

>traffic is allowed to be admitted on to the link, more packets = will

>exceed the token bucket rate therefore marking density = increases

>possibly until all packets are marked. However, for pure and = stable CBR

>traffic you will get a step marking (on-off) where the = transition from

>no marking to all packets marked being quick.

I'm not sure which you you are saying is more = desirable:

- = the outcome with variable traffic (a gradual transition from 0-100% = marking)

- = or the outcome for CBR traffic (a step change)?

I = think you're saying that a gradual transition is desirable, but that = even

with on-off marking you get a gradual transition as long as there's =

variation in the traffic, which there usually is.

(See later for my view)

>

>My view is that PCN should work equally well regardless of the = number of

>flows in an ingress-egress aggregate from one to many = flows,

Agreed.

>as well

>should work without the need for ingress-egress aggregation = concept.

If = you mean by this, that a new flow shouldn't need to use information from =

existing flows in an aggregate, I agree. That's a performance = enhancement,

not an essential function.

>The

>so called on-off marking approach is not that dependent on the = rate of

>ingress-egress traffic meaning that edge node will be able to = determine

>if new flow should be admitted based on low bit rate (probe or = single

>voice flow) or high bit rate flow(s) passing through the = pre-congested

>link.

I = think I am agreeing with you in everything you say, except on one point =

(if I understand you right). So I'll restate everything I believe, = tagged

with whether we're agreeing or disagreeing, to try to reach = closure, as

we've been going round these issues for some time (pre-PCN = w-g).

Agreement?: A gradual transition in interior admission marking is = desirable

as = the boundary nodes can always turn this into a threshold or use it in =

innovative ways, to be determined.

Agreement?: Whether the transition is gradual is a serious issue, = because a

distributed measurement-based admission control (DMBAC) system like = PCN

admits traffic one round trip before it knows whether it should = have done.

So = in a flash crowd (mass calling event) admissions can overshoot if the =

interior admission marking only flips from 0-100% at the last = instant.

Whereas if the interior nodes give a gradual increase, the boundary = nodes

can use the early warning contingency to be more conservative when = necessary.

Agreement: We hope and expect that traffic levels will be variable = because

of = silence suppression etc. Then step (on-off) marking on interior nodes =

will be sufficient. It will still lead to a gradual increase in = admission

marking as the token bucket level goes back and forth across the = step,

because it will stay increasingly on the marking side the closer = the

average rate gets to the 'PCN lower rate' ("admission stop = threshold" in

your terms).

Agreement: It would be sufficient to standardise step marking = (on-off e.g.

3sm) as a minimum requirement for admission = control.

Agreement: This would leave one case of pure and stable CBR traffic = that

would not give a smooth rise in marking, but would toggle from 0 to = 100% on

the addition of the last flow.

Disagreement?: Stable CBR-like traffic won't necessarily be unusual = in

certain networks. It is certainly possible (tho unlikely) that a = particular

link may be fed by a large proportion of CBR codecs without silence =

suppression (e.g. where a network itself deploys a load of cheap = codecs for

PSTN-emulation). But much more likely are links where the total = traffic is

CBR-like even tho each flow is variable, due to statistical = aggregation of

very many variable flows.

Disagreement?: The algo shouldn't have to rely on the traffic being =

variable to behave in the way we want. Ramp marking (as in the body = of

draft-briscoe-twvwg-cl-phb-03.txt) creates a gradual increase in = marking

even for CBR-like traffic. Then the marking algo gives a more = gradual

transition WHATEVER the traffic (unless it's locally shaped to be = absolutly

pure CBR).

The following ASCII art illustrates this. Even for step marking, = the curve

of = marking probability against mean arrival rate is smoother for traffic =

with more variance, but if the traffic doesn't have enough = variance, you

can push the curve smoother by using a ramp algo. The flatter the = ramp, the

smoother the curve.

^_

|p, mean marking = probability          &n= bsp;           &nb= sp;    |

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

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

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

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

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

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

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

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

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

|           &= nbsp;           &n= bsp;            = variance        ;;|

|           &= nbsp;           &n= bsp;        of total = PCN       / ||

|           &= nbsp;           &n= bsp;     traffic on = link,      | ||

|           &= nbsp;           &n= bsp;           &nb= sp;       = v       , ||

|           &= nbsp;           &n= bsp;     = OR            = ; +---  .  ||

|           &= nbsp;           &n= bsp;     slope of ramp  |\    = ,  ||

|           &= nbsp;           &n= bsp;           &nb= sp;        | \  /   = ||

|           &= nbsp;           &n= bsp;           &nb= sp;           = _/    ||

|           &= nbsp;           &n= bsp;           &nb= sp;        __/ \    = ||

|           &= nbsp;           &n= bsp;           &nb= sp;   ,--^^     \   = ||           = mean

|           &= nbsp;           &n= bsp; = __,,,,----^^^^          = ; \_/ |        = arrival

|    /|    = ______._,_=3D_=3D_=3D_____,,,,,,,,,,......----^\  = |           = rate,

+---/ | = /----------------------------------------------+------------->_=

      = |/            = ;            =             &= nbsp;          = X            =   x

           &n= bsp;           &nb= sp;           &nbs= p;          PCN lower = rate


Agreement: A gradual increase in marking will sometimes lead to a = flow

being denied that could have been admitted. But that's unavoidable = anyway

if = some flows are variable - we even had that trade-off to an extent even =

in = Intserv-style admission control. However, ramp marking makes the range =

of = rates over which you get under-admission wider than it was with just =

natural traffic variability.

Agreement?:

* = For a link with a large number of flows with high statistical =

multiplexing, the benefit of artifically creating a gradual = increase using

ramp marking outweighs the cost. You get early warning of a flash = crowd but

miss the odd flow unnecessarily (when the system hits its admission = limit,

which should be rare anyway).

* = For a link only carrying a small number of flows within its PCN lower =

rate, the cost of ramp marking in under-admissions outweighs its = benefit.

Note, this needen't be a low capacity link - it might be a high = capacity

link with a few large flows.

* = For a link in between - with high number of flows but not high enough =

stat mux to smooth to CBR-like, the traffic variance may give = enough of a

gradual increase to handle flash crowds without needing to add more =

smoothness using ramp marking (ie cost of ramp under-admissions = outweights

benefit of more smoothness when you've got enough = anyway).

Agreement?: Note: links with a few flows fall outside the PCN = charter, but

that shouldn't stop us prefering solutions that handle such links, = all

other issues being equal.

Agreement?: If I'm right in all this, I believe we should allow and =

encourage (but not mandate) vendors to implement ramp marking on = machines

targeted for PCN interior nodes (ie SHOULD implement ramp). Then = ramp is

available if it's needed, but can be turned off if it = isn't.

Agreement?: But we should advise that step marking is the best = solution (ie

SHOULD deploy step) if there's enough variability in the traffic = anyway (or

only a few flows are expected on the link).

Agreement?: But ramp marking is hard to do on much current = hardware. So

it's useful that it's not a MUST. However, if an operator needs = ramp

marking (a risk of flash crowds and links with smoothly aggregated = traffic)

we = should caution that inability to deploy ramp is NOT a good reason for =

not deploying it.

Disagreement: You imply that, with low packet probing rates, step = (on-off)

marking can determine whether to admit a new flow faster than ramp. = Given

both have a range over which they mark packets probabilistically, I = don't

believe this is the way to state the distinction between them. = Certainly

ramp marks packets probabilistically over a wider range of loads. = But, for

either algo, the ingress boundary node doesn't know whether an = interior

node is within this range or not when it probes. So it has to send = as many

probes in both cases in case an interior node might be in its = probabilistic

range of marking.

Disagreement?: In fact, ramp actually gives a much quicker probing = time

than step:

* = Step: If the queue is above the step 5% of the time due to traffic =

variation, over a *long* time period it will indeed mark 5% of = probes. BUT

over a *short* period it will mark all the probes the same (queue = length

correlation over time).

* = Ramp: If the queue is varying around the point on the ramp that is doing =

5% = marking, it will mark each probe with ~5% probability, independently of =

how it marked previous ones.

So, with either algo you have to send the same number of probes, = but with

ramp you can send them back-to-back, while with step you get hardly = any

more information unless you send them spaced over a long time = period (ie a

few seconds). Hence ramp should be much quicker to = probe.


Pls say whether you agree or disagree with each point, so we can = home in on

exactly why we keep both going round this loop.

Cheers


Bob

>Regards, Joe

>email:babiarz@nortel.com

>Telephone:613-763-6098

>-----Original Message-----

>From: Geib, Ruediger [mailto:Ruediger.Geib@t-system= s.com]

>Sent: August 24, 2007 3:09 AM

>To: l.andrew@ieee.org; = rbriscoe@jungle.bt.co.uk

>Cc: pcn@ietf.org; eeschan@cityu.edu.hk

>Subject: RE: [PCN] draft-eardley-pcn-architecture-00.txt on-off = marking

>

>Lachlan, Bob,

>

>you both seem to agree that ramp marking is the best = solution.

>Picking up Lachlan's pretty sound arguments on different = thresholds

>for different types of incoming calls - what you describe = is

>estimating the available (not consumed) PCN bandwidth rather = than

>just a "pre congestion notification", I = think.

>If there's a simple solution to realize this idea, PCN = should

>investigate it. This could be helpful if there's a new call to = be

>admitted and no PCN flow exists between two gateways. The = question

>then would be, whether a certain bandwidth is available, = rather

>than "any congestion visible".


ToDo:

* = an edge ingress node needs to use its own knowledge of its own rate =

contribution to the problem (x).

0 = <=3D p <=3D 1



Bob

>Regards,

>

>Ruediger

>

>

>|Lachlan wrote:

>|I believe that the marking scheme should carry as much = information as

>|possible about the network state, and that thresholding should = be done

>|as late as possible (at the decision-making end-points).  = The more

>|information the decision-making entity has, better the = decisions it

>|can make.

>|

>|If things like thresholding are done where the admission = decisions are

>|made, there is also a smoother upgrade path for changes in = the

>|admission rules.  For example, an operator may want to = apply different

>|thresholds applied to different types of incoming calls.  = If routers

>|provide a single threshold, this can't be implemented at a = later

>|stage.  Similarly, an operator may want to admit a = certain percentage

>|of traffic dependent on the congestion level, rather than = admitting

>|all or none.

>

>|Bob wrote:

>|[BB] The problem we were trying to solve with ramp marking was = the

>|reverse:

>|we were looking for a marking algo that produced a smooth = increase in

>|marking over a wider range of loads. The edge nodes can always = turn a

>|smooth rise into a toggle at a specific threshold marking = level.

>

>

>_______________________________________________

>PCN mailing list

>PCN@ietf.org

>https://www1.ietf.org= /mailman/listinfo/pcn

____________________________________________________________________= ________

Bob Briscoe, = <bob.briscoe@bt.com>      Networks = Research Centre, BT Research

B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 = 3RE,UK.    +44 1473 645196

------_=_NextPart_001_01C7F681.AFDB2906-- --===============0277131912== 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://www1.ietf.org/mailman/listinfo/pcn --===============0277131912==-- From pcn-bounces@ietf.org Wed Sep 19 02:32:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXt69-0008AK-Lp; Wed, 19 Sep 2007 02:31:45 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IXt67-00089R-W2 for pcn-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 02:31:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXt67-00089J-LF for pcn@ietf.org; Wed, 19 Sep 2007 02:31:43 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXt60-0008Hs-SG for pcn@ietf.org; Wed, 19 Sep 2007 02:31:43 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 19 Sep 2007 08:31:16 +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); Wed, 19 Sep 2007 08:31:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds rate" Date: Wed, 19 Sep 2007 08:31:15 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C0DE7C3@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A0@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCN architecture, use of phrases like "exceeds rate" thread-index: AcfZ4sD4MX/wup2KTYmWXZzVtqCqDAgo1F2A From: "Geib, Ruediger" To: X-OriginalArrivalTime: 19 Sep 2007 06:31:16.0091 (UTC) FILETIME=[AE57F4B0:01C7FA86] X-Spam-Score: -1.0 (-) X-Scan-Signature: bb7a33d18683bf5063a44e640cf125f1 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1695816503==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1695816503== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FA86.AE2144D9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FA86.AE2144D9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil, =20 with a small delay of 5 weeks (but no one else reacted yet?): both, description and definition proposed by you below are allright with me. =20 Regards, =20 Ruediger =20 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Wednesday, August 08, 2007 7:37 PM To: pcn@ietf.org Subject: [PCN] PCN architecture, use of phrases like "exceeds rate" I wrote a new / replacement para in the intro - to try to overcome bob's rant - which complained about using phrases like "do marking when the current rate exceeds a reference rate" [copied at end] - whilst still giving the innocent reader (if such a person exists) a sporting chance of understanding what it's all about: =20 <> =20 I know the last bit mentions rate - hopefully it's ok by relating it to the overall system performance, rather than how each link does marking. I'm not sure whether "*roughly*" is really necessary or whether you think i cheated.=20 =20 I also added to the definitions for example: <> =20 ** bob's rant > * Marking is when "current" rate is "above" a reference rate? >=20 > " o Admission-marking: the marking of PCN-packets by a PCN-node to > indicate that the PCN-traffic on a link is above the configured- > admissible-rate. >=20 > o Termination-marking: the marking of PCN-packets by a PCN-node to > indicate that the PCN-traffic on a link is above the configured- > termination-rate. > " >=20 > These marking definitions and other examples hilighted in magenta in the > above PDF prejudge marking mechanisms as rate measurements. >=20 > We don't just have marking when the _current_rate is _above_ the reference > rate. We can have marking when the _current_ rate is _below_, or when the > _past_ rate was _above_. >=20 > The configured rates are parameters of a (to be defined) mechanism. These > mechanisms will not have to mark packets when the rate is above these > configured rates. That depends on the mechanism. >=20 > This sounds picky, but it's actually a big rant I have about all this > loose > discussion of rate (yes, the issue of what rate means is mentioned in the > draft, but we need to be careful about such sloppy usage). IMHO, it's > important to scale our conception of time down to inter-arrival times, to > be precise. Then the rate is packet size/interarrival time. Therefore seen > at a small enough timescale, rate might be varying rapidly above and below > the configured rate. >=20 > A marking mechanism could be implemented by a virtual queue rather than a > rate measurement. When the offered instantaneous rate has been below the > configured-admission-rate for many packets (perhaps hundreds), marking > will > and should still occur,... if the virtual queue is still above a marking > threshold even if it is emptying rather than filling. This can be a > deliberate design choice that says we still want admission marking when > there has been recent overload to allow time for the control loop to work. > It ensures a greater safety margin is automatically created by the marking > mechanism when recent traffic had higher variance. This was the marking > algorithm that was most studied and simulated in CL-PHB draft. =20 =20 =20 ------_=_NextPart_001_01C7FA86.AE2144D9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Phil,
 
with a=20 small delay of 5 weeks (but no one else reacted=20 yet?): both, description and definition proposed by=20 you below are allright with me.
 
Regards,
 
Ruediger
 
-----Original Message-----
From: = philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: Wednesday, August 08, = 2007 7:37=20 PM
To: pcn@ietf.org
Subject: [PCN] PCN = architecture, use=20 of phrases like "exceeds rate"

I wrote a new / replacement para in the = intro - to try=20 to overcome bob’s rant - which complained about using phrases = like “do marking=20 when the current rate exceeds a reference rate” [copied at end] = - whilst still=20 giving the innocent reader (if such a person exists) a sporting chance = of=20 understanding what it's all about:

 

<<Two rates, a PCN-lower-rate and a=20 PCN-upper-rate, can be associated with each link of the PCN-domain. = Each rate=20 is used by an algorithm (specified in another document) that = determines how=20 and when a number of PCN-packets are marked, and how the markings are = encoded=20 in packet headers. PCN-egress-nodes make measurements of the packet = markings=20 and send information as necessary to the nodes that make the decision = about=20 which PCN-flows to accept/reject or terminate, based on this = information.=20 Another document will describe decision-making algorithms. Overall the = aim is=20 to enable PCN-nodes to give an "early warning" of potential congestion = before=20 there is any significant build-up of PCN-packets in the queue; the = admission=20 control mechanism limits the PCN-traffic on each link to *roughly* its = PCN-lower-rate and the flow termination mechanism limits the = PCN-traffic on=20 each link to *roughly* its PCN-upper-rate.>>

 

I know the last bit mentions rate - = hopefully it's ok=20 by relating it to the overall system performance, rather than how each = link=20 does marking. I'm not sure whether "*roughly*" is really necessary or = whether=20 you think i cheated.

 

I also added to the definitions for=20 example:

<<Threshold-marking: a PCN-marking = algorithm=20 such that all PCN-traffic is marked if the PCN-traffic exceeds a = particular=20 rate (either the PCN-lower-rate or PCN-upper-rate). NOTE: The = definition=20 reflects the overall intent of the algorithm rather than its = instantaneous=20 behaviour, since the rate measured at a particular moment depends on = the=20 algorithm, its implementation and the traffic's variance as well as = its=20 rate.>>

 

** bob’s rant

> * Marking is when "current" rate is = "above" a=20 reference rate?

>

> "   o  = Admission-marking: the=20 marking of PCN-packets by a PCN-node to

>       =20 indicate that the PCN-traffic on a link is above the=20 configured-

>       =20 admissible-rate.

>

>     o =20 Termination-marking: the marking of PCN-packets by a PCN-node=20 to

>       =20 indicate that the PCN-traffic on a link is above the=20 configured-

>       =20 termination-rate.

> "

>

> These marking definitions and other = examples=20 hilighted in magenta in the

> above PDF prejudge marking mechanisms = as rate=20 measurements.

>

> We don't just have marking when the = _current_rate=20 is _above_ the reference

> rate. We can have marking when the = _current_ rate=20 is _below_, or when the

> _past_ rate was = _above_.

>

> The configured rates are parameters of = a (to be=20 defined) mechanism. These

> mechanisms will not have to mark = packets when the=20 rate is above these

> configured rates. That depends on the=20 mechanism.

>

> This sounds picky, but it's actually a = big rant I=20 have about all this

> loose

> discussion of rate (yes, the issue of = what rate=20 means is mentioned in the

> draft, but we need to be careful about = such=20 sloppy usage). IMHO, it's

> important to scale our conception of = time down to=20 inter-arrival times, to

> be precise. Then the rate is packet=20 size/interarrival time. Therefore seen

> at a small enough timescale, rate might = be=20 varying rapidly above and below

> the configured rate.

>

> A marking mechanism could be = implemented by a=20 virtual queue rather than a

> rate measurement. When the offered = instantaneous=20 rate has been below the

> configured-admission-rate for many = packets=20 (perhaps hundreds), marking

> will

> and should still occur,... if the = virtual queue=20 is still above a marking

> threshold even if it is emptying rather = than=20 filling. This can be a

> deliberate design choice that says we = still want=20 admission marking when

> there has been recent overload to allow = time for=20 the control loop to work.

> It ensures a greater safety margin is=20 automatically created by the marking

> mechanism when recent traffic had = higher=20 variance. This was the marking

> algorithm that was most studied and = simulated in=20 CL-PHB draft.

 

 

 

------_=_NextPart_001_01C7FA86.AE2144D9-- --===============1695816503== 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://www1.ietf.org/mailman/listinfo/pcn --===============1695816503==-- From pcn-bounces@ietf.org Wed Sep 19 03:25:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXtvC-00057x-GV; Wed, 19 Sep 2007 03:24:30 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IXtvB-00057f-10 for pcn-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 03:24:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXtv6-00056r-KH for pcn@ietf.org; Wed, 19 Sep 2007 03:24:24 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXtuz-0001AQ-R6 for pcn@ietf.org; Wed, 19 Sep 2007 03:24:24 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 19 Sep 2007 09:24:11 +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); Wed, 19 Sep 2007 09:24:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN architecture, revised sub-section on probing Date: Wed, 19 Sep 2007 09:24:10 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C0DE7C4@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A9@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCN architecture, revised sub-section on probing thread-index: AcfaCZ+BOedo9lzYRa+g2kHgUi9IgAggHadA From: "Geib, Ruediger" To: X-OriginalArrivalTime: 19 Sep 2007 07:24:11.0151 (UTC) FILETIME=[12D3A9F0:01C7FA8E] X-Spam-Score: -1.0 (-) X-Scan-Signature: 539f8b288ab42db633e5c7cf1c34fca1 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1839667340==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1839667340== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FA8E.1274976C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FA8E.1274976C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil, =20 my views on the subject: =20 - the discussion on the decision when to apply probing misses one important aspect, at least if=20 you look at a single domain: probing is only required if any pre-congestion occurs within this=20 domain. If there's no pre congested link within a domain, no probing is required within this=20 domain.=20 =20 - given that probing is only applied within a domain, if there's pre-congestion on any link, then=20 the only purpose of probing is to find out, whether traffic from the particular ingress to a=20 desired egress would contribute to this pre-congestion. The probing flow then should be=20 designed to ensure that packets of the probing flow are marked (and if interpretation is=20 to be as simple as possible: marked probing packets mean no admission).=20 =20 - If there's no flow between an ingress and an egress and ECMP is operational within a=20 domain, the ingress may have to signal its intention to probe to an egress. =20 I'm not sure whether a useful probing mechanism is easy to develop an therefore support=20 your proposal to regard probing as optional (at least in the single domain case). =20 Regards, =20 Ruediger =20 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Thursday, August 09, 2007 12:15 AM To: pcn@ietf.org Subject: [PCN] PCN architecture, revised sub-section on probing This is to flag up that I wrote a revised sub-section (in Section 5, Detailed functional architecture) about probing. to reflect (hopefully!) some other discussion we had on the list in july.=20 =20 5.5. Probing functions =20 Probing functions are optional, and can be used for admission control. A PCN-ingress-node generates and sends probe packets in order to test the pre-congestion level. Probing is useful or even essential under the following conditions: =20 o when an ingress-egress-aggregate carries no traffic (or too little traffic for the PCN-egress-node to accurately make the "measurements of PCN-traffic" that are required for an admission decision). It may be that the traffic levels on other ingress- egress-aggregates are so high that a new flow shouldn't be admitted on the 'empty' ingress-egress-aggregate. Probing is useful to check this. =20 o in the presence of multipath routing (ECMP) between the PCN- boundary-nodes, when some paths are pre-congested there may be other paths which aren't pre-congested. Probing is useful to determine whether the new flow would follow a path that isn't pre- congested and hence can be admitted. =20 Probe packets may be simple data addressed to the PCN-egress-node and require no protocol standardisation, although there will be best practice for their number, size and rate. There are two possibilities for how probing is triggered: =20 o the PCN-egress-node requests (signals) the PCN-ingress-node to generate probe traffic =20 o if the PCN-ingress-node knows which PCN-egress-node is associated with the destination address in the admission request, then the PCN-ingress-node could know it has no reservation with that PCN- egress-node and unilaterally start probing. =20 The probing functions are: =20 o Make decision that probing is needed =20 o (if required) Communicate the request that probing is needed - the PCN-egress-node signals to the PCN-ingress-node that probe traffic is needed =20 o Generate probe traffic - the PCN-ingress-node generates the probe traffic. The appropriate number (or rate) of probe packets will depend on the PCN-marking algorithm; for example an excess-rate- marking algorithm generates fewer PCN-marks than a threshold- marking algorithm. =20 o Forward probe packets - as far as PCN-interior-nodes are concerned, probe packets must be handled the same as (ordinary data) PCN-packets. =20 o Consume probe packets - the PCN-egress-node consumes probe packets to ensure that they don't travel beyond the PCN-domain. =20 ------_=_NextPart_001_01C7FA8E.1274976C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Phil,
 
my=20 views on the subject:
 
- the=20 discussion on the decision when to apply probing misses one = important=20 aspect, at least if
 =20 you look at a single domain: probing is only required if any = pre-congestion=20 occurs within this
 =20 domain. If there's no pre congested link within a domain, no probing is = required=20 within this
 =20 domain. 
 
-=20 given that probing is only applied within a domain, if there's = pre-congestion on=20 any link, then
  the only purpose of probing is to = find out,=20 whether traffic from the particular ingress to a
 =20 desired egress would contribute to this = pre-congestion. The probing flow=20 then should be 
 =20 designed to ensure that packets of the = probing=20 flow are marked (and if interpretation is=20
 =20 to be as simple as possible: marked probing=20 packets mean no admission).
 
- If=20 there's no flow between an ingress and an egress and ECMP is operational = within=20 a
 =20 domain, the ingress may have to signal its intention to probe to an=20 egress.
 
I'm=20 not sure whether a useful probing mechanism is easy to develop an = therefore=20 support
your=20 proposal to regard probing as optional (at least in the single domain=20 case).
 
Regards,
 
Ruediger
 
 -----Original = Message-----
From:=20 philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: = Thursday,=20 August 09, 2007 12:15 AM
To: pcn@ietf.org
Subject: = [PCN] PCN=20 architecture, revised sub-section on probing

This is to flag up that I wrote a revised = sub-section=20 (in Section 5, Detailed functional architecture) about probing. to = reflect=20 (hopefully!) some other discussion we had on the list in july.=20

 

5.5.  Probing = functions

 

   Probing functions are optional, = and can=20 be used for admission

   control.  A = PCN-ingress-node=20 generates and sends probe packets in

   order to test the = pre-congestion=20 level.  Probing is useful or even

   essential under the following=20 conditions:

 

   o  when an = ingress-egress-aggregate=20 carries no traffic (or too little

      traffic for = the=20 PCN-egress-node to accurately make the

      "measurements = of=20 PCN-traffic" that are required for an admission

      = decision).  It may=20 be that the traffic levels on other ingress-

      = egress-aggregates are=20 so high that a new flow shouldn't be

      admitted on = the 'empty'=20 ingress-egress-aggregate.  Probing is

      useful to = check=20 this.

 

   o  in the presence of = multipath=20 routing (ECMP) between the PCN-

      = boundary-nodes, when=20 some paths are pre-congested there may be

      other paths = which=20 aren't pre-congested.  Probing is useful to

      determine = whether the=20 new flow would follow a path that isn't pre-

      congested and = hence can=20 be admitted.

 

   Probe packets may be simple = data=20 addressed to the PCN-egress-node and

   require no protocol = standardisation,=20 although there will be best

   practice for their number, size = and=20 rate.  There are two

   possibilities for how probing = is=20 triggered:

 

   o  the PCN-egress-node = requests=20 (signals) the PCN-ingress-node to

      generate = probe=20 traffic

 

   o  if the PCN-ingress-node = knows=20 which PCN-egress-node is associated

      with the = destination=20 address in the admission request, then the

      = PCN-ingress-node could=20 know it has no reservation with that PCN-

      egress-node = and=20 unilaterally start probing.

 

   The probing functions=20 are:

 

   o  Make decision that = probing is=20 needed

 

   o  (if required) = Communicate the=20 request that probing is needed - the

      = PCN-egress-node signals=20 to the PCN-ingress-node that probe traffic

      is=20 needed

 

   o  Generate probe traffic = - the=20 PCN-ingress-node generates the probe

      = traffic.  The=20 appropriate number (or rate) of probe packets will

      depend on the = PCN-marking algorithm; for example an excess-rate-

      marking = algorithm=20 generates fewer PCN-marks than a threshold-

      marking=20 algorithm.

 

   o  Forward probe packets - = as far as=20 PCN-interior-nodes are

      concerned, = probe=20 packets must be handled the same as (ordinary

      data)=20 PCN-packets.

 

   o  Consume probe packets - = the=20 PCN-egress-node consumes probe packets

      to ensure = that they=20 don't travel beyond the PCN-domain.

 

------_=_NextPart_001_01C7FA8E.1274976C-- --===============1839667340== 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://www1.ietf.org/mailman/listinfo/pcn --===============1839667340==-- From pcn-bounces@ietf.org Wed Sep 19 21:55:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYBFp-0001VV-2R; Wed, 19 Sep 2007 21:54:57 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IYBFo-0001Se-E2 for pcn-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 21:54:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYBFo-0001AE-1K for pcn@ietf.org; Wed, 19 Sep 2007 21:54:56 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYBFc-0005Fo-1a for pcn@ietf.org; Wed, 19 Sep 2007 21:54:44 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8K1scb08117; Thu, 20 Sep 2007 01:54:38 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds rate" Date: Wed, 19 Sep 2007 21:54:36 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646512377342@zcarhxm1.corp.nortel.com> In-Reply-To: <1B6169C658325341A3B8066E23919E1C0DE7C3@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture, use of phrases like "exceeds rate" Thread-Index: AcfZ4sD4MX/wup2KTYmWXZzVtqCqDAgo1F2AACdxudA= References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A0@E03MVZ1-UKDY.domain1.systemhost.net> <1B6169C658325341A3B8066E23919E1C0DE7C3@S4DE8PSAANK.mitte.t-com.de> From: "Jozef Babiarz" To: "Geib, Ruediger" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a9d8f61f7718176ef97b85bbcc64331 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1710725835==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1710725835== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FB29.337F5A8E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FB29.337F5A8E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil and others, since Ruediger email brought this to my attention. I have the following comments. =20 I think we should change the word "algorithm" to "marking behaviour" and "rate" to "threshold". At least I believe that we should avoid specifying a specific algorithm but just define the behaviour of the algorithm. This would allow vendors to choose an algorithm that they believe gives best results. So would propose the following. =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: September 19, 2007 2:31 AM To: philip.eardley@bt.com Cc: pcn@ietf.org Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds rate" =20 Phil, =20 with a small delay of 5 weeks (but no one else reacted yet?): both, description and definition proposed by you below are allright with me. =20 Regards, =20 Ruediger =20 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Wednesday, August 08, 2007 7:37 PM To: pcn@ietf.org Subject: [PCN] PCN architecture, use of phrases like "exceeds rate" I wrote a new / replacement para in the intro - to try to overcome bob's rant - which complained about using phrases like "do marking when the current rate exceeds a reference rate" [copied at end] - whilst still giving the innocent reader (if such a person exists) a sporting chance of understanding what it's all about: =20 <> =20 I know the last bit mentions rate - hopefully it's ok by relating it to the overall system performance, rather than how each link does marking. I'm not sure whether "*roughly*" is really necessary or whether you think i cheated.=20 =20 I also added to the definitions for example: <> =20 ** bob's rant > * Marking is when "current" rate is "above" a reference rate? >=20 > " o Admission-marking: the marking of PCN-packets by a PCN-node to > indicate that the PCN-traffic on a link is above the configured- > admissible-rate. >=20 > o Termination-marking: the marking of PCN-packets by a PCN-node to > indicate that the PCN-traffic on a link is above the configured- > termination-rate. > " >=20 > These marking definitions and other examples hilighted in magenta in the > above PDF prejudge marking mechanisms as rate measurements. >=20 > We don't just have marking when the _current_rate is _above_ the reference > rate. We can have marking when the _current_ rate is _below_, or when the > _past_ rate was _above_. >=20 > The configured rates are parameters of a (to be defined) mechanism. These > mechanisms will not have to mark packets when the rate is above these > configured rates. That depends on the mechanism. >=20 > This sounds picky, but it's actually a big rant I have about all this > loose > discussion of rate (yes, the issue of what rate means is mentioned in the > draft, but we need to be careful about such sloppy usage). IMHO, it's > important to scale our conception of time down to inter-arrival times, to > be precise. Then the rate is packet size/interarrival time. Therefore seen > at a small enough timescale, rate might be varying rapidly above and below > the configured rate. >=20 > A marking mechanism could be implemented by a virtual queue rather than a > rate measurement. When the offered instantaneous rate has been below the > configured-admission-rate for many packets (perhaps hundreds), marking > will > and should still occur,... if the virtual queue is still above a marking > threshold even if it is emptying rather than filling. This can be a > deliberate design choice that says we still want admission marking when > there has been recent overload to allow time for the control loop to work. > It ensures a greater safety margin is automatically created by the marking > mechanism when recent traffic had higher variance. This was the marking > algorithm that was most studied and simulated in CL-PHB draft. =20 =20 =20 ------_=_NextPart_001_01C7FB29.337F5A8E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Phil and others, since Ruediger = email brought this to my attention. I have the following = comments.

 

I think we should change the word = “algorithm” to “marking behaviour” and “rate” to = “threshold”. At least I believe that we should avoid specifying a specific algorithm = but just define the behaviour of the algorithm. This would allow vendors to = choose an algorithm that they believe gives best results. So would propose the following.

  

 

<<Two traffic thresholds, a = PCN-lower-threshold and a PCN-upper-threshold, can be associated with each link of the = PCN-domain. Each traffic threshold has a marking behaviour(specified in another = document) that determines how and when PCN-packets are marked, and how the = markings are encoded in packet headers. PCN-egress-nodes make measurements of the = packet markings and send information as necessary to the nodes that make the = decision about which PCN-flow(s) to accept/reject or terminate, based on this information. Another document will describe decision-making behaviour. = Overall the aim is to enable PCN-nodes to give an "early warning" of potential congestion before there is any significant build-up of = PCN-packets in the queue; the admission control mechanism limits the PCN-traffic on = each link to *roughly* its PCN-lower- threshold and the flow termination mechanism = limits the PCN-traffic on each link to *roughly* its = PCN-upper-threshold.>>

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

From: Geib, = Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: September 19, 2007 = 2:31 AM
To: = philip.eardley@bt.com
Cc: pcn@ietf.org
Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds = rate"

 

Phil,

 

with a small = delay of 5 weeks (but no one else reacted = yet?): both, description and definition proposed by you below are allright with = me.

 

Regards,

 

Ruediger

 

-----Original Message-----
From: = philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Wednesday, August = 08, 2007 7:37 PM
To: pcn@ietf.org
Subject: [PCN] PCN = architecture, use of phrases like "exceeds rate"

I wrote a new / replacement para in the intro = - to try to overcome bob’s rant - which complained about using phrases like “do marking when the current rate exceeds a reference rate” = [copied at end] - whilst still giving the innocent reader (if such a person = exists) a sporting chance of understanding what it's all = about:

 

<<Two rates, a PCN-lower-rate and a PCN-upper-rate, can be associated with each link of the PCN-domain. Each = rate is used by an algorithm (specified in another document) that determines = how and when a number of PCN-packets are marked, and how the markings are = encoded in packet headers. PCN-egress-nodes make measurements of the packet = markings and send information as necessary to the nodes that make the decision about = which PCN-flows to accept/reject or terminate, based on this information. = Another document will describe decision-making algorithms. Overall the aim is to = enable PCN-nodes to give an "early warning" of potential congestion = before there is any significant build-up of PCN-packets in the queue; the = admission control mechanism limits the PCN-traffic on each link to *roughly* its PCN-lower-rate and the flow termination mechanism limits the PCN-traffic = on each link to *roughly* its = PCN-upper-rate.>>

 

I know the last bit mentions rate - hopefully = it's ok by relating it to the overall system performance, rather than how each = link does marking. I'm not sure whether "*roughly*" is really = necessary or whether you think i cheated.

 

I also added to the definitions for = example:

<<Threshold-marking: a PCN-marking = algorithm such that all PCN-traffic is marked if the PCN-traffic exceeds a = particular rate (either the PCN-lower-rate or PCN-upper-rate). NOTE: The definition reflects the overall intent of the algorithm rather than its = instantaneous behaviour, since the rate measured at a particular moment depends on the algorithm, its implementation and the traffic's variance as well as its rate.>>

 

** bob’s = rant

> * Marking is when "current" = rate is "above" a reference rate?

>

> "   o  = Admission-marking: the marking of PCN-packets by a PCN-node to

>       = indicate that the PCN-traffic on a link is above the = configured-

>       = admissible-rate.

>

>     o  = Termination-marking: the marking of PCN-packets by a PCN-node to

>       = indicate that the PCN-traffic on a link is above the = configured-

>       = termination-rate.

> "

>

> These marking definitions and other = examples hilighted in magenta in the

> above PDF prejudge marking mechanisms as = rate measurements.

>

> We don't just have marking when the = _current_rate is _above_ the reference

> rate. We can have marking when the = _current_ rate is _below_, or when the

> _past_ rate was = _above_.

>

> The configured rates are parameters of a = (to be defined) mechanism. These

> mechanisms will not have to mark packets = when the rate is above these

> configured rates. That depends on the = mechanism.

>

> This sounds picky, but it's actually a = big rant I have about all this

> loose

> discussion of rate (yes, the issue of = what rate means is mentioned in the

> draft, but we need to be careful about = such sloppy usage). IMHO, it's

> important to scale our conception of = time down to inter-arrival times, to

> be precise. Then the rate is packet size/interarrival time. Therefore seen

> at a small enough timescale, rate might = be varying rapidly above and below

> the configured = rate.

>

> A marking mechanism could be implemented = by a virtual queue rather than a

> rate measurement. When the offered = instantaneous rate has been below the

> configured-admission-rate for many = packets (perhaps hundreds), marking

> will

> and should still occur,... if the = virtual queue is still above a marking

> threshold even if it is emptying rather = than filling. This can be a

> deliberate design choice that says we = still want admission marking when

> there has been recent overload to allow = time for the control loop to work.

> It ensures a greater safety margin is automatically created by the marking

> mechanism when recent traffic had higher variance. This was the marking

> algorithm that was most studied and = simulated in CL-PHB draft.

 

 

 

------_=_NextPart_001_01C7FB29.337F5A8E-- --===============1710725835== 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://www1.ietf.org/mailman/listinfo/pcn --===============1710725835==-- From pcn-bounces@ietf.org Mon Sep 24 10:46:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZpAy-0005f2-96; Mon, 24 Sep 2007 10:44:44 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IZpAx-0005es-5x for pcn-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 10:44:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZpAw-0005dQ-JQ for pcn@ietf.org; Mon, 24 Sep 2007 10:44:42 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZpAq-00035c-FG for pcn@ietf.org; Mon, 24 Sep 2007 10:44:37 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 15:44:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds rate" Date: Mon, 24 Sep 2007 15:44:34 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC4FE@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646512377342@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture, use of phrases like "exceeds rate" Thread-Index: AcfZ4sD4MX/wup2KTYmWXZzVtqCqDAgo1F2AACdxudAA5RLFIA== From: To: , X-OriginalArrivalTime: 24 Sep 2007 14:44:35.0229 (UTC) FILETIME=[6CDEBCD0:01C7FEB9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9624d2f5d047d13a089d0be4702e088f Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1071279160==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1071279160== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FEB9.6C585C1C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FEB9.6C585C1C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joe =20 The change of the word 'algorithm' to 'marking behaviour' is ok with me. Yes, we will have to decide what level of detail to standardise the marking behaviour, but we don't have to decide that in this document.=20 =20 I'd prefer not to change 'rate' to 'threshold' at the moment. Since in a token bucket or virtual queue implementation it does correspond to a rate. Also, would prefer not to re-open the terminology rat-hole.=20 =20 Thanks phil =20 -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: 20 September 2007 02:55 To: Geib, Ruediger; Eardley,PL,Philip,CXR9 R Cc: pcn@ietf.org Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds rate" =20 Phil and others, since Ruediger email brought this to my attention. I have the following comments. =20 I think we should change the word "algorithm" to "marking behaviour" and "rate" to "threshold". At least I believe that we should avoid specifying a specific algorithm but just define the behaviour of the algorithm. This would allow vendors to choose an algorithm that they believe gives best results. So would propose the following. =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: September 19, 2007 2:31 AM To: philip.eardley@bt.com Cc: pcn@ietf.org Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds rate" =20 Phil, =20 with a small delay of 5 weeks (but no one else reacted yet?): both, description and definition proposed by you below are allright with me. =20 Regards, =20 Ruediger =20 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Wednesday, August 08, 2007 7:37 PM To: pcn@ietf.org Subject: [PCN] PCN architecture, use of phrases like "exceeds rate" I wrote a new / replacement para in the intro - to try to overcome bob's rant - which complained about using phrases like "do marking when the current rate exceeds a reference rate" [copied at end] - whilst still giving the innocent reader (if such a person exists) a sporting chance of understanding what it's all about: =20 <> =20 I know the last bit mentions rate - hopefully it's ok by relating it to the overall system performance, rather than how each link does marking. I'm not sure whether "*roughly*" is really necessary or whether you think i cheated.=20 =20 I also added to the definitions for example: <> =20 ** bob's rant > * Marking is when "current" rate is "above" a reference rate? >=20 > " o Admission-marking: the marking of PCN-packets by a PCN-node to > indicate that the PCN-traffic on a link is above the configured- > admissible-rate. >=20 > o Termination-marking: the marking of PCN-packets by a PCN-node to > indicate that the PCN-traffic on a link is above the configured- > termination-rate. > " >=20 > These marking definitions and other examples hilighted in magenta in the > above PDF prejudge marking mechanisms as rate measurements. >=20 > We don't just have marking when the _current_rate is _above_ the reference > rate. We can have marking when the _current_ rate is _below_, or when the > _past_ rate was _above_. >=20 > The configured rates are parameters of a (to be defined) mechanism. These > mechanisms will not have to mark packets when the rate is above these > configured rates. That depends on the mechanism. >=20 > This sounds picky, but it's actually a big rant I have about all this > loose > discussion of rate (yes, the issue of what rate means is mentioned in the > draft, but we need to be careful about such sloppy usage). IMHO, it's > important to scale our conception of time down to inter-arrival times, to > be precise. Then the rate is packet size/interarrival time. Therefore seen > at a small enough timescale, rate might be varying rapidly above and below > the configured rate. >=20 > A marking mechanism could be implemented by a virtual queue rather than a > rate measurement. When the offered instantaneous rate has been below the > configured-admission-rate for many packets (perhaps hundreds), marking > will > and should still occur,... if the virtual queue is still above a marking > threshold even if it is emptying rather than filling. This can be a > deliberate design choice that says we still want admission marking when > there has been recent overload to allow time for the control loop to work. > It ensures a greater safety margin is automatically created by the marking > mechanism when recent traffic had higher variance. This was the marking > algorithm that was most studied and simulated in CL-PHB draft. =20 =20 =20 ------_=_NextPart_001_01C7FEB9.6C585C1C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Joe

 

The change of the word = ‘algorithm’ to ‘marking behaviour’ is ok with me. Yes, we will have to = decide what level of detail to standardise the marking behaviour, but we = don’t have to decide that in this document.

 

I’d prefer not to change = ‘rate’ to ‘threshold’ at the moment. Since in a token bucket or = virtual queue implementation it does correspond to a rate. Also, would prefer = not to re-open the terminology rat-hole.

 

Thanks

phil

 

-----Original Message-----
From: Jozef Babiarz [mailto:babiarz@nortel.com]
Sent: 20 September 2007 = 02:55
To: Geib, Ruediger; Eardley,PL,Philip,CXR9 R
Cc: pcn@ietf.org
Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds = rate"

 

Phil and others, = since Ruediger email brought this to my attention. I have the following = comments.

 

I think we = should change the word “algorithm” to “marking behaviour” and “rate” to “threshold”. At least I believe that = we should avoid specifying a specific algorithm but just define the = behaviour of the algorithm. This would allow vendors to choose an algorithm that they believe gives best results. So would propose the = following.

  

 

<<Two traffic thresholds, a PCN-lower-threshold and a PCN-upper-threshold, can be associated with each link of the PCN-domain. = Each traffic threshold has a marking behaviour(specified in another document) = that determines how and when PCN-packets are marked, and how the markings are encoded in packet headers. PCN-egress-nodes make measurements of the = packet markings and send information as necessary to the nodes that make the = decision about which PCN-flow(s) to accept/reject or terminate, based on this = information. Another document will describe decision-making behaviour. Overall the = aim is to enable PCN-nodes to give an "early warning" of potential = congestion before there is any significant build-up of PCN-packets in the queue; = the admission control mechanism limits the PCN-traffic on each link to = *roughly* its PCN-lower- threshold and the flow termination mechanism limits the PCN-traffic on each link to *roughly* its = PCN-upper-threshold.>>

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

From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: September 19, 2007 = 2:31 AM
To: = philip.eardley@bt.com
Cc: pcn@ietf.org
Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds = rate"

 

Phil,

 

with a small delay of 5 weeks = (but no one else reacted yet?): both, description and definition proposed by you below are allright with = me.

 

Regards,

 

Ruediger

 

-----Original = Message-----
From: = philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Wednesday, August = 08, 2007 7:37 PM
To: pcn@ietf.org
Subject: [PCN] PCN = architecture, use of phrases like "exceeds rate"

I wrote a new / replacement para in the intro - to try to = overcome bob’s rant - which complained about using phrases like “do = marking when the current rate exceeds a reference rate” [copied at end] - = whilst still giving the innocent reader (if such a person exists) a sporting = chance of understanding what it's all about:

 

<<Two rates, a PCN-lower-rate and a PCN-upper-rate, can be associated with each link of the PCN-domain. Each rate is used by an = algorithm (specified in another document) that determines how and when a number of PCN-packets are marked, and how the markings are encoded in packet = headers. PCN-egress-nodes make measurements of the packet markings and send = information as necessary to the nodes that make the decision about which PCN-flows = to accept/reject or terminate, based on this information. Another document = will describe decision-making algorithms. Overall the aim is to enable = PCN-nodes to give an "early warning" of potential congestion before there = is any significant build-up of PCN-packets in the queue; the admission control mechanism limits the PCN-traffic on each link to *roughly* its = PCN-lower-rate and the flow termination mechanism limits the PCN-traffic on each link = to *roughly* its PCN-upper-rate.>>

 

I know the last bit mentions rate - hopefully it's ok by = relating it to the overall system performance, rather than how each link does marking. = I'm not sure whether "*roughly*" is really necessary or whether you = think i cheated.

 

I also added to the definitions for example:

<<Threshold-marking: a PCN-marking algorithm such that all PCN-traffic is marked if the PCN-traffic exceeds a particular rate = (either the PCN-lower-rate or PCN-upper-rate). NOTE: The definition reflects the = overall intent of the algorithm rather than its instantaneous behaviour, since = the rate measured at a particular moment depends on the algorithm, its = implementation and the traffic's variance as well as its = rate.>>

 

** bob’s rant

> * Marking is when "current" rate is = "above" a reference rate?

>

> "   o  Admission-marking: the marking = of PCN-packets by a PCN-node to

>        indicate that the PCN-traffic on a link is above the configured-

>        = admissible-rate.

>

>     o  Termination-marking: the = marking of PCN-packets by a PCN-node to

>        indicate that the PCN-traffic on a link is above the configured-

>        = termination-rate.

> "

>

> These marking definitions and other examples hilighted in = magenta in the

> above PDF prejudge marking mechanisms as rate = measurements.

>

> We don't just have marking when the _current_rate is = _above_ the reference

> rate. We can have marking when the _current_ rate is = _below_, or when the

> _past_ rate was _above_.

>

> The configured rates are parameters of a (to be defined) mechanism. These

> mechanisms will not have to mark packets when the rate is = above these

> configured rates. That depends on the = mechanism.

>

> This sounds picky, but it's actually a big rant I have = about all this

> loose

> discussion of rate (yes, the issue of what rate means is = mentioned in the

> draft, but we need to be careful about such sloppy usage). = IMHO, it's

> important to scale our conception of time down to = inter-arrival times, to

> be precise. Then the rate is packet size/interarrival time. Therefore seen

> at a small enough timescale, rate might be varying rapidly = above and below

> the configured rate.

>

> A marking mechanism could be implemented by a virtual queue = rather than a

> rate measurement. When the offered instantaneous rate has = been below the

> configured-admission-rate for many packets (perhaps = hundreds), marking

> will

> and should still occur,... if the virtual queue is still = above a marking

> threshold even if it is emptying rather than filling. This = can be a

> deliberate design choice that says we still want admission = marking when

> there has been recent overload to allow time for the = control loop to work.

> It ensures a greater safety margin is automatically created = by the marking

> mechanism when recent traffic had higher variance. This was = the marking

> algorithm that was most studied and simulated in CL-PHB = draft.

 

 

 

=00 ------_=_NextPart_001_01C7FEB9.6C585C1C-- --===============1071279160== 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://www1.ietf.org/mailman/listinfo/pcn --===============1071279160==-- From pcn-bounces@ietf.org Mon Sep 24 10:53:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZpJS-000509-SC; Mon, 24 Sep 2007 10:53:30 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IZpJR-0004zz-BW for pcn-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 10:53:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZpJQ-0004wS-OI for pcn@ietf.org; Mon, 24 Sep 2007 10:53:29 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZpJP-0003Mg-P7 for pcn@ietf.org; Mon, 24 Sep 2007 10:53:28 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 15:53:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN architecture, revised sub-section on probing Date: Mon, 24 Sep 2007 15:53:24 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC4FF@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1C0DE7C4@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture, revised sub-section on probing Thread-Index: AcfaCZ+BOedo9lzYRa+g2kHgUi9IgAggHadAAQwNp+A= From: To: X-OriginalArrivalTime: 24 Sep 2007 14:53:26.0903 (UTC) FILETIME=[A9C5C070:01C7FEBA] X-Spam-Score: 0.0 (/) X-Scan-Signature: dd9ffe26482d533f4d1fa531728a7327 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1817782502==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1817782502== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FEBA.A86DC25D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FEBA.A86DC25D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Ruediger =20 I'm not sure from your email whether you think that any changes or additions are needed to the text in the draft, or whether it's ok. Please let me know if you think something needs changing =20 Thanks! phil=20 =20 -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: 19 September 2007 08:24 To: Eardley,PL,Philip,CXR9 R Cc: pcn@ietf.org Subject: RE: [PCN] PCN architecture, revised sub-section on probing =20 Phil, =20 my views on the subject: =20 - the discussion on the decision when to apply probing misses one important aspect, at least if=20 you look at a single domain: probing is only required if any pre-congestion occurs within this=20 domain. If there's no pre congested link within a domain, no probing is required within this=20 domain.=20 =20 - given that probing is only applied within a domain, if there's pre-congestion on any link, then=20 the only purpose of probing is to find out, whether traffic from the particular ingress to a=20 desired egress would contribute to this pre-congestion. The probing flow then should be=20 designed to ensure that packets of the probing flow are marked (and if interpretation is=20 to be as simple as possible: marked probing packets mean no admission).=20 =20 - If there's no flow between an ingress and an egress and ECMP is operational within a=20 domain, the ingress may have to signal its intention to probe to an egress. =20 I'm not sure whether a useful probing mechanism is easy to develop an therefore support=20 your proposal to regard probing as optional (at least in the single domain case). =20 Regards, =20 Ruediger =20 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Thursday, August 09, 2007 12:15 AM To: pcn@ietf.org Subject: [PCN] PCN architecture, revised sub-section on probing This is to flag up that I wrote a revised sub-section (in Section 5, Detailed functional architecture) about probing. to reflect (hopefully!) some other discussion we had on the list in july.=20 =20 5.5. Probing functions =20 Probing functions are optional, and can be used for admission control. A PCN-ingress-node generates and sends probe packets in order to test the pre-congestion level. Probing is useful or even essential under the following conditions: =20 o when an ingress-egress-aggregate carries no traffic (or too little traffic for the PCN-egress-node to accurately make the "measurements of PCN-traffic" that are required for an admission decision). It may be that the traffic levels on other ingress- egress-aggregates are so high that a new flow shouldn't be admitted on the 'empty' ingress-egress-aggregate. Probing is useful to check this. =20 o in the presence of multipath routing (ECMP) between the PCN- boundary-nodes, when some paths are pre-congested there may be other paths which aren't pre-congested. Probing is useful to determine whether the new flow would follow a path that isn't pre- congested and hence can be admitted. =20 Probe packets may be simple data addressed to the PCN-egress-node and require no protocol standardisation, although there will be best practice for their number, size and rate. There are two possibilities for how probing is triggered: =20 o the PCN-egress-node requests (signals) the PCN-ingress-node to generate probe traffic =20 o if the PCN-ingress-node knows which PCN-egress-node is associated with the destination address in the admission request, then the PCN-ingress-node could know it has no reservation with that PCN- egress-node and unilaterally start probing. =20 The probing functions are: =20 o Make decision that probing is needed =20 o (if required) Communicate the request that probing is needed - the PCN-egress-node signals to the PCN-ingress-node that probe traffic is needed =20 o Generate probe traffic - the PCN-ingress-node generates the probe traffic. The appropriate number (or rate) of probe packets will depend on the PCN-marking algorithm; for example an excess-rate- marking algorithm generates fewer PCN-marks than a threshold- marking algorithm. =20 o Forward probe packets - as far as PCN-interior-nodes are concerned, probe packets must be handled the same as (ordinary data) PCN-packets. =20 o Consume probe packets - the PCN-egress-node consumes probe packets to ensure that they don't travel beyond the PCN-domain. =20 ------_=_NextPart_001_01C7FEBA.A86DC25D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Ruediger

 

I’m not sure from your email = whether you think that any changes or additions are needed to the text in the = draft, or whether it’s ok. Please let me know if you think something needs = changing

 

Thanks!

phil

 

-----Original Message-----
From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: 19 September 2007 = 08:24
To: = Eardley,PL,Philip,CXR9 R
Cc: pcn@ietf.org
Subject: RE: [PCN] PCN architecture, revised sub-section on probing

 

Phil,

 

my views on the = subject:

 

- the discussion on = the decision when to apply probing misses one important aspect, at least if =

  you look at a single domain: probing is only required if any pre-congestion occurs within this =

  domain. If there's no pre = congested link within a domain, no probing is required within this =

  = domain. 

 

- given that probing is only = applied within a domain, if there's pre-congestion on any link, then =

  the only purpose of = probing is to find out, whether traffic from the particular ingress to a =

  desired egress would = contribute to this pre-congestion. The probing flow then should = be 

  designed to ensure that = packets of the probing flow are marked (and if interpretation is =

  to be as simple as = possible: marked probing packets mean no admission).

 

- If there's no flow between an = ingress and an egress and ECMP is operational within a

  domain, the ingress may have = to signal its intention to probe to an egress.

 

I'm not sure whether a useful = probing mechanism is easy to develop an therefore support =

your proposal to regard probing as optional (at least in the single domain case).

 

Regards,

 

Ruediger

 

 -----Original = Message-----
From: = philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Thursday, August = 09, 2007 12:15 AM
To: pcn@ietf.org
Subject: [PCN] PCN = architecture, revised sub-section on probing

This is to flag up that I wrote a revised sub-section (in = Section 5, Detailed functional architecture) about probing. to reflect (hopefully!) = some other discussion we had on the list in july.

 

5.5.  Probing functions

 

   Probing functions are optional, and can be used for admission

   control.  A PCN-ingress-node generates and = sends probe packets in

   order to test the pre-congestion level.  = Probing is useful or even

   essential under the following = conditions:

 

   o  when an ingress-egress-aggregate carries no traffic (or too little

      traffic for the PCN-egress-node = to accurately make the

      "measurements of = PCN-traffic" that are required for an admission

      decision).  It may be that = the traffic levels on other ingress-

      egress-aggregates are so high = that a new flow shouldn't be

      admitted on the 'empty' ingress-egress-aggregate.  Probing is

      useful to check = this.

 

   o  in the presence of multipath routing (ECMP) between the PCN-

      boundary-nodes, when some paths = are pre-congested there may be

      other paths which aren't pre-congested.  Probing is useful to

      determine whether the new flow = would follow a path that isn't pre-

      congested and hence can be = admitted.

 

   Probe packets may be simple data addressed to the = PCN-egress-node and

   require no protocol standardisation, although there = will be best

   practice for their number, size and rate.  = There are two

   possibilities for how probing is = triggered:

 

   o  the PCN-egress-node requests (signals) the PCN-ingress-node to

      generate probe = traffic

 

   o  if the PCN-ingress-node knows which PCN-egress-node is associated

      with the destination address in = the admission request, then the

      PCN-ingress-node could know it = has no reservation with that PCN-

      egress-node and unilaterally = start probing.

 

   The probing functions are:

 

   o  Make decision that probing is = needed

 

   o  (if required) Communicate the request that = probing is needed - the

      PCN-egress-node signals to the PCN-ingress-node that probe traffic

      is needed

 

   o  Generate probe traffic - the = PCN-ingress-node generates the probe

      traffic.  The appropriate = number (or rate) of probe packets will

      depend on the PCN-marking = algorithm; for example an excess-rate-

      marking algorithm generates fewer PCN-marks than a threshold-

      marking = algorithm.

 

   o  Forward probe packets - as far as PCN-interior-nodes are

      concerned, probe packets must be = handled the same as (ordinary

      data) = PCN-packets.

 

   o  Consume probe packets - the PCN-egress-node consumes probe packets

      to ensure that they don't travel = beyond the PCN-domain.

 

=00 ------_=_NextPart_001_01C7FEBA.A86DC25D-- --===============1817782502== 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://www1.ietf.org/mailman/listinfo/pcn --===============1817782502==-- From pcn-bounces@ietf.org Mon Sep 24 13:51:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZs4v-0005PM-TG; Mon, 24 Sep 2007 13:50:41 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IZs4u-0005EJ-0x for pcn-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 13:50:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZs4t-0005E5-DK for pcn@ietf.org; Mon, 24 Sep 2007 13:50:39 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZs4s-0001Oh-Jw for pcn@ietf.org; Mon, 24 Sep 2007 13:50:39 -0400 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 l8OHoWw28636; Mon, 24 Sep 2007 17:50:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds rate" Date: Mon, 24 Sep 2007 13:50:26 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB64651249BE1B@zcarhxm1.corp.nortel.com> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC4FE@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture, use of phrases like "exceeds rate" Thread-Index: AcfZ4sD4MX/wup2KTYmWXZzVtqCqDAgo1F2AACdxudAA5RLFIAAGu8ww References: <9671A92C3C8B5744BC97F855F7CB646512377342@zcarhxm1.corp.nortel.com> <75A199C5D243C741BF3D3F1EBCEF9BA5019DC4FE@E03MVZ1-UKDY.domain1.systemhost.net> From: "Jozef Babiarz" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 89a1e35b8763fad584ad8e0b42e66144 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0804064804==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0804064804== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FED3.63E74F7D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FED3.63E74F7D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil, I'm OK with rate.=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: September 24, 2007 10:45 AM To: Babiarz, Jozef (CAR:0S03); Ruediger.Geib@t-systems.com Cc: pcn@ietf.org Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds rate" =20 Joe =20 The change of the word 'algorithm' to 'marking behaviour' is ok with me. Yes, we will have to decide what level of detail to standardise the marking behaviour, but we don't have to decide that in this document.=20 =20 I'd prefer not to change 'rate' to 'threshold' at the moment. Since in a token bucket or virtual queue implementation it does correspond to a rate. Also, would prefer not to re-open the terminology rat-hole.=20 =20 Thanks phil =20 -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: 20 September 2007 02:55 To: Geib, Ruediger; Eardley,PL,Philip,CXR9 R Cc: pcn@ietf.org Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds rate" =20 Phil and others, since Ruediger email brought this to my attention. I have the following comments. =20 I think we should change the word "algorithm" to "marking behaviour" and "rate" to "threshold". At least I believe that we should avoid specifying a specific algorithm but just define the behaviour of the algorithm. This would allow vendors to choose an algorithm that they believe gives best results. So would propose the following. =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: September 19, 2007 2:31 AM To: philip.eardley@bt.com Cc: pcn@ietf.org Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds rate" =20 Phil, =20 with a small delay of 5 weeks (but no one else reacted yet?): both, description and definition proposed by you below are allright with me. =20 Regards, =20 Ruediger =20 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Wednesday, August 08, 2007 7:37 PM To: pcn@ietf.org Subject: [PCN] PCN architecture, use of phrases like "exceeds rate" I wrote a new / replacement para in the intro - to try to overcome bob's rant - which complained about using phrases like "do marking when the current rate exceeds a reference rate" [copied at end] - whilst still giving the innocent reader (if such a person exists) a sporting chance of understanding what it's all about: =20 <> =20 I know the last bit mentions rate - hopefully it's ok by relating it to the overall system performance, rather than how each link does marking. I'm not sure whether "*roughly*" is really necessary or whether you think i cheated.=20 =20 I also added to the definitions for example: <> =20 ** bob's rant > * Marking is when "current" rate is "above" a reference rate? >=20 > " o Admission-marking: the marking of PCN-packets by a PCN-node to > indicate that the PCN-traffic on a link is above the configured- > admissible-rate. >=20 > o Termination-marking: the marking of PCN-packets by a PCN-node to > indicate that the PCN-traffic on a link is above the configured- > termination-rate. > " >=20 > These marking definitions and other examples hilighted in magenta in the > above PDF prejudge marking mechanisms as rate measurements. >=20 > We don't just have marking when the _current_rate is _above_ the reference > rate. We can have marking when the _current_ rate is _below_, or when the > _past_ rate was _above_. >=20 > The configured rates are parameters of a (to be defined) mechanism. These > mechanisms will not have to mark packets when the rate is above these > configured rates. That depends on the mechanism. >=20 > This sounds picky, but it's actually a big rant I have about all this > loose > discussion of rate (yes, the issue of what rate means is mentioned in the > draft, but we need to be careful about such sloppy usage). IMHO, it's > important to scale our conception of time down to inter-arrival times, to > be precise. Then the rate is packet size/interarrival time. Therefore seen > at a small enough timescale, rate might be varying rapidly above and below > the configured rate. >=20 > A marking mechanism could be implemented by a virtual queue rather than a > rate measurement. When the offered instantaneous rate has been below the > configured-admission-rate for many packets (perhaps hundreds), marking > will > and should still occur,... if the virtual queue is still above a marking > threshold even if it is emptying rather than filling. This can be a > deliberate design choice that says we still want admission marking when > there has been recent overload to allow time for the control loop to work. > It ensures a greater safety margin is automatically created by the marking > mechanism when recent traffic had higher variance. This was the marking > algorithm that was most studied and simulated in CL-PHB draft. =20 =20 =20 ------_=_NextPart_001_01C7FED3.63E74F7D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Phil, I’m OK with rate. =

 

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

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: September 24, 2007 = 10:45 AM
To: Babiarz, Jozef (CAR:0S03); Ruediger.Geib@t-systems.com
Cc: pcn@ietf.org
Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds = rate"

 

Joe=

 

The change of = the word ‘algorithm’ to ‘marking behaviour’ is ok with = me. Yes, we will have to decide what level of detail to standardise the marking behaviour, but we don’t have to decide that in this document. =

 

I’d prefer = not to change ‘rate’ to ‘threshold’ at the moment. = Since in a token bucket or virtual queue implementation it does correspond to a = rate. Also, would prefer not to re-open the terminology rat-hole. =

 

Thanks

phil

 

-----Original Message-----
From: Jozef Babiarz = [mailto:babiarz@nortel.com]
Sent: 20 September 2007 = 02:55
To: Geib, Ruediger; Eardley,PL,Philip,CXR9 R
Cc: pcn@ietf.org
Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds = rate"

 

Phil and others, since Ruediger = email brought this to my attention. I have the following = comments.

 

I think we should change the word “algorithm” to “marking behaviour” and “rate” to “threshold”. At least I believe that = we should avoid specifying a specific algorithm but just define the = behaviour of the algorithm. This would allow vendors to choose an algorithm that they believe gives best results. So would propose the = following.

  

 

<<Two traffic thresholds, a = PCN-lower-threshold and a PCN-upper-threshold, can be associated with each link of the = PCN-domain. Each traffic threshold has a marking behaviour(specified in another = document) that determines how and when PCN-packets are marked, and how the = markings are encoded in packet headers. PCN-egress-nodes make measurements of the = packet markings and send information as necessary to the nodes that make the = decision about which PCN-flow(s) to accept/reject or terminate, based on this information. Another document will describe decision-making behaviour. = Overall the aim is to enable PCN-nodes to give an "early warning" of potential congestion before there is any significant build-up of = PCN-packets in the queue; the admission control mechanism limits the PCN-traffic on = each link to *roughly* its PCN-lower- threshold and the flow termination mechanism = limits the PCN-traffic on each link to *roughly* its = PCN-upper-threshold.>>

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

From: Geib, = Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: September 19, 2007 = 2:31 AM
To: = philip.eardley@bt.com
Cc: pcn@ietf.org
Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds = rate"

 

Phil,

 

with a small = delay of 5 weeks (but no one else reacted = yet?): both, description and definition proposed by you below are allright with = me.

 

Regards,

 

Ruediger

 

-----Original Message-----
From: = philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Wednesday, August = 08, 2007 7:37 PM
To: pcn@ietf.org
Subject: [PCN] PCN = architecture, use of phrases like "exceeds rate"

I wrote a new / replacement para in the intro = - to try to overcome bob’s rant - which complained about using phrases like “do marking when the current rate exceeds a reference rate” = [copied at end] - whilst still giving the innocent reader (if such a person = exists) a sporting chance of understanding what it's all = about:

 

<<Two rates, a PCN-lower-rate and a PCN-upper-rate, can be associated with each link of the PCN-domain. Each = rate is used by an algorithm (specified in another document) that determines = how and when a number of PCN-packets are marked, and how the markings are = encoded in packet headers. PCN-egress-nodes make measurements of the packet = markings and send information as necessary to the nodes that make the decision about = which PCN-flows to accept/reject or terminate, based on this information. = Another document will describe decision-making algorithms. Overall the aim is to = enable PCN-nodes to give an "early warning" of potential congestion = before there is any significant build-up of PCN-packets in the queue; the = admission control mechanism limits the PCN-traffic on each link to *roughly* its PCN-lower-rate and the flow termination mechanism limits the PCN-traffic = on each link to *roughly* its = PCN-upper-rate.>>

 

I know the last bit mentions rate - hopefully = it's ok by relating it to the overall system performance, rather than how each = link does marking. I'm not sure whether "*roughly*" is really = necessary or whether you think i cheated.

 

I also added to the definitions for = example:

<<Threshold-marking: a PCN-marking = algorithm such that all PCN-traffic is marked if the PCN-traffic exceeds a = particular rate (either the PCN-lower-rate or PCN-upper-rate). NOTE: The definition reflects the overall intent of the algorithm rather than its = instantaneous behaviour, since the rate measured at a particular moment depends on the algorithm, its implementation and the traffic's variance as well as its rate.>>

 

** bob’s = rant

> * Marking is when "current" = rate is "above" a reference rate?

>

> "   o  = Admission-marking: the marking of PCN-packets by a PCN-node to

>       = indicate that the PCN-traffic on a link is above the = configured-

>       = admissible-rate.

>

>     o  Termination-marking: the marking of PCN-packets by a PCN-node = to

>       = indicate that the PCN-traffic on a link is above the = configured-

>       = termination-rate.

> "

>

> These marking definitions and other = examples hilighted in magenta in the

> above PDF prejudge marking mechanisms as = rate measurements.

>

> We don't just have marking when the = _current_rate is _above_ the reference

> rate. We can have marking when the = _current_ rate is _below_, or when the

> _past_ rate was = _above_.

>

> The configured rates are parameters of a = (to be defined) mechanism. These

> mechanisms will not have to mark packets = when the rate is above these

> configured rates. That depends on the = mechanism.

>

> This sounds picky, but it's actually a = big rant I have about all this

> loose

> discussion of rate (yes, the issue of = what rate means is mentioned in the

> draft, but we need to be careful about = such sloppy usage). IMHO, it's

> important to scale our conception of = time down to inter-arrival times, to

> be precise. Then the rate is packet size/interarrival time. Therefore seen

> at a small enough timescale, rate might = be varying rapidly above and below

> the configured = rate.

>

> A marking mechanism could be implemented = by a virtual queue rather than a

> rate measurement. When the offered = instantaneous rate has been below the

> configured-admission-rate for many = packets (perhaps hundreds), marking

> will

> and should still occur,... if the = virtual queue is still above a marking

> threshold even if it is emptying rather = than filling. This can be a

> deliberate design choice that says we = still want admission marking when

> there has been recent overload to allow = time for the control loop to work.

> It ensures a greater safety margin is automatically created by the marking

> mechanism when recent traffic had higher variance. This was the marking

> algorithm that was most studied and = simulated in CL-PHB draft.

 

 

 

------_=_NextPart_001_01C7FED3.63E74F7D-- --===============0804064804== 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://www1.ietf.org/mailman/listinfo/pcn --===============0804064804==-- From pcn-bounces@ietf.org Wed Sep 26 02:32:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaQRO-0005aj-7e; Wed, 26 Sep 2007 02:32:10 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IaQRN-0005ac-8X for pcn-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 02:32:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaQRM-0005ZV-Rk for pcn@ietf.org; Wed, 26 Sep 2007 02:32:08 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaQRF-0000Aa-OT for pcn@ietf.org; Wed, 26 Sep 2007 02:32:08 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 26 Sep 2007 08:31:42 +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); Wed, 26 Sep 2007 08:31:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN architecture, revised sub-section on probing Date: Wed, 26 Sep 2007 08:31:41 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C0DE80A@S4DE8PSAANK.mitte.t-com.de> In-reply-to: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC4FF@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture, revised sub-section on probing Thread-Index: AcfaCZ+BOedo9lzYRa+g2kHgUi9IgAggHadAAQwNp+AAUwip8A== From: "Geib, Ruediger" To: X-OriginalArrivalTime: 26 Sep 2007 06:31:41.0705 (UTC) FILETIME=[E6809790:01C80006] X-Spam-Score: -1.0 (-) X-Scan-Signature: 708bdb947b83e88c58fd603ed07f3c7a Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1569370654==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1569370654== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80006.E6249BF5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80006.E6249BF5 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Phil, =20 the views I express should be added to the description on probing.=20 =20 Regards, =20 Ruediger -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Monday, September 24, 2007 4:53 PM To: Geib, Rudiger Cc: pcn@ietf.org Subject: RE: [PCN] PCN architecture, revised sub-section on probing Thanks Ruediger =20 I'm not sure from your email whether you think that any changes or additions are needed to the text in the draft, or whether it's ok. Please let me know if you think something needs changing =20 Thanks! phil=20 =20 -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: 19 September 2007 08:24 To: Eardley,PL,Philip,CXR9 R Cc: pcn@ietf.org Subject: RE: [PCN] PCN architecture, revised sub-section on probing =20 Phil, =20 my views on the subject: =20 - the discussion on the decision when to apply probing misses one important aspect, at least if=20 you look at a single domain: probing is only required if any pre-congestion occurs within this=20 domain. If there's no pre congested link within a domain, no probing is required within this=20 domain.=20 =20 - given that probing is only applied within a domain, if there's pre-congestion on any link, then=20 the only purpose of probing is to find out, whether traffic from the particular ingress to a=20 desired egress would contribute to this pre-congestion. The probing flow then should be=20 designed to ensure that packets of the probing flow are marked (and if interpretation is=20 to be as simple as possible: marked probing packets mean no admission).=20 =20 - If there's no flow between an ingress and an egress and ECMP is operational within a=20 domain, the ingress may have to signal its intention to probe to an egress. =20 I'm not sure whether a useful probing mechanism is easy to develop an therefore support=20 your proposal to regard probing as optional (at least in the single domain case). =20 Regards, =20 Ruediger =20 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Thursday, August 09, 2007 12:15 AM To: pcn@ietf.org Subject: [PCN] PCN architecture, revised sub-section on probing This is to flag up that I wrote a revised sub-section (in Section 5, Detailed functional architecture) about probing. to reflect (hopefully!) some other discussion we had on the list in july.=20 =20 5.5. Probing functions =20 Probing functions are optional, and can be used for admission control. A PCN-ingress-node generates and sends probe packets in order to test the pre-congestion level. Probing is useful or even essential under the following conditions: =20 o when an ingress-egress-aggregate carries no traffic (or too little traffic for the PCN-egress-node to accurately make the "measurements of PCN-traffic" that are required for an admission decision). It may be that the traffic levels on other ingress- egress-aggregates are so high that a new flow shouldn't be admitted on the 'empty' ingress-egress-aggregate. Probing is useful to check this. =20 o in the presence of multipath routing (ECMP) between the PCN- boundary-nodes, when some paths are pre-congested there may be other paths which aren't pre-congested. Probing is useful to determine whether the new flow would follow a path that isn't pre- congested and hence can be admitted. =20 Probe packets may be simple data addressed to the PCN-egress-node and require no protocol standardisation, although there will be best practice for their number, size and rate. There are two possibilities for how probing is triggered: =20 o the PCN-egress-node requests (signals) the PCN-ingress-node to generate probe traffic =20 o if the PCN-ingress-node knows which PCN-egress-node is associated with the destination address in the admission request, then the PCN-ingress-node could know it has no reservation with that PCN- egress-node and unilaterally start probing. =20 The probing functions are: =20 o Make decision that probing is needed =20 o (if required) Communicate the request that probing is needed - the PCN-egress-node signals to the PCN-ingress-node that probe traffic is needed =20 o Generate probe traffic - the PCN-ingress-node generates the probe traffic. The appropriate number (or rate) of probe packets will depend on the PCN-marking algorithm; for example an excess-rate- marking algorithm generates fewer PCN-marks than a threshold- marking algorithm. =20 o Forward probe packets - as far as PCN-interior-nodes are concerned, probe packets must be handled the same as (ordinary data) PCN-packets. =20 o Consume probe packets - the PCN-egress-node consumes probe packets to ensure that they don't travel beyond the PCN-domain. =20 ------_=_NextPart_001_01C80006.E6249BF5 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi=20 Phil,
 
the=20 views I express should be added to the description on probing.=20
 
Regards,
 
Ruediger
-----Original Message-----
From: = philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: Monday, September 24, = 2007 4:53=20 PM
To: Geib, Rüdiger
Cc: = pcn@ietf.org
Subject:=20 RE: [PCN] PCN architecture, revised sub-section on=20 probing

Thanks=20 Ruediger

 

I’m = not sure from=20 your email whether you think that any changes or additions are needed = to the=20 text in the draft, or whether it’s ok. Please let me know if you = think=20 something needs changing

 

Thanks!

phil=20

 

-----Original=20 Message-----
From: = Geib,=20 Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: 19 September 2007 = 08:24
To: Eardley,PL,Philip,CXR9 = R
Cc: pcn@ietf.org
Subject: RE: [PCN] PCN = architecture,=20 revised sub-section on probing

 

Phil,

 

my views on = the=20 subject:

 

- the = discussion on=20 the decision when to apply probing misses one important aspect, = at least=20 if

  you = look at a=20 single domain: probing is only required if any pre-congestion occurs = within=20 this

  = domain. If=20 there's no pre congested link within a domain, no probing is required = within=20 this

 =20 domain. 

 

- given = that probing=20 is only applied within a domain, if there's pre-congestion on any = link, then=20

  the only=20 purpose of probing is to find out, whether traffic from the particular = ingress=20 to a

  = desired egress=20 would contribute to this pre-congestion. The probing flow then = should=20 be 

  = designed to=20 ensure that packets of the probing flow are marked (and if=20 interpretation is

  = to be as=20 simple as possible: marked probing packets mean no admission).=20

 

- If = there's no flow=20 between an ingress and an egress and ECMP is operational within a=20

  = domain, the=20 ingress may have to signal its intention to probe to an=20 egress.

 

I'm not = sure whether=20 a useful probing mechanism is easy to develop an therefore = support=20

your = proposal to=20 regard probing as optional (at least in the single domain=20 case).

 

Regards,

 

Ruediger

 

 -----Original=20 Message-----
From:=20 philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Thursday, August 09, 2007 = 12:15=20 AM
To:=20 pcn@ietf.org
Subject: [PCN]=20 PCN architecture, revised sub-section on = probing

This is to flag up that I wrote a revised=20 sub-section (in Section 5, Detailed functional architecture) about = probing.=20 to reflect (hopefully!) some other discussion we had on the list in = july.=20

 

5.5.  Probing = functions

 

   Probing functions are = optional, and can=20 be used for admission

   control.  A = PCN-ingress-node=20 generates and sends probe packets in

   order to test the = pre-congestion=20 level.  Probing is useful or even

   essential under the following = conditions:

 

   o  when an=20 ingress-egress-aggregate carries no traffic (or too = little

      traffic for = the=20 PCN-egress-node to accurately make the

      = "measurements of=20 PCN-traffic" that are required for an admission

      = decision).  It=20 may be that the traffic levels on other ingress-

      = egress-aggregates are=20 so high that a new flow shouldn't be

      admitted on = the=20 'empty' ingress-egress-aggregate.  Probing is

      useful to = check=20 this.

 

   o  in the presence of = multipath=20 routing (ECMP) between the PCN-

      = boundary-nodes, when=20 some paths are pre-congested there may be

      other paths = which=20 aren't pre-congested.  Probing is useful to

      determine = whether the=20 new flow would follow a path that isn't pre-

      congested = and hence=20 can be admitted.

 

   Probe packets may be simple = data=20 addressed to the PCN-egress-node and

   require no protocol = standardisation,=20 although there will be best

   practice for their number, = size and=20 rate.  There are two

   possibilities for how probing = is=20 triggered:

 

   o  the PCN-egress-node = requests=20 (signals) the PCN-ingress-node to

      generate = probe=20 traffic

 

   o  if the = PCN-ingress-node knows=20 which PCN-egress-node is associated

      with the = destination=20 address in the admission request, then the

      = PCN-ingress-node=20 could know it has no reservation with that PCN-

      egress-node = and=20 unilaterally start probing.

 

   The probing functions=20 are:

 

   o  Make decision that = probing is=20 needed

 

   o  (if required) = Communicate the=20 request that probing is needed - the

      = PCN-egress-node=20 signals to the PCN-ingress-node that probe traffic

      is=20 needed

 

   o  Generate probe = traffic - the=20 PCN-ingress-node generates the probe

      = traffic.  The=20 appropriate number (or rate) of probe packets will

      depend on = the=20 PCN-marking algorithm; for example an excess-rate-

      marking = algorithm=20 generates fewer PCN-marks than a threshold-

      marking=20 algorithm.

 

   o  Forward probe packets = - as far=20 as PCN-interior-nodes are

      concerned, = probe=20 packets must be handled the same as (ordinary

      data)=20 PCN-packets.

 

   o  Consume probe packets = - the=20 PCN-egress-node consumes probe packets

      to ensure = that they=20 don't travel beyond the PCN-domain.

 

------_=_NextPart_001_01C80006.E6249BF5-- --===============1569370654== 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://www1.ietf.org/mailman/listinfo/pcn --===============1569370654==-- From pcn-bounces@ietf.org Fri Sep 28 13:30:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbJfT-0002qd-00; Fri, 28 Sep 2007 13:30:23 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IbJfR-0002qT-O2 for pcn-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 13:30:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbJfR-0002qL-Bh for pcn@ietf.org; Fri, 28 Sep 2007 13:30:21 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbJfQ-0006zY-Nl for pcn@ietf.org; Fri, 28 Sep 2007 13:30:21 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 18:30:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN architecture, revised sub-section on probing Date: Fri, 28 Sep 2007 18:30:19 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC516@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1C0DE80A@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture, revised sub-section on probing Thread-Index: AcfaCZ+BOedo9lzYRa+g2kHgUi9IgAggHadAAQwNp+AAUwip8AB6vy9A From: To: X-OriginalArrivalTime: 28 Sep 2007 17:30:19.0994 (UTC) FILETIME=[3E1073A0:01C801F5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8e9fbe727bc2159b431d624c595c1eab Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0482562369==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0482562369== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C801F5.3D8EC435" This is a multi-part message in MIME format. ------_=_NextPart_001_01C801F5.3D8EC435 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ruediger, =20 Follow-ups (further questions!) in-line on each of your 3 points=20 =20 [RG] - the discussion on the decision when to apply probing misses one important aspect, at least if=20 you look at a single domain: probing is only required if any pre-congestion occurs within this=20 domain. If there's no pre congested link within a domain, no probing is required within this=20 domain.=20 =20 [phil] I slightly re-phrased the first bullet (the second bullet is unaltered), so the text now says: =20 Probing is useful or even essential under the following conditions: =20 o when an ingress-egress-aggregate carries no traffic (or too little traffic for the PCN-egress-node to accurately make the "measurements of PCN-traffic" that are required for an admission decision), but the traffic levels on other ingress-egress-aggregates are so high that a new flow shouldn't be admitted on the 'empty' ingress-egress-aggregate. Probing is useful to check this. o in the presence of multipath routing (ECMP) between the PCN-boundary-nodes, when some paths are pre-congested there may be other paths which aren't pre-congested. Probing is useful to determine whether the new flow would follow a path that isn't pre-congested and hence can be admitted. =20 I think what's written implies that it may not always be possible to know whether there's any (relevant) pre-congestion or none - so there's an argument for probing in such times of doubt to discover what the situation really is (if it turns out that there isn't any pre-congestion then, as you say, in some ways the probing hasn't proved to be useful). I think the tweaked text above captures this, but please suggest any mods to make it clearer (or disagree!) =20 =20 [RG} - given that probing is only applied within a domain, if there's pre-congestion on any link, then=20 the only purpose of probing is to find out, whether traffic from the particular ingress to a=20 desired egress would contribute to this pre-congestion. The probing flow then should be=20 designed to ensure that packets of the probing flow are marked (and if interpretation is=20 to be as simple as possible: marked probing packets mean no admission).=20 =20 [phil] I'm not quite sure what you mean by "designed to ensure that packets of the probing flow are marked". The section currently says that probe pkts are handled in the same way as (ordinary data) PCN-pkts [*]. I think you may be suggesting something different, that probing pkts should be preferentially PCN-marked?=20 [*] incidentally, I'll tweak the text to add something like "in terms of pkt scheduling/forwarding and PCN-marking" ; for pkt dropping it may be arguable you should preferentially drop probes to ease DoS worries? =20 Re: "interpretation is to be as simple as possible: marked probing packets mean no admission" - I think this is too solution-space for this Architecture draft (presumably there may be different options, eg block call if the single probe pkt is marked, if at least 2 out of 100 marked, etc) =20 =20 [RG] - If there's no flow between an ingress and an egress and ECMP is operational within a=20 domain, the ingress may have to signal its intention to probe to an egress. =20 [phil] could you explain your reference to ECMP please? At the moment the doc says that "(if required) Communicate the request that probing is needed - the PCN-egress-node signals to the PCN-ingress-node that probe traffic is needed". But you're suggesting there are particular circumstances when something is needed in the opposite direction? =20 =20 Thanks! phil =20 =20 ------_=_NextPart_001_01C801F5.3D8EC435 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ruediger,

 

Follow-ups (further questions!) = in-line on each of your 3 points

 

[RG] - the discussion on the decision when to apply probing = misses one important aspect, at least if

  you look at a single domain: probing is only required if any pre-congestion occurs within this =

  domain. If there's no pre = congested link within a domain, no probing is required within this =

  = domain. 

 

[phil] I slightly re-phrased the = first bullet (the second bullet is unaltered), so the text now = says:

 

Probing is useful or even essential under the following = conditions:

 

   o  when an ingress-egress-aggregate carries no traffic (or too little traffic for the PCN-egress-node to accurately = make the "measurements of PCN-traffic" that are required for an admission decision), but = the traffic levels on other ingress-egress-aggregates are so high that a new = flow shouldn't be admitted on the 'empty' ingress-egress-aggregate.  = Probing is useful to check this.

   o  in the presence of multipath routing (ECMP) between the PCN-boundary-nodes, when some paths are pre-congested there = may be other paths which aren't pre-congested.  Probing is useful to determine = whether the new flow would follow a path that isn't pre-congested and hence can = be admitted.

 

I think what’s written = implies that it may not always be possible to know whether there’s any (relevant) = pre-congestion or none – so there’s an argument for probing in such times = of doubt to discover what the situation really is (if it turns out that there = isn’t any pre-congestion then, as you say, in some ways the probing = hasn’t proved to be useful). I think the tweaked text above captures this, but please = suggest any mods to make it clearer (or disagree!)

 

 

[RG} - given that probing is only applied within a domain, if = there's pre-congestion on any link, then

  the only purpose of = probing is to find out, whether traffic from the particular ingress to a =

  desired egress would = contribute to this pre-congestion. The probing flow then should = be 

  designed to ensure that = packets of the probing flow are marked (and if interpretation is =

  to be as simple as = possible: marked probing packets mean no admission).

 

[phil] I’m not quite sure = what you mean by “designed to = ensure that packets of the probing flow are marked”. The section = currently says that probe pkts are handled in the same way as (ordinary data) PCN-pkts = [*]. I think you may be suggesting something different, that probing pkts should be preferentially PCN-marked?

[*] incidentally, I’ll tweak = the text to add something like “in terms of pkt scheduling/forwarding = and PCN-marking” ; for pkt dropping it may be arguable you should preferentially drop probes to ease DoS worries?

 

Re: “interpretation is = to be as simple as possible: marked probing packets mean no = admission” – I think this is too solution-space for this Architecture draft = (presumably there may be different options, eg block call if the single probe pkt is = marked, if at least 2 out of 100 marked, etc)

 

 

[RG] - If there's no flow between = an ingress and an egress and ECMP is operational within a =

  domain, the ingress may have = to signal its intention to probe to an egress.

 

[phil] could you explain your = reference to ECMP please?

At the moment = the doc says that “(if required) Communicate the request = that probing is needed – the PCN-egress-node signals to the = PCN-ingress-node that probe traffic is needed”. But you’re suggesting there = are particular circumstances when something is needed in the opposite = direction?

 

 

Thanks!

phil

 

 

=00 ------_=_NextPart_001_01C801F5.3D8EC435-- --===============0482562369== 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://www1.ietf.org/mailman/listinfo/pcn --===============0482562369==-- From pcn-bounces@ietf.org Fri Sep 28 14:16:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbKNP-0007NI-7Z; Fri, 28 Sep 2007 14:15:47 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IbKNO-0007ND-GA for pcn-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 14:15:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbKNO-0007Gv-6A for pcn@ietf.org; Fri, 28 Sep 2007 14:15:46 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbKNJ-0000dQ-8e for pcn@ietf.org; Fri, 28 Sep 2007 14:15:43 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l8SIFZUO002162 for ; Fri, 28 Sep 2007 13:15:35 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 13:15:35 -0500 Received: from [147.117.169.143] ([147.117.169.143]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 13:15:35 -0500 Subject: RE: [PCN] PCN architecture, revised sub-section on probing From: Steven Blake To: pcn In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC516@E03MVZ1-UKDY.domain1.systemhost.net> References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC516@E03MVZ1-UKDY.domain1.systemhost.net> Content-Type: text/plain Organization: Ericsson IP Infrastructure Date: Fri, 28 Sep 2007 14:15:34 -0400 Message-Id: <1191003334.15202.61.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Sep 2007 18:15:35.0624 (UTC) FILETIME=[90B4B480:01C801FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org If a probe packet for a PCN-managed flow is intended to follow the same ECMP path as the flow, then the probe packet has to look exactly like flow packets in the header fields usually hashed by routers to load split for ECMP: IP source/destination address, TCP/UDP source/destination port; maybe the protocol/next header field as well. If you do this, you are essentially spoofing traffic for the host originating the flow. I'm sure the security review comments for this will make for entertaining reading. At the very least, you need to ensure that there is an *airtight* mechanism for ensuring that the probe traffic can never leak out of the PCN domain, and that no ICMP traffic can be sent back towards the host. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sat Sep 29 02:31:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbVrC-0005iW-U8; Sat, 29 Sep 2007 02:31:18 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IbVrB-0005f7-Lj for pcn-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 02:31:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbVrB-0005do-9g for pcn@ietf.org; Sat, 29 Sep 2007 02:31:17 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbVrA-0001bi-Fl for pcn@ietf.org; Sat, 29 Sep 2007 02:31:17 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8T6V8mU017651; Sat, 29 Sep 2007 09:31:09 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Sep 2007 09:31:08 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Sep 2007 09:31:08 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Sep 2007 09:31:07 +0300 Received: from [192.168.255.2] (essapo-nirac25395.europe.nokia.com [10.162.253.95]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8T6V6EP027791; Sat, 29 Sep 2007 09:31:06 +0300 In-Reply-To: <1191003334.15202.61.camel@neutrino> References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC516@E03MVZ1-UKDY.domain1.systemhost.net> <1191003334.15202.61.camel@neutrino> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [PCN] PCN architecture, revised sub-section on probing Date: Sat, 29 Sep 2007 09:31:03 +0300 To: ext Steven Blake X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 29 Sep 2007 06:31:07.0497 (UTC) FILETIME=[515A1D90:01C80262] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: pcn X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1591200481==" Errors-To: pcn-bounces@ietf.org --===============1591200481== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-21-139382991; protocol="application/pkcs7-signature" --Apple-Mail-21-139382991 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-9-28, at 21:15, ext Steven Blake wrote: > If a probe packet for a PCN-managed flow is intended to follow the > same > ECMP path as the flow, then the probe packet has to look exactly like > flow packets in the header fields usually hashed by routers to load > split for ECMP: IP source/destination address, TCP/UDP > source/destination port; maybe the protocol/next header field as well. > > If you do this, you are essentially spoofing traffic for the host > originating the flow. I'm sure the security review comments for this > will make for entertaining reading. > > At the very least, you need to ensure that there is an *airtight* > mechanism for ensuring that the probe traffic can never leak out of > the > PCN domain, and that no ICMP traffic can be sent back towards the > host. Let me add that probe traffic (other than for supporting ECMP) seems only useful when a domain can go from "no congestion" to "must terminate" through the admission of a very small number of flows. Otherwise, the gradual admission of regular flows can be used to determine whether admission should be terminated. In other words, regular flows can be used to "probe" the domain. I question whether domains that require explicit probing mechanisms fall under the current PCN charter, which focuses on domains that multiplex a sufficient numbers of flows such that stateless, statistical mechanisms are effective. Explicit probing adds a lot of complexity. The idea behind PCN is to add a minimal set of mechanisms to a large and busy DiffServ domain, which would allow this domain to protect the QoS of already-admitted flows in a best-effort sort of way. Meaning that although flow termination should be mostly prevented due to admission stop decisions, there will be no guarantees that no flow will ever be terminated. PCN is also not a mechanism to squeeze the last ounce of utilization out of a domain - sufficient overprovisioning remains a requirement. Because of this, I wonder if PCN needs to support ECMP - which did not come up during the chartering phase - when it looks likely that such support will significantly complicate the solution. Finally, let me say that I'm worried that the WG seems to have settled on a mode of working where all the different proposals will be merged into one. The result is not likely to be a very simple solution. We have ample experience with solutions that have been designed in this manner failing to gain any traction, due to their complexities. I'd like to strongly encourage the WG to instead discuss which of the proposals is the most *simple* one that will fulfill the chartered goals. We'd like the outcome of the first phase of work to be something that people will usefully deploy in some domains. Without demonstrated deployability and use, the need for continued future work on PCN is questionable. Lars --Apple-Mail-21-139382991 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA5MjkwNjMxMDRaMCMGCSqGSIb3DQEJBDEWBBSgSJe+0wlti9bH xYN7/9EqUVNM7zCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAPdNNN9hCllvjjybnDzCyRzWVK1YN89rCVboB2ndUCS2W2IMxpjAB tp1enzjS62jDJBHeOGEHGZt5yVLcEuxQ4jOem+E4QJMn/bwRpuZz698keQshxpQJgwlldCY0uodt 9fuxwf3yp331/aR2b7HCMTRwwPIpVdrIZQd9gvyVkfWwVOfQGk2Qv8L9iQO7kbYAOADAnJpynnx8 UY80llBHHmRwtHIm5AmOLskV/08kYb/B1TM1vq3Qq2xf/QoHjpUHwpIVluUVmWsXtasBPQDfjWuv BgzJPHwO2ggSDiQLzwa+iuMMyXT130mAh/uVVLHHzQFHUl9mld1tSF9k8whJdAAAAAAAAA== --Apple-Mail-21-139382991-- --===============1591200481== 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://www1.ietf.org/mailman/listinfo/pcn --===============1591200481==-- From pcn-bounces@ietf.org Sat Sep 29 05:20:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbYU7-0002HL-HE; Sat, 29 Sep 2007 05:19:39 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IbYU5-0002Fr-Ck for pcn-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 05:19:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbYU5-0002Fi-1z for pcn@ietf.org; Sat, 29 Sep 2007 05:19:37 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbYU4-0006dd-Hd for pcn@ietf.org; Sat, 29 Sep 2007 05:19:36 -0400 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 l8T9JZ03008248; Sat, 29 Sep 2007 11:19:35 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sat, 29 Sep 2007 09:19:34 +0000 To: "Steven Blake" , "pcn" Subject: RE: [PCN] PCN architecture, revised sub-section on probing Date: Sat, 29 Sep 2007 09:19:34 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <1191003334.15202.61.camel@neutrino> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.029 () AWL 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, 29 Sep 2007 11:19:35 +0200 (MEST) X-Spam-Score: 1.8 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Steven Regarding the below comment: > On 9/28/2007, "Steven Blake" wrote: >If a probe packet for a PCN-managed flow is intended to follow the same >ECMP path as the flow, then the probe packet has to look exactly like >flow packets in the header fields usually hashed by routers to load >split for ECMP: IP source/destination address, TCP/UDP >source/destination port; maybe the protocol/next header field as well. > >If you do this, you are essentially spoofing traffic for the host >originating the flow. I'm sure the security review comments for this >will make for entertaining reading. > >At the very least, you need to ensure that there is an *airtight* >mechanism for ensuring that the probe traffic can never leak out of the >PCN domain, and that no ICMP traffic can be sent back towards the >host. Georgios: You are right about the security implications, therefore a requirement that has to hold is that the (end)node that initiates the flow should maintain security associations with the PCN-ingress node that initiates probing. Best regards, Georgios > > >Regards, > >=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 >Ericsson/Redback Networks +1 919-472-9913 > > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sat Sep 29 05:22:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbYX8-00044b-Bj; Sat, 29 Sep 2007 05:22:46 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IbYX7-00044W-R4 for pcn-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 05:22:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbYX7-00044H-HQ for pcn@ietf.org; Sat, 29 Sep 2007 05:22:45 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbYWx-0003rz-01 for pcn@ietf.org; Sat, 29 Sep 2007 05:22:45 -0400 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 l8T9MSWe008927; Sat, 29 Sep 2007 11:22:28 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sat, 29 Sep 2007 09:22:27 +0000 To: "Lars Eggert" , "ext Steven Blake" Subject: Re: [PCN] PCN architecture, revised sub-section on probing Date: Sat, 29 Sep 2007 09:22:27 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.029 () AWL 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, 29 Sep 2007 11:22:29 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: pcn X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Lars Agree with you regarding the comment on developing a solution that is not too complex, but if this solution is too simple and is not able to solve serius issues then this solution will not be deployed eather. Best regards, Georgios On 9/29/2007, "Lars Eggert" wrote: >On 2007-9-28, at 21:15, ext Steven Blake wrote: >> If a probe packet for a PCN-managed flow is intended to follow the >> same >> ECMP path as the flow, then the probe packet has to look exactly like >> flow packets in the header fields usually hashed by routers to load >> split for ECMP: IP source/destination address, TCP/UDP >> source/destination port; maybe the protocol/next header field as well. >> >> If you do this, you are essentially spoofing traffic for the host >> originating the flow. I'm sure the security review comments for this >> will make for entertaining reading. >> >> At the very least, you need to ensure that there is an *airtight* >> mechanism for ensuring that the probe traffic can never leak out of >> the >> PCN domain, and that no ICMP traffic can be sent back towards the >> host. > >Let me add that probe traffic (other than for supporting ECMP) seems >only useful when a domain can go from "no congestion" to "must >terminate" through the admission of a very small number of flows. >Otherwise, the gradual admission of regular flows can be used to >determine whether admission should be terminated. In other words, >regular flows can be used to "probe" the domain. > >I question whether domains that require explicit probing mechanisms >fall under the current PCN charter, which focuses on domains that >multiplex a sufficient numbers of flows such that stateless, >statistical mechanisms are effective. > >Explicit probing adds a lot of complexity. The idea behind PCN is to >add a minimal set of mechanisms to a large and busy DiffServ domain, >which would allow this domain to protect the QoS of already-admitted >flows in a best-effort sort of way. Meaning that although flow >termination should be mostly prevented due to admission stop >decisions, there will be no guarantees that no flow will ever be >terminated. PCN is also not a mechanism to squeeze the last ounce of >utilization out of a domain - sufficient overprovisioning remains a >requirement. Because of this, I wonder if PCN needs to support ECMP - >which did not come up during the chartering phase - when it looks >likely that such support will significantly complicate the solution. > >Finally, let me say that I'm worried that the WG seems to have >settled on a mode of working where all the different proposals will >be merged into one. The result is not likely to be a very simple >solution. We have ample experience with solutions that have been >designed in this manner failing to gain any traction, due to their >complexities. > >I'd like to strongly encourage the WG to instead discuss which of the >proposals is the most *simple* one that will fulfill the chartered >goals. We'd like the outcome of the first phase of work to be >something that people will usefully deploy in some domains. Without >demonstrated deployability and use, the need for continued future >work on PCN is questionable. > >Lars > > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Sep 30 02:08:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbryS-0004UW-7U; Sun, 30 Sep 2007 02:08:16 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IbryQ-0004UP-KN for pcn-confirm+ok@megatron.ietf.org; Sun, 30 Sep 2007 02:08:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbryQ-0004To-93 for pcn@ietf.org; Sun, 30 Sep 2007 02:08:14 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbryI-0001dV-Br for pcn@ietf.org; Sun, 30 Sep 2007 02:08:14 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JP6002YD3NYT5@szxga02-in.huawei.com> for pcn@ietf.org; Sun, 30 Sep 2007 14:07:10 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JP6000RJ3NVLS@szxga02-in.huawei.com> for pcn@ietf.org; Sun, 30 Sep 2007 14:07:10 +0800 (CST) Received: from z24109b ([10.70.76.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JP600DEB3NUT3@szxml04-in.huawei.com> for pcn@ietf.org; Sun, 30 Sep 2007 14:07:07 +0800 (CST) Date: Sun, 30 Sep 2007 14:06:52 +0800 From: Tina TSOU Subject: Re: [PCN] PCN architecture, revised sub-section on probing To: "Geib, Ruediger" , philip.eardley@bt.com Message-id: <003701c80328$18d0ee60$514c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC516@E03MVZ1-UKDY.domain1.systemhost.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: bfc9ec46aa2f66e5aee6a3bbffb0ebe9 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1310168185==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1310168185== Content-type: multipart/alternative; boundary="Boundary_(ID_6kosaTR1JP0w+L6jyoQFMA)" This is a multi-part message in MIME format. --Boundary_(ID_6kosaTR1JP0w+L6jyoQFMA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, Pls see comments in line demarked with [Tina: ...](: B. R. Tina ----- Original Message ----- From: philip.eardley@bt.com To: Ruediger.Geib@t-systems.com Cc: pcn@ietf.org Sent: Saturday, September 29, 2007 1:30 AM Subject: RE: [PCN] PCN architecture, revised sub-section on probing Ruediger, Follow-ups (further questions!) in-line on each of your 3 points [RG] - the discussion on the decision when to apply probing misses one important aspect, at least if you look at a single domain: probing is only required if any pre-congestion occurs within this domain. If there's no pre congested link within a domain, no probing is required within this domain. [phil] I slightly re-phrased the first bullet (the second bullet is unaltered), so the text now says: Probing is useful or even essential under the following conditions: o when an ingress-egress-aggregate carries no traffic (or too little traffic for the PCN-egress-node to accurately make the "measurements of PCN-traffic" that are required for an admission decision), [Tina: If the fact is the same above, if Probe message is sent, Ingress Node needs to send much more Probe Message traffic than the existing traffic. I think this will significantly increase the flow level in the domain. And will also take too much effort to generate these messages.] but the traffic levels on other ingress-egress-aggregates are so high that a new flow shouldn't be admitted on the 'empty' ingress-egress-aggregate. Probing is useful to check this. [Tina: I think Probe message is used to acquire the "pre-congestion" condition within the PCN domain. So Probe Message is only required when Ingress Node needs to make judgment to flow, but it has no knowledge about the condition within the domain. So Probing message is needed. The present PCN mechanism is designed as such that only Egress Node can know the flow forward status. This status must be sent to Ingess Node so as that Ingress Node can make Flow Admission or Flow Termination. Any circumstances that Ingress need to know the pre-congestion status within the domain, but Ingress Node doesn't know (such as ingress-egress-aggregate carries no traffic or too little traffic to accurately make measurement). It needs to send Probe message to acquire the pre-congestion status.] o in the presence of multipath routing (ECMP) between the PCN-boundary-nodes, when some paths are pre-congested there may be other paths which aren't pre-congested. Probing is useful to determine whether the new flow would follow a path that isn't pre-congested and hence can be admitted. [Tina: Probe message is not so intelligent to be routed to not-congestion path. So when forwarded, Probe message isn't necessary to flow across the one that is congested. Thus in this condition, Probe Message doesn't finish its mission.] I think what's written implies that it may not always be possible to know whether there's any (relevant) pre-congestion or none - so there's an argument for probing in such times of doubt to discover what the situation really is (if it turns out that there isn't any pre-congestion then, as you say, in some ways the probing hasn't proved to be useful). I think the tweaked text above captures this, but please suggest any mods to make it clearer (or disagree!) [RG} - given that probing is only applied within a domain, if there's pre-congestion on any link, then the only purpose of probing is to find out, whether traffic from the particular ingress to a desired egress would contribute to this pre-congestion. The probing flow then should be designed to ensure that packets of the probing flow are marked (and if interpretation is to be as simple as possible: marked probing packets mean no admission). [phil] I'm not quite sure what you mean by "designed to ensure that packets of the probing flow are marked". The section currently says that probe pkts are handled in the same way as (ordinary data) PCN-pkts [*]. I think you may be suggesting something different, that probing pkts should be preferentially PCN-marked? [*] incidentally, I'll tweak the text to add something like "in terms of pkt scheduling/forwarding and PCN-marking" ; for pkt dropping it may be arguable you should preferentially drop probes to ease DoS worries? Re: "interpretation is to be as simple as possible: marked probing packets mean no admission" - I think this is too solution-space for this Architecture draft (presumably there may be different options, eg block call if the single probe pkt is marked, if at least 2 out of 100 marked, etc) [RG] - If there's no flow between an ingress and an egress and ECMP is operational within a domain, the ingress may have to signal its intention to probe to an egress. [phil] could you explain your reference to ECMP please? At the moment the doc says that "(if required) Communicate the request that probing is needed - the PCN-egress-node signals to the PCN-ingress-node that probe traffic is needed". But you're suggesting there are particular circumstances when something is needed in the opposite direction? Thanks! phil ------------------------------------------------------------------------------ _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --Boundary_(ID_6kosaTR1JP0w+L6jyoQFMA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Hi,
Pls see comments in = line demarked=20 with [Tina: ...](:

B. R.
Tina
----- Original Message -----
From:=20 philip.eardley@bt.com
Sent: Saturday, September 29, = 2007 1:30=20 AM
Subject: RE: [PCN] PCN = architecture,=20 revised sub-section on probing

Ruediger,

 

Follow-ups = (further=20 questions!) in-line on each of your 3 points

 

[RG]=20 - the = discussion on=20 the decision when to apply probing misses one important aspect, = at least=20 if

  you = look at a=20 single domain: probing is only required if any pre-congestion occurs = within=20 this

  = domain. If=20 there's no pre congested link within a domain, no probing is required = within=20 this

 =20 domain. 

 

[phil] I = slightly=20 re-phrased the first bullet (the second bullet is unaltered), so the = text now=20 says:

 

Probing is useful or even essential under = the=20 following conditions:

 

   o  when an = ingress-egress-aggregate=20 carries no traffic (or too little traffic for the PCN-egress-node to=20 accurately make the "measurements of PCN-traffic" that are required = for an=20 admission decision),

[Tina: If the fact is = the same=20 above, if Probe message is sent, Ingress Node needs to send much more = Probe=20 Message traffic than the existing traffic. I think this will = significantly=20 increase the flow level in the domain.
And will also take too much = effort=20 to generate these messages.]

but the traffic levels on other=20 ingress-egress-aggregates are so high that a new flow shouldn't be = admitted on=20 the 'empty' ingress-egress-aggregate.  Probing is useful to check = this.

[Tina: I think Probe message is used to = acquire the=20 "pre-congestion" condition within the PCN domain. So Probe Message is = only=20 required when Ingress Node needs to make judgment to flow, but it has = no=20 knowledge about the condition within the domain. So Probing message is = needed.
The present PCN mechanism is designed as such that only = Egress Node=20 can know the flow forward status. This status must be sent to Ingess = Node so=20 as that Ingress Node can make Flow Admission or Flow Termination. Any=20 circumstances that Ingress need to know the pre-congestion status = within the=20 domain, but Ingress Node doesn't know (such as = ingress-egress-aggregate=20 carries no traffic or too little traffic to accurately make = measurement). It=20 needs to send Probe message to acquire the pre-congestion=20 status.]

 

   o  in the presence of = multipath=20 routing (ECMP) between the PCN-boundary-nodes, when some paths are=20 pre-congested there may be other paths which aren't = pre-congested. =20 Probing is useful to determine whether the new flow would follow a = path that=20 isn't pre-congested and hence can be admitted.

[Tina: Probe message is not so intelligent = to be=20 routed to not-congestion path. So when forwarded, Probe message isn't=20 necessary to flow across the one that is congested. Thus in this = condition,=20 Probe Message doesn't finish its mission.]

 

I think = what=92s=20 written implies that it may not always be possible to know whether = there=92s any=20 (relevant) pre-congestion or none =96 so there=92s an argument for = probing in such=20 times of doubt to discover what the situation really is (if it turns = out that=20 there isn=92t any pre-congestion then, as you say, in some ways the = probing=20 hasn=92t proved to be useful). I think the tweaked text above captures = this, but=20 please suggest any mods to make it clearer (or = disagree!)

 

 

[RG}=20 - given = that probing=20 is only applied within a domain, if there's pre-congestion on any = link, then=20

  the only=20 purpose of probing is to find out, whether traffic from the particular = ingress=20 to a

  = desired egress=20 would contribute to this pre-congestion. The probing flow then = should=20 be 

  = designed to=20 ensure that packets of the probing flow are marked (and if=20 interpretation is

  = to be as=20 simple as possible: marked probing packets mean no admission).=20

 

[phil] = I=92m not quite=20 sure what you mean by =93designed to = ensure=20 that packets of the probing flow are marked=94. The section = currently says=20 that probe pkts are handled in the same way as (ordinary data) = PCN-pkts [*]. I=20 think you may be suggesting something different, that probing pkts = should be=20 preferentially PCN-marked?

[*] = incidentally,=20 I=92ll tweak the text to add something like =93in terms of pkt=20 scheduling/forwarding and PCN-marking=94 ; for pkt dropping it may be = arguable=20 you should preferentially drop probes to ease DoS = worries?

 

Re:=20 =93interpretation is to be as simple as possible: marked = probing=20 packets mean no admission=94 =96 I think this is too = solution-space for this=20 Architecture draft (presumably there may be different options, eg = block call=20 if the single probe pkt is marked, if at least 2 out of 100 marked,=20 etc)

 

 

[RG] - If = there's no=20 flow between an ingress and an egress and ECMP is operational within a =

  = domain, the=20 ingress may have to signal its intention to probe to an=20 egress.

 

[phil] = could you=20 explain your reference to ECMP please?

At the = moment the doc=20 says that =93(if required) Communicate the request that = probing is=20 needed =96 the PCN-egress-node signals to the PCN-ingress-node that = probe=20 traffic is needed=94. But you=92re suggesting there are particular = circumstances=20 when something is needed in the opposite direction?

 

 

Thanks!

phil

 

 

_______________________________________________
PCN mailing=20 = list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn
--Boundary_(ID_6kosaTR1JP0w+L6jyoQFMA)-- --===============1310168185== 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://www1.ietf.org/mailman/listinfo/pcn --===============1310168185==-- From pcn-bounces@ietf.org Sun Sep 30 05:58:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbvYs-0004DE-EK; Sun, 30 Sep 2007 05:58:06 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IbvYr-0004Cs-GU for pcn-confirm+ok@megatron.ietf.org; Sun, 30 Sep 2007 05:58:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbvYr-0004Cj-6r for pcn@ietf.org; Sun, 30 Sep 2007 05:58:05 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbvYj-00053e-Vy for pcn@ietf.org; Sun, 30 Sep 2007 05:58:05 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JP6008VZEB2BK@szxga03-in.huawei.com> for pcn@ietf.org; Sun, 30 Sep 2007 17:57:02 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JP600067EB1FD@szxga03-in.huawei.com> for pcn@ietf.org; Sun, 30 Sep 2007 17:57:02 +0800 (CST) Received: from z24109b ([10.70.76.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JP600ERMEB0DM@szxml03-in.huawei.com> for pcn@ietf.org; Sun, 30 Sep 2007 17:57:01 +0800 (CST) Date: Sun, 30 Sep 2007 17:56:46 +0800 From: Tina TSOU Subject: [PCN] PCN architecture, use of phrases like "exceeds rate" To: pcn@ietf.org Message-id: <011c01c80348$36842e20$514c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0851431854==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0851431854== Content-type: multipart/alternative; boundary="Boundary_(ID_yzxsLYCUV5VcLHvtw62E1Q)" This is a multi-part message in MIME format. --Boundary_(ID_yzxsLYCUV5VcLHvtw62E1Q) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi, See comments in line demarked with [Tina: ...] (: B. R. Tina RE: [PCN] PCN architecture, use of phrases like "exceeds rate" To: "Geib, Ruediger" , =20 Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds rate"=20 From: "Jozef Babiarz" =20 Date: Wed, 19 Sep 2007 21:54:36 -0400=20 Cc: pcn at ietf.org=20 In-reply-to: = <1B6169C658325341A3B8066E23919E1C0DE7C3@S4DE8PSAANK.mitte.t-com.de>=20 List-archive: =20 List-help: =20 List-id: PCN WG list =20 List-post: =20 List-subscribe: , = =20 List-unsubscribe: , = =20 References: = <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A0@E03MVZ1-UKDY.domain1.systemhost= .net> = <1B6169C658325341A3B8066E23919E1C0DE7C3@S4DE8PSAANK.mitte.t-com.de>=20 Thread-index: AcfZ4sD4MX/wup2KTYmWXZzVtqCqDAgo1F2AACdxudA=3D=20 Thread-topic: [PCN] PCN architecture, use of phrases like "exceeds rate" = Phil and others, since Ruediger email brought this to my attention. I = have the following comments. =20 I think we should change the word =A1=B0algorithm=A1=B1 to =A1=B0marking = behaviour=A1=B1 and =A1=B0rate=A1=B1 to =A1=B0threshold=A1=B1. At least = I believe that we should avoid specifying a specific algorithm but just = define the behaviour of the algorithm. This would allow vendors to = choose an algorithm that they believe gives best results. So would = propose the following. [Tina: The change is necessary for this new one is more explicit in = meaning.] =20 =20 <> Regards, Joe=20 email:babiarz at nortel.com=20 Telephone:613-763-6098=20 --Boundary_(ID_yzxsLYCUV5VcLHvtw62E1Q) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Hi,
See comments in line = demarked with=20 [Tina: ...] (:
 
B. R.
Tina
 
 
RE: [PCN] PCN architecture, use of = phrases like=20 "exceeds rate"
 
To: "Geib, Ruediger" <Ruediger.Geib = at=20 t-systems.com>, <philip.eardley at bt.com>
Subject: RE: = [PCN] PCN=20 architecture, use of phrases like "exceeds rate"
From: "Jozef = Babiarz"=20 <babiarz at nortel.com>
Date: Wed, 19 Sep 2007 21:54:36 -0400 =
Cc:=20 pcn at ietf.org
In-reply-to: <1B6169C658325341A3B8066E23919E1C0DE7C3@S4DE8PSAANK.mitte.t-com.d= e>=20
List-archive: <http://www1.ietf.org/pipermai= l/pcn>=20
List-help: <mailto:pcn-request@ie= tf.org?subject=3Dhelp>=20
List-id: PCN WG list <pcn.ietf.org>
List-post: <mailto:pcn@ietf.org> =
List-subscribe:=20 <https://www1.ietf.org= /mailman/listinfo/pcn>,=20 <mailto:pcn-reque= st@ietf.org?subject=3Dsubscribe>=20
List-unsubscribe: <https://www1.ietf.org= /mailman/listinfo/pcn>,=20 <mailto:pcn-req= uest@ietf.org?subject=3Dunsubscribe>=20
References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A0@E03MVZ1-UKDY= .domain1.systemhost.net>=20 <1B6169C658325341A3B8066E23919E1C0DE7C3@S4DE8PSAANK.mitte.t-com.d= e>=20
Thread-index: AcfZ4sD4MX/wup2KTYmWXZzVtqCqDAgo1F2AACdxudA=3D =
Thread-topic:=20 [PCN] PCN architecture, use of phrases like "exceeds rate"
Phil and = others,=20 since Ruediger email brought this to my attention. I have the following=20 comments.
 
I think we should change the word = =A1=B0algorithm=A1=B1 to =A1=B0marking=20 behaviour=A1=B1 and =A1=B0rate=A1=B1 to =A1=B0threshold=A1=B1. At least = I believe that we should avoid=20 specifying a specific algorithm but just define the behaviour of the = algorithm.=20 This would allow vendors to choose an algorithm that they believe gives = best=20 results. So would propose the following.
[Tina: = The=20 change is necessary for this new one is more explicit in=20 meaning.]
  
 
<<Two traffic = thresholds, a=20 PCN-lower-threshold and a PCN-upper-threshold, can be associated with = each link=20 of the PCN-domain. Each traffic threshold has a marking = behaviour(specified in=20 another document) that determines how and when PCN-packets are marked, = and how=20 the markings are encoded in packet headers. PCN-egress-nodes make = measurements=20 of the packet markings and send information as necessary to the nodes = that make=20 the decision about which PCN-flow(s) to accept/reject or terminate, = based on=20 this information. Another document will describe decision-making = behaviour.=20 Overall the aim is to enable PCN-nodes to give an "early warning" of = potential=20 congestion before there is any significant build-up of PCN-packets in = the queue;=20 the admission control mechanism limits the PCN-traffic on each link to = *roughly*=20 its PCN-lower- threshold and the flow termination mechanism limits the=20 PCN-traffic on each link to *roughly* its=20 PCN-upper-threshold.>>
Regards, Joe
email:babiarz at = nortel.com=20
Telephone:613-763-6098
 
 
 
 
 

 
--Boundary_(ID_yzxsLYCUV5VcLHvtw62E1Q)-- --===============0851431854== 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://www1.ietf.org/mailman/listinfo/pcn --===============0851431854==--