From pcn-bounces@ietf.org Tue May 6 08:45:46 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E346B28C332; Tue, 6 May 2008 08:45:45 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB44B28C3D7 for ; Tue, 6 May 2008 08:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.702 X-Spam-Level: * X-Spam-Status: No, score=1.702 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, J_CHICKENPOX_92=0.6, MIME_ASCII0=1.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InUKBHcyhoPr for ; Tue, 6 May 2008 08:45:32 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 411D328C244 for ; Tue, 6 May 2008 08:45:24 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 May 2008 16:45:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 May 2008 16:45:19 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B347A8@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B347A5@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN Marking behaviour draft Thread-Index: AcivamRCDCBDDZLPTLS4UT3u8U0c+QAAC6UA From: To: , X-OriginalArrivalTime: 06 May 2008 15:45:20.0955 (UTC) FILETIME=[30D620B0:01C8AF90] Subject: Re: [PCN] PCN Marking behaviour draft X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1166269468==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1166269468== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AF90.300E45AC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AF90.300E45AC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fortune Thanks for your comments! Some follow-ups in-line, indicated by [phil] phil =20 -----Original Message----- From: Eardley,PL,Philip,CXR9 R=20 Sent: 06 May 2008 12:15 To: Eardley,PL,Philip,CXR9 R Subject:=20 =20 Hi Philip et al, =20 I am resending the comments below because Tina said she hasn't received my last email with the same comments. And I don't know why my last email hasn't been archived in the PCN mailing list. =20 A few comments below: =20 Comment 1: In section 1, I think the use cases are based on the following assumptions: a) Flow=20 termination and admission control can be deployed independently. b) Both threshold-marking=20 and excess-traffic-marking are applicable for admission control. c) Only excess-traffic-marking=20 is applicable for flow termination, and threshold-marking is not applicable for flow termination. =20 I would like to know if these assumptions are correct in you view.=20 And I suggest we add the assumptions into section 1, just to provide more support to the=20 sentense "This leads to the following four use cases". =20 [phil] yes, you're right. I'll try to make this clearer.=20 =20 Comment 2: I am wondering if the following use case is acceptable, because I think it obeys my=20 assumptions above: An operator requires only admission control, and excess-traffic-marking is used. And this is not included in section 1 in the current draft. =20 [phil] in theory this is possible. However, the real limitation in this case is that you only have two encoding states (PCN-marked & not PCN-marked) - then you'd use threshold-marking, as this is more accurate for admission control than excess-traffic-marking. However, I should add this in somehow.=20 =20 Comment 3: I am a little confused by the descriptions of use case 3 and 4 in section 1. I don't know why two encoding states are needed in use case 3, while only 1 encoding states=20 are needed in use case 4. Suppose admission control need two states, one is ADMISSION(as default),=20 the other is ADMISSION-STOP. I think in the same way, flow termination need two states, one is=20 TERMINATION, the other is TERMINATION-STOP(as default). If the default state should be excluded,=20 then admission control only need one state called ADMISSION-STOP, while flow termination only=20 need one state called TERMINATION. =20 [phil] yes, sorry this is confusing. I made a typo. Use case 4 should say that 2 encoding states are needed, ie excess-traffic-marked & "not PCN-marked" =20 Comment 4: The condition function is introduced into the draft. I think this is the function belonging=20 to the PCN-interior-node. Maybe we can add this funciton to the draft-PCN-architecture. =20 [phil] yes, this is a good point. Thanks.=20 =20 Comment 5: Something like the first 4 sentenses of the section 2.4 can also be mentioned in section 2.3. =20 [phil] no, the two sections are deliberately different. First some context for other people. Section 2.3 is about the Threshold meter function & S2.4 about the Excess traffic meter function. The first few sentences of S2.4 explain that the Excess traffic meter shouldn't meter pkts that are already excess-traffic-marked.=20 =20 Your suggestion is that S2.3 similarly says that the Threshold meter function shouldn't meter pkts that are already threshold marked (or perhaps excess-traffic-marked). This would be wrong - remember that the marked pkts come from admitted flows and cause load on the router, so must contribute to the decision about whether a new flow is blocked or admitted. To illustrate this, consider a contrived scenario. There's a high speed router with a 1Gb/s PCN-threshold-rate. The total traffic is above this, so all the pkts are threshold-marked. The traffic gets split over many small links (a big fan out) and mixed with lots of other traffic that has gone through other routers that aren't doing any marking, such that another node seems 1Mb/s of threshold marks. This node actually has a total traffic of 10Mb/s and a threshold rate of 9.1Mb/s. 1Mb/s is already marked - so with your proposal it will only meter 9M/s & hence not mark any more pkts. If there's a PCN egress at the end of this link it sees 10% of traffic as threshold marked, which may not be enough to trigger blocking of new flows. Yet really the traffic is well above its threshold rate, so really no more flows should be admitted. This is achieved if the node meters all pkts, ie including ones already marked, as then it ends up threshold marking all pkts. =20 Things are different for the excess traffic meter, because the PCN edges nodes react to the amount of excess-traffic-markings to determine how much traffic to terminate. =20 =20 S2.4 also says that if a PCN-interior-node drops a pkt, then it shouldn't contribute to the excess-traffic-meter. There's no need to say something similar for the threshold meter - if the load is high enough for pkts to be dropped, then we know for sure that the traffic is way above the PCN-threshold-rate and therefore all pkts are getting threshold-marked or excess-traffic-marked.=20 =20 I'll add some explanation to the Appendix to cover these points.=20 =20 Comment 6: In section 4.5 in draft-PCN-architecture, it says "There may be other traffic with the same priority=20 as PCN-traffic.". This kind of traffic is not very clear to me whether it affects PCN-meter.=20 Could you clarify it, please? =20 [phil] this needs clarifying. Joe and I have been discussing this, as we realised whilst writing this draft that this text is problematic. Will send something soon =20 Best Regards, Fortune =20 ----- Original Message -----=20 From: philip.eardley@bt.com=20 To: pcn@ietf.org=20 Sent: Tuesday, April 29, 2008 10:40 PM Subject: [PCN] PCN Marking behaviour draft =20 =20 Hi =20 I've just posted a draft which tries to specify the marking behaviour for PCN nodes. =20 =20 =20 It's based on an update of the emails I sent shortly before the last IETF. Updates include adjusting as a result of the WG consensus call on Steven's Questions 1 to 6. Many thanks to Joe, Michael & Anna who've made suggestions and comments about it. Overall I think it's much improved compared to the emails. =20 =20 =20 Comments please! =20 =20 =20 Thanks =20 Phil/. =20 =20 =20 =20 =20 =20 =20 -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: 29 April 2008 15:33 To: Eardley,PL,Philip,CXR9 R Subject: New Version Notification for draft-eardley-pcn-marking-behaviour-00=20 =20 =20 =20 =20 =20 A new version of I-D, draft-eardley-pcn-marking-behaviour-00.txt has been successfuly submitted by Philip Eardley and posted to the IETF repository. =20 =20 =20 Filename: draft-eardley-pcn-marking-behaviour =20 Revision: 00 =20 Title: Marking behaviour of PCN-nodes =20 Creation_date: 2008-04-29 =20 WG ID: Independent Submission =20 Number_of_pages: 15 =20 =20 =20 Abstract: =20 This document standardises the two marking behaviours of PCN-nodes: =20 threshold marking and excess traffic marking. Threshold marking =20 marks all PCN-packets if the PCN traffic rate is greater than a first =20 configured rate. Excess traffic marking marks a proportion of PCN- =20 packets, such that the amount marked equals the traffic rate in =20 excess of a second configured rate.Requirements Language =20 =20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", =20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this =20 document are to be interpreted as described in RFC 2119 [RFC2119]. =20 =20 =20 =20 =20 =20 =20 The IETF Secretariat. =20 =20 =20 =20 =20 =20 =20 =20 =20 ------------------------------------------------------------------------ -------- =20 =20 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn ------_=_NextPart_001_01C8AF90.300E45AC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Fortune

Thanks for your = comments!

Some follow-ups in-line, indicated = by [phil]

phil

 

-----Original Message-----
From: = Eardley,PL,Philip,CXR9 R
Sent: 06 May 2008 = 12:15
To: = Eardley,PL,Philip,CXR9 R
Subject: =

 

Hi Philip et al,

 

I am resending the comments below because Tina said she hasn't = received my last email with the same comments.

And I don't know why my last email hasn't been archived in the = PCN mailing list.

 

A few comments below:

 

Comment 1:

In section 1, I think the use cases are based on the following assumptions: a) Flow

termination and admission control can be deployed independently. = b) Both threshold-marking

and excess-traffic-marking are applicable for admission control. = c) Only excess-traffic-marking

is applicable for flow termination, and threshold-marking is not applicable for flow termination.

 

I would like to know if these assumptions are correct in you = view.

And I suggest we add the assumptions into section 1, just to = provide more support to the

sentense "This leads to the following four use = cases".

 

[phil] yes, you’re right. = I’ll try to make this clearer.

 

Comment 2:

I am wondering if the following use case is acceptable, because = I think it obeys my

assumptions above: An operator requires only admission control, = and excess-traffic-marking is used.

And this is not included in section 1 in the current = draft.

 

[phil] in theory this is possible. = However, the real limitation in this case is that you only have two encoding = states (PCN-marked & not PCN-marked) - then you’d use = threshold-marking, as this is more accurate for admission control than excess-traffic-marking. = However, I should add this in somehow.

 

Comment 3:

I am a little confused by the descriptions of use case 3 and 4 = in section 1.

I don't know why two encoding states are needed in use case 3, = while only 1 encoding states

are needed in use case 4. Suppose admission control need two = states, one is ADMISSION(as default),

the other is ADMISSION-STOP. I think in the same way, flow = termination need two states, one is

TERMINATION, the other is TERMINATION-STOP(as default). If the = default state should be excluded,

then admission control only need one state called = ADMISSION-STOP, while flow termination only

need one state called TERMINATION.

 

[phil] yes, sorry this is = confusing. I made a typo. Use case 4 should say that 2 encoding states are needed, ie excess-traffic-marked & “not = PCN-marked”

 

Comment 4:

The condition function is introduced into the draft. I think = this is the function belonging

to the PCN-interior-node. Maybe we can add this funciton to the draft-PCN-architecture.

 

[phil] yes, this is a good point. = Thanks.

 

Comment 5:

Something like the first 4 sentenses of the section 2.4 can also = be mentioned in section 2.3.

 

[phil] no, the two sections are = deliberately different.

First some context for other people. =
Section 2.3 is about the Threshold meter function & S2.4 about =
the Excess traffic meter function. The first few sentences =
of S2.4 explain that the Excess traffic meter shouldn’t meter pkts =
that are already excess-traffic-marked. 
 
Your =
suggestion is that S2.3 similarly says that the Threshold meter function =
shouldn’t meter pkts that are already threshold marked (or perhaps =
excess-traffic-marked). This would be wrong – remember that the =
marked pkts come from admitted flows and cause load on the router, so =
must contribute to the decision about whether a new flow is blocked or =
admitted.
To =
illustrate this, consider a contrived scenario. There’s a high =
speed router with a 1Gb/s PCN-threshold-rate. The total traffic is above =
this, so all the pkts are threshold-marked. The traffic gets split over =
many small links (a big fan out) and mixed with lots of other traffic =
that has gone through other routers that aren’t doing any marking, =
such that another node seems 1Mb/s of threshold marks. This node =
actually has a total traffic of 10Mb/s and a threshold rate of 9.1Mb/s. =
1Mb/s is already marked – so with your proposal it will only meter =
9M/s & hence not mark any more pkts. If there’s a PCN egress =
at the end of this link it sees 10% of traffic as threshold marked, =
which may not be enough to trigger blocking of new flows. Yet really the =
traffic is well above its threshold rate, so really no more flows should =
be admitted. This is achieved if the node meters all pkts, ie including =
ones already marked, as then it ends up threshold marking all =
pkts.
 
Things =
are different for the excess traffic meter, because the PCN edges nodes =
react to the amount of excess-traffic-markings to determine how much =
traffic to terminate.  
 
S2.4 also =
says that if a PCN-interior-node drops a pkt, then it shouldn’t =
contribute to the excess-traffic-meter. There’s no need to say =
something similar for the threshold meter – if the load is high =
enough for pkts to be dropped, then we know for sure that the traffic is =
way above the PCN-threshold-rate and therefore all pkts are getting =
threshold-marked or excess-traffic-marked. =

 
I’ll add some explanation to the =
Appendix to cover these points. 
 

Comment 6:

In section 4.5 in draft-PCN-architecture, it says "There = may be other traffic with the same priority

as PCN-traffic.". This kind of traffic is not very clear to = me whether it affects PCN-meter.

Could you clarify it, please?

 

[phil] this needs clarifying. Joe = and I have been discussing this, as we realised whilst writing this draft that this = text is problematic. Will send something soon

 

Best Regards,

Fortune

 

----- Original Message -----

From: philip.eardley@bt.com

To: pcn@ietf.org

Sent: Tuesday, April 29, 2008 10:40 PM

Subject: [PCN] PCN Marking behaviour draft

 

 

Hi

 

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

 

 

 

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

 

 

 

Comments please!

 

 

 

Thanks

 

Phil/.

 

 

 

 

 

 

 

-----Original Message-----

From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] =

Sent: 29 April 2008 15:33

To: Eardley,PL,Philip,CXR9 R

Subject: New Version Notification for draft-eardley-pcn-marking-behaviour-00

 

 

 

 

 

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

 

 

 

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

 

Revision:   00

 

Title:          = ;  Marking behaviour of PCN-nodes

 

Creation_date:    2008-04-29

 

WG ID:            Independent = Submission

 

Number_of_pages: 15

 

 

 

Abstract:

 

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

 

threshold marking and excess traffic marking.  Threshold = marking

 

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

 

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

 

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

 

excess of a second configured rate.Requirements = Language

 

 

 

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

 

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

 

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

 

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

 

 

 

 

 

The IETF Secretariat.

 

 

 

 

 

 

 

 

 

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

 

 

_______________________________________________

=

PCN mailing list

PCN@ietf.org

https://www.ietf.org/mailman/listinfo/pcn

=00 ------_=_NextPart_001_01C8AF90.300E45AC-- --===============1166269468== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1166269468==-- From pcn-bounces@ietf.org Fri May 9 03:29:45 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9164D3A6833; Fri, 9 May 2008 03:29:45 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 273F83A6833 for ; Fri, 9 May 2008 03:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuobdichjeO2 for ; Fri, 9 May 2008 03:29:42 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 5806A3A681E for ; Fri, 9 May 2008 03:29:38 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Fri, 9 May 2008 11:26: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); Fri, 9 May 2008 11:26:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 May 2008 11:28:25 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C0137041D@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-eardley-pcn-marking-behaviour-00 Thread-Index: AcijDdEhZTGFLwePTTiggUM/QqQ5UgAwCZpAAB3SJWADLoioIA== References: <1208713265.3483.27.camel@tachyon> <75A199C5D243C741BF3D3F1EBCEF9BA503B3475A@E03MVZ1-UKDY.domain1.systemhost.net> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 09 May 2008 09:26:10.0927 (UTC) FILETIME=[B80097F0:01C8B1B6] Cc: pcn@ietf.org Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, thanks for your early draft. The document is short = and in a good shape. I still have some questions, = mainly related to the conditioner. Regards, Rudiger -----------Issue 1------------- 1. Introduction o Packet classify and condition -... also Figure 1 and a couple of other times in = the text: The location of the conditioner and its = functions to me are not well defined. Two = main issues: - the conditioner drops or downgrades packets = above a threshold, so there's some meter in = front of it. - section 2.4 says = "A packet SHOULD NOT be metered (by this = excess traffic meter function) in the = following two cases: o If the packet is already = excess-traffic-marked; o If this PCN-node drops (downgrades) the = packet because the link is overloaded." If the conditioner is in front of the meter, = then the packet can't be metered if it is = dropped or downgraded. Michael published on the sequence of conditioner = and marker in his "Performance Evaluation of = PCN-based Flow Admission Control and Termination". = Condition, then meter seems to be preferrable. = All in all, the aspect of conditioning is rather = unclear and if the authors don't take any = position on the sequence meter/condition/mark, = some argumentation in the document may be helpful. Unless anything speaks against meter, condition, mark, I prefer this sequence. -----------Issue 2------------- 2.2. Classify and condition function "If the level of traffic is sufficiently high to = overload the PCN behaviour aggregate(s), then = traffic MUST be conditioned." This implies another meter to determine the overload, = doesn't it? Is the following holding: classify->overload-meter->condition-> thresh/excess meter->mark? This sequence would be allright with me. -------Issue 3a------------------ same section as issue 2, just continuing "The three possibilities are: o drop PCN-packets; o downgrade PCN-packets to a lower priority = behaviour aggregate, such as best effort or = assured forwarding, and perhaps drop lower priority packets; o drop or downgrade other "metered packets". ^^^^^^ Please delete "other" as it sounds unprecise and = contradicts the earlier statement, that these = packets are more important then PCN traffic. May be replaced by adding "in general". Or is this sequence of possibilities meant as a = list of handling priorities? ------Issue 3b: Do all routers of a domain have to = support this conditioning and do they all have to = operate with the same choice? The document is = unclear on that ---------Issue 4------------------ same section as issue 3, just continuing "If PCN-packets are dropped (or downgraded) then: o excess-traffic-marked PCN-packets SHOULD be = preferentially dropped (downgraded); o PCN-packets that are dropped (downgraded) = SHOULD NOT be metered by the Excess traffic = Meter." Please define what is meant by = "excess-traffic-marked". Do you mean CE marked? It is probably not harmful if the threshold meter = counts these packets, but it doesn't make much = sense either. But I don't ask for a change of = text on that aspect (if thought useful, then = generalise the text). -------Issue 5----------------- 2.3. Threshold meter function .. "The meter is a token bucket, which..." ^^ Please replace by "acts like" (also in "2.4 = Excess meter" ------Issue 6----------------- 2.5. Marking function "o if two encoding states are available (one = for excess-traffic-marked and one for = "not PCN-marked") then: * if the Excess traffic Meter indicates = marking, then the packet is = excess-traffic-marked; * otherwise the packet's encoding state = is not altered." and the same text earlier for threshold marking. = Could both be replaced by: o if two encoding states are available (one = for Behaviour_mode and one for "not = PCN-marked") then: * if the Behaviour_Meter indicates = marking, then the packet is = Behaviour_marked; * otherwise the packet's encoding state = is not altered." Where the Behaviour is either Excess or Threshold. = Ok, a minor comment, would save a few lines, = but doesn't necessarily improve readability. ------------------------------ R=FCdiger Geib T-Systems Enterprise Services GmbH Systems Integration R=FCdiger Geib Project Unit 6 Line of Business Networks & Processes Deutsche-Telekom-Allee 7, 64295 Darmstadt Tel. +49 6151 937-2138 Fax +49 6151 937-4591 Internet: http://www.t-systems.com T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, Olaf = Heyden*, Dr. Klaus Hofmann, Katrin Horstmann, Joachim Langmack*, Wilfried P= eters*, Dr. Stefan Schloter, Dr. Matthias Schuster*, Zvezdana Seeger*, Dr. = Rolf Werner Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri May 9 03:42:54 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BAB73A6833; Fri, 9 May 2008 03:42:54 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 551183A6833 for ; Fri, 9 May 2008 03:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[AWL=2.351, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPJtVvjl1gas for ; Fri, 9 May 2008 03:42:52 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id A78F33A681E for ; Fri, 9 May 2008 03:42:51 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 May 2008 11:41:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 May 2008 11:41:00 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B347BE@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1C0137041D@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-eardley-pcn-marking-behaviour-00 Thread-Index: AcijDdEhZTGFLwePTTiggUM/QqQ5UgAwCZpAAB3SJWADLoioIAAvQRTA From: To: X-OriginalArrivalTime: 09 May 2008 10:41:01.0467 (UTC) FILETIME=[2C929EB0:01C8B1C1] Cc: pcn@ietf.org Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Rudiger Thanks for the comments. I think the slight lack of clarity about the conditioner comes because it's= an issue we've thought about less than the "core" PCN meter/mark functions= , and also because trying to leave some implementation openness. Issue 1: Yes, the conditioner will include a meter in for it to do its work (I don't= see this as being "in front of" the conditioner - it's part of it). this i= s different from the PCN meters (at one point you seem to imply the PCN met= er is the same thing as the conditioner's meter) Will try & clarify. Will also take another look at some of the Diffserv stu= ff about conditioners, to try and use the same language [I did try to alrea= dy, as this was an earlier comment by joe, but I'll try & make it better] &= maybe add refs. Issue 2: Ok, I see that we're both thinking the same, as this is basically the answe= r I gave to issue 1! Issue 3a: I thought it was worth distinguishing the dropping/downgrading of PCN pkts,= from the dropping/downgrading of other metered pkts (by which I meant, met= ered pkts that are not PCn pkts - these 2 terms are precisely defined) I'll try & clarify Issue 3b: An interesting question. At the moment the doc says that Conditioning is a = MUST, ie all routers of pcn-domain will have to support it. the doc implies= that they don't all have to operate with the same choice; I think this is = reasonable, but some standards language is needed. Inclined to make all the= conditioning possibilities MAYs (ie dropping pcn pkts, downgrading pcn pkt= s, drop/downgrade metered, non-pcn pkts). = Please shout if you think something different, eg that one possibility is s= o much better that it needs to be a SHOULD. = Issue 4: Excess-traffic-marked is defined elsewhere. It means marked by an (earlier = PCN-node's) excess traffic meter /marker function. = This & issue 2 suggest that need to add a terminology section. It's a deliberate choice that the threshold meter SHOULD NOT meter these pk= ts (ie not meter ones that are already excess-traffic-marked). The reason i= s that otherwise too much traffic is terminated (with some edge behaviours)= . This choice was one of the consensus decisions reached in Steven's Questi= ons 1-6. Issue 5: Ok Issue 6: I think this change would be over-compression, and it's better to use a few= more words & make it easier to understand. = Thanks! phil = > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 09 May 2008 10:28 > To: Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org > Subject: RE: [PCN] draft-eardley-pcn-marking-behaviour-00 > = > Hi Phil, > = > thanks for your early draft. The document is short > and in a good shape. I still have some questions, > mainly related to the conditioner. > = > Regards, > = > Rudiger > = > -----------Issue 1------------- > = > 1. Introduction > = > o Packet classify and condition -... > also Figure 1 and a couple of other times in > the text: > = > The location of the conditioner and its > functions to me are not well defined. Two > main issues: > - the conditioner drops or downgrades packets > above a threshold, so there's some meter in > front of it. > - section 2.4 says > "A packet SHOULD NOT be metered (by this > excess traffic meter function) in the > following two cases: > = > o If the packet is already > excess-traffic-marked; > = > o If this PCN-node drops (downgrades) the > packet because the link is overloaded." > = > If the conditioner is in front of the meter, > then the packet can't be metered if it is > dropped or downgraded. > = > Michael published on the sequence of conditioner > and marker in his "Performance Evaluation of > PCN-based Flow Admission Control and Termination". > Condition, then meter seems to be preferrable. > = > All in all, the aspect of conditioning is rather > unclear and if the authors don't take any > position on the sequence meter/condition/mark, > some argumentation in the document may be helpful. > = > Unless anything speaks against meter, condition, > mark, I prefer this sequence. > = > -----------Issue 2------------- > = > 2.2. Classify and condition function > = > "If the level of traffic is sufficiently high to > overload the PCN behaviour aggregate(s), then > traffic MUST be conditioned." > = > This implies another meter to determine the overload, > doesn't it? Is the following holding: > = > classify->overload-meter->condition-> > thresh/excess meter->mark? > = > This sequence would be allright with me. > = > -------Issue 3a------------------ > = > same section as issue 2, just continuing > = > "The three possibilities are: > = > o drop PCN-packets; > = > o downgrade PCN-packets to a lower priority > behaviour aggregate, such as best effort or > assured forwarding, and perhaps drop lower > priority packets; > = > o drop or downgrade other "metered packets". > ^^^^^^ > Please delete "other" as it sounds unprecise and > contradicts the earlier statement, that these > packets are more important then PCN traffic. > May be replaced by adding "in general". > = > Or is this sequence of possibilities meant as a > list of handling priorities? > = > ------Issue 3b: Do all routers of a domain have to > support this conditioning and do they all have to > operate with the same choice? The document is > unclear on that > = > ---------Issue 4------------------ > = > same section as issue 3, just continuing > = > "If PCN-packets are dropped (or downgraded) then: > = > o excess-traffic-marked PCN-packets SHOULD be > preferentially dropped (downgraded); > = > o PCN-packets that are dropped (downgraded) > SHOULD NOT be metered by the Excess traffic > Meter." > = > Please define what is meant by > "excess-traffic-marked". Do you mean CE marked? > = > It is probably not harmful if the threshold meter > counts these packets, but it doesn't make much > sense either. But I don't ask for a change of > text on that aspect (if thought useful, then > generalise the text). > = > -------Issue 5----------------- > = > 2.3. Threshold meter function > = > .. > "The meter is a token bucket, which..." > ^^ > = > Please replace by "acts like" (also in "2.4 > Excess meter" > = > ------Issue 6----------------- > = > 2.5. Marking function > = > "o if two encoding states are available (one > for excess-traffic-marked and one for > "not PCN-marked") then: > = > * if the Excess traffic Meter indicates > marking, then the packet is > excess-traffic-marked; > = > * otherwise the packet's encoding state > is not altered." > = > and the same text earlier for threshold marking. > Could both be replaced by: > = > o if two encoding states are available (one > for Behaviour_mode and one for "not > PCN-marked") then: > = > * if the Behaviour_Meter indicates > marking, then the packet is > Behaviour_marked; > = > * otherwise the packet's encoding state > is not altered." > = > Where the Behaviour is either Excess or Threshold. > = > Ok, a minor comment, would save a few lines, > but doesn't necessarily improve readability. > ------------------------------ > = > = > = > R=FCdiger Geib > = > T-Systems Enterprise Services GmbH > Systems Integration > R=FCdiger Geib > Project Unit 6 > Line of Business Networks & Processes > Deutsche-Telekom-Allee 7, 64295 Darmstadt > Tel. +49 6151 937-2138 > Fax +49 6151 937-4591 > Internet: http://www.t-systems.com > = > = > T-Systems Enterprise Services GmbH > Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) > Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, Olaf > Heyden*, Dr. Klaus Hofmann, Katrin Horstmann, Joachim Langmack*, Wilfried > Peters*, Dr. Stefan Schloter, Dr. Matthias Schuster*, Zvezdana Seeger*, > Dr. Rolf Werner > Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 > Sitz der Gesellschaft: Frankfurt am Main > WEEE-Reg.-Nr. DE87523644 > *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG > = > = > = > = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu May 15 15:16:00 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9F483A6828; Thu, 15 May 2008 15:16:00 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AFF73A6872 for ; Thu, 15 May 2008 15:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2N+aubazaa1O for ; Thu, 15 May 2008 15:15:58 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 6380F3A681B for ; Thu, 15 May 2008 15:15:58 -0700 (PDT) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 May 2008 16:32:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 May 2008 16:31:43 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-moncaster-pcn-baseline-encoding-00 thread-index: Aci2n45ClKpoTZ+pRHadFns300LwjQAAARxw From: To: X-OriginalArrivalTime: 15 May 2008 15:32:03.0758 (UTC) FILETIME=[D36344E0:01C8B6A0] Subject: [PCN] FW: New Version Notification for draft-moncaster-pcn-baseline-encoding-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi All, I have just posted an initial attempt at a standards track encoding document to allow two PCN encoding states (as agreed in the voting on this list). I have included Michael Menth and Bob Briscoe as authors on this as it is based on the work we all did at the last IETF. Please can people try and read this and let me have any comments. The key aim of the document is to specify the baseline encoding in such a manner that it allows the experimental extension (with three encoding states) to exist without contradiction. It achieves this by splitting the behaviour into core behaviour, behaviour at edge nodes and behaviour at interior nodes. I am currently trying to finish writing the initial draft for the experimental extension to three encoding states. I am having some difficulty putting it in clear English but hope to be able to post an early version next week. Ideally I am hoping that we can get at least this baseline encoding accepted as a WG document by early June and can get it into WGLC before the Dublin IETF. Toby ____________________________________________________________________ Toby Moncaster, Networks Research Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: 15 May 2008 16:23 To: Moncaster,T,Toby,CXR9 R Cc: Briscoe,RJ,Bob,CXR9 R; menth@informatik.uni-wuerzburg.de Subject: New Version Notification for draft-moncaster-pcn-baseline-encoding-00 A new version of I-D, draft-moncaster-pcn-baseline-encoding-00.txt has been successfuly submitted by T Moncaster and posted to the IETF repository. Filename: draft-moncaster-pcn-baseline-encoding Revision: 00 Title: Encoding and Transport of (Pre-)Congestion Information from within a DiffServ Domain to the Egress Creation_date: 2008-05-15 WG ID: Independent Submission Number_of_pages: 10 Abstract: Pre-congestion notification (PCN) is a mechanism designed to protect the Quality of Service of inelastic flows. It does this by marking packets when traffic load on a link is approaching or has exceeded a threshold below the physical link rate. This document specifies how such marks are to be encoded into the IP header. The baseline encoding described here provides for two PCN encoding states. Status This memo is posted as an Internet-Draft with an intent to eventually progress to standards track. The IETF Secretariat. _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed May 21 03:30:12 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F3D93A6A1F; Wed, 21 May 2008 03:30:12 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 536F03A6A1F for ; Wed, 21 May 2008 03:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.56 X-Spam-Level: X-Spam-Status: No, score=-0.56 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9tyClOYkTji for ; Wed, 21 May 2008 03:30:10 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id CD54F3A67DB for ; Wed, 21 May 2008 03:30:09 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Wed, 21 May 2008 12:30:10 +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, 21 May 2008 12:30:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 May 2008 12:32:35 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C013E4CB4@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New Version Notification fordraft-moncaster-pcn-baseline-encoding-00 thread-index: Aci2n45ClKpoTZ+pRHadFns300LwjQAAARxwASBbfeA= References: From: "Geib, Ruediger" To: X-OriginalArrivalTime: 21 May 2008 10:30:10.0203 (UTC) FILETIME=[A5589EB0:01C8BB2D] Cc: pcn@ietf.org Subject: Re: [PCN] New Version Notification fordraft-moncaster-pcn-baseline-encoding-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Toby, thanks for your draft, which specifies the basic PCN encoding pretty well. A few minor comments below. Regards, Rudiger -------------------------------------------------- Minor: Section 4. Encoding two PCN states in IP first bullet point ...."To conserve DSCPs, DiffServ Codepoints SHOULD be chosen that are already defined for use with admission controlled traffic, such as the Voice-Admit codepoint defined in [voice-admit]." [RG] Not-PCN combined with Voice-Admit then means that a domain supports another admission control scheme than PCN in the backbone? But may make sense if a flow passes different domains and some of them don't support PCN. --------------------------------------------------- Minor: 4.2. PCN-Enabled DiffServ Codepoints Second section, second sentence ...."The scheduling behaviour used for a packet does not change whether PCN is enabled for a DSCP or not and whatever the setting of the ECN field." [RG] I'm not sure that understand what you mean. Could you explain this with a few mor stetements? --------------------------------------------------- Editorials: - suggest to change "Two" in some lines to "two". - replace "PCN region" by "PCN domain" (compliant with architecture terminology). - Some mor words to the following of bullet points of 4.3. o PCN interior nodes that are in a pre-congestion state above the configured level MUST set the PM codepoint by changing the ECN bits of NM marked packets to 11. ^^^^^^^^^^^^ o The PM codepoint MUST NOT be changed to NM. ^^^ ^^^^^^^^^ | -----Original Message----- | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | Behalf Of toby.moncaster@bt.com | Sent: Thursday, May 15, 2008 5:32 PM | To: pcn@ietf.org | Subject: [PCN] FW: New Version Notification | fordraft-moncaster-pcn-baseline-encoding-00 | | | | Hi All, | | I have just posted an initial attempt at a standards track | encoding document to allow two PCN encoding states (as agreed | in the voting on this list). I have included Michael Menth | and Bob Briscoe as authors on this as it is based on the work | we all did at the last IETF. | | Please can people try and read this and let me have any | comments. The key aim of the document is to specify the | baseline encoding in such a manner that it allows the | experimental extension (with three encoding | states) to exist without contradiction. It achieves this by | splitting the behaviour into core behaviour, behaviour at | edge nodes and behaviour at interior nodes. | | I am currently trying to finish writing the initial draft for | the experimental extension to three encoding states. I am | having some difficulty putting it in clear English but hope | to be able to post an early version next week. | | Ideally I am hoping that we can get at least this baseline | encoding accepted as a WG document by early June and can get | it into WGLC before the Dublin IETF. | | Toby | | ____________________________________________________________________ | Toby Moncaster, Networks Research | Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 | 1473 648734 | | -----Original Message----- | From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] | Sent: 15 May 2008 16:23 | To: Moncaster,T,Toby,CXR9 R | Cc: Briscoe,RJ,Bob,CXR9 R; menth@informatik.uni-wuerzburg.de | Subject: New Version Notification for | draft-moncaster-pcn-baseline-encoding-00 | | | A new version of I-D, draft-moncaster-pcn-baseline-encoding-00.txt has | been successfuly submitted by T Moncaster and posted to the IETF | repository. | | Filename: draft-moncaster-pcn-baseline-encoding | Revision: 00 | Title: Encoding and Transport of | (Pre-)Congestion Information | from within a DiffServ Domain to the Egress | Creation_date: 2008-05-15 | WG ID: Independent Submission | Number_of_pages: 10 | | Abstract: | Pre-congestion notification (PCN) is a mechanism designed to protect | the Quality of Service of inelastic flows. It does this by marking | packets when traffic load on a link is approaching or has exceeded a | threshold below the physical link rate. This document specifies how | such marks are to be encoded into the IP header. The baseline | encoding described here provides for two PCN encoding states. | | Status | | This memo is posted as an Internet-Draft with an intent to eventually | progress to standards track. | | | | | The IETF Secretariat. | | | _______________________________________________ | PCN mailing list | PCN@ietf.org | https://www.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed May 21 05:41:24 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03FF43A6A44; Wed, 21 May 2008 05:41:24 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E13C228C204 for ; Wed, 21 May 2008 05:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.015 X-Spam-Level: X-Spam-Status: No, score=0.015 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0SDYPSf3GzW for ; Wed, 21 May 2008 05:41:17 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id BD9113A6A6E for ; Wed, 21 May 2008 05:41:16 -0700 (PDT) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 May 2008 13:41:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 May 2008 13:41:00 +0100 Message-ID: In-Reply-To: <1B6169C658325341A3B8066E23919E1C013E4CB4@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New Version Notification fordraft-moncaster-pcn-baseline-encoding-00 Thread-Index: Aci2n45ClKpoTZ+pRHadFns300LwjQAAARxwASBbfeAAB7Hs0A== From: To: X-OriginalArrivalTime: 21 May 2008 12:41:19.0151 (UTC) FILETIME=[F79ACBF0:01C8BB3F] Cc: pcn@ietf.org Subject: Re: [PCN] New Version Notification fordraft-moncaster-pcn-baseline-encoding-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ruediger, Thanks for the comments. I will incorporate them in my next revision (which will come out in early June). Responses to the two minor points are inline below... Toby > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 21 May 2008 11:33 > To: Moncaster,T,Toby,CXR9 R > Cc: pcn@ietf.org > Subject: RE: [PCN] New Version Notification > fordraft-moncaster-pcn-baseline-encoding-00 > > Hi Toby, > > thanks for your draft, which specifies the basic PCN encoding > pretty well. A few minor comments below. > > Regards, > > Rudiger > > -------------------------------------------------- > > Minor: Section 4. Encoding two PCN states in IP > > first bullet point > ...."To conserve DSCPs, DiffServ Codepoints > SHOULD be chosen that are already defined for use > with admission controlled traffic, such as the > Voice-Admit codepoint defined in [voice-admit]." > > [RG] Not-PCN combined with Voice-Admit then means that > a domain supports another admission control scheme > than PCN in the backbone? But may make sense if a > flow passes different domains and some of them don't > support PCN. Basically this is in order to facillitate the re-use of the Voice-admit codepoint. It also allows for the possibility that some traffic might wish to get the same scheduling and forwarding treatment as PCN but not be admission controlled in a PCN-like fashion. In practise it is (very?) likely that in a single DiffServ domain traffic like this would actually be moved to a different class (possibly receiving similar treatment) as otherwise the PCN marking algorithms would have to take account of the presence of this extra traffic. > > --------------------------------------------------- > > Minor: 4.2. PCN-Enabled DiffServ Codepoints > > Second section, second sentence > > ...."The scheduling behaviour used for a packet > does not change whether PCN is enabled for a DSCP or > not and whatever the setting of the ECN field." > > [RG] I'm not sure that understand what you mean. Could > you explain this with a few mor stetements? > > --------------------------------------------------- > OK, this came from an edit by Bob Briscoe. Essentially what it means is that PCN is not a scheduling behaviour and thus whether or not PCN is enabled for a DSCP doesn't affect what scheduling behaviour is applied to that DSCP (which scheduling behaviour to use for the PCN enabvled DSCP is an issue that will be specified elsewhere). Equally, within any DSCP, the value of the ECN bits has no affect on what scheduling behaviour it receives. This point is (obviosuly) related to the above point on the Not PCN class. > > Editorials: > > - suggest to change "Two" in some lines to "two". > - replace "PCN region" by "PCN domain" (compliant with > architecture terminology). > - Some mor words to the following of bullet points of 4.3. > > o PCN interior nodes that are in a pre-congestion state above the > configured level MUST set the PM codepoint by changing the ECN > bits of NM marked packets to 11. > ^^^^^^^^^^^^ > o The PM codepoint MUST NOT be changed to NM. > ^^^ ^^^^^^^^^ > > > | -----Original Message----- > | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > | Behalf Of toby.moncaster@bt.com > | Sent: Thursday, May 15, 2008 5:32 PM > | To: pcn@ietf.org > | Subject: [PCN] FW: New Version Notification > | fordraft-moncaster-pcn-baseline-encoding-00 > | > | > | > | Hi All, > | > | I have just posted an initial attempt at a standards track > | encoding document to allow two PCN encoding states (as agreed > | in the voting on this list). I have included Michael Menth > | and Bob Briscoe as authors on this as it is based on the work > | we all did at the last IETF. > | > | Please can people try and read this and let me have any > | comments. The key aim of the document is to specify the > | baseline encoding in such a manner that it allows the > | experimental extension (with three encoding > | states) to exist without contradiction. It achieves this by > | splitting the behaviour into core behaviour, behaviour at > | edge nodes and behaviour at interior nodes. > | > | I am currently trying to finish writing the initial draft for > | the experimental extension to three encoding states. I am > | having some difficulty putting it in clear English but hope > | to be able to post an early version next week. > | > | Ideally I am hoping that we can get at least this baseline > | encoding accepted as a WG document by early June and can get > | it into WGLC before the Dublin IETF. > | > | Toby > | > | ____________________________________________________________________ > | Toby Moncaster, Networks Research > | Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 > | 1473 648734 > | > | -----Original Message----- > | From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > | Sent: 15 May 2008 16:23 > | To: Moncaster,T,Toby,CXR9 R > | Cc: Briscoe,RJ,Bob,CXR9 R; menth@informatik.uni-wuerzburg.de > | Subject: New Version Notification for > | draft-moncaster-pcn-baseline-encoding-00 > | > | > | A new version of I-D, > draft-moncaster-pcn-baseline-encoding-00.txt has > | been successfuly submitted by T Moncaster and posted to the IETF > | repository. > | > | Filename: draft-moncaster-pcn-baseline-encoding > | Revision: 00 > | Title: Encoding and Transport of > | (Pre-)Congestion Information > | from within a DiffServ Domain to the Egress > | Creation_date: 2008-05-15 > | WG ID: Independent Submission > | Number_of_pages: 10 > | > | Abstract: > | Pre-congestion notification (PCN) is a mechanism designed to protect > | the Quality of Service of inelastic flows. It does this by marking > | packets when traffic load on a link is approaching or has exceeded a > | threshold below the physical link rate. This document specifies how > | such marks are to be encoded into the IP header. The baseline > | encoding described here provides for two PCN encoding states. > | > | Status > | > | This memo is posted as an Internet-Draft with an intent to > eventually > | progress to standards track. > | > | > | > | > | The IETF Secretariat. > | > | > | _______________________________________________ > | PCN mailing list > | PCN@ietf.org > | https://www.ietf.org/mailman/listinfo/pcn > | > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed May 21 20:32:52 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05DD43A688B; Wed, 21 May 2008 20:32:52 -0700 (PDT) X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 2106E3A6914; Wed, 21 May 2008 20:32:49 -0700 (PDT) From: Steven Blake(IETF PCN WG) To: Tina Tsou Mime-Version: 1.0 Message-Id: <20080522033250.2106E3A6914@core3.amsl.com> Date: Wed, 21 May 2008 20:32:50 -0700 (PDT) Cc: Monique Morrow , IETF PCN mailing list Subject: [PCN] New Liaison Statement, "IETF PCN Working Group Response to Liaison Statement TD 1653R2 (Plen/11) from ITU-T Study Group 11" X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Steven Blake , Scott Bradner List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Title: IETF PCN Working Group Response to Liaison Statement TD 1653R2 (Plen/11) from ITU-T Study Group 11 Submission Date: 2008-05-21 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=454 From: Steven Blake(IETF PCN WG) To: ITU-T/Study Group 11(Tina Tsou ) Cc: IETF PCN mailing list Lars Eggert Magnus Westerlund Monique Morrow Reponse Contact: Steven Blake Scott Bradner Technical Contact: IETF PCN mailing list Purpose: In response Body: To: ITU-T Study Group 11 Thank you for your liaison from your Seoul meeting on your intent to utilize PCN in a RACF-controlled environment. At this time, key details of the PCN architecture, such as packet encoding, interior node marking behaviors, and edge node computations and communication flows, still remain to be decided. Hence we recommend that the ITU-T proceed cautiously in any work that depends on the emerging PCN architecture. We encourage you to continue monitoring developments in the PCN working group, and to keep us informed as you investigate the requirements of using the IETF PCN architecture and protocols in a RACF-controlled environment. Thank you, Scott Bradner and Steven Blake, PCN working group co-chairs Attachment(s): No document has been attached _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon May 26 00:56:44 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7812D3A6997; Mon, 26 May 2008 00:56:44 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B493A6997 for ; Mon, 26 May 2008 00:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.989 X-Spam-Level: X-Spam-Status: No, score=-5.989 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43aRhoHwlz2P for ; Mon, 26 May 2008 00:56:35 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A6E513A68F0 for ; Mon, 26 May 2008 00:56:35 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 44E0620BB2 for ; Mon, 26 May 2008 09:56:36 +0200 (CEST) X-AuditID: c1b4fb3c-ac097bb00000193b-27-483a6d340f11 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 28F0120786 for ; Mon, 26 May 2008 09:56:36 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 May 2008 09:56:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 May 2008 09:56:35 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0507A3658A@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Usecases and Benefits of end to end ECN support in PCN Domains thread-index: Aci/BgS+mBrVjG4oT6i16mRqkD9SDg== From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 26 May 2008 07:56:36.0061 (UTC) FILETIME=[055AE0D0:01C8BF06] X-Brightmail-Tracker: AAAAAA== Subject: [PCN] Usecases and Benefits of end to end ECN support in PCN Domains X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi The ECN-PCN usecases draft has been updated. The main addition is the secti= on 3.5 suggested by Ken Carlberg. http://tools.ietf.org/id/draft-sarker-pcn-ecn-pcn-usecases-01.txt Comments are welcome /Ingemar ******************************************* = Ingemar Johansson = Senior Research Engineer, IETF "nethead" = EAB/TVP - Multimedia Technologies = Ericsson Research Ericsson AB = Box 920 S-971 28 Lule=E5, Sweden = Tel: +46 (0)8 4043042 = ECN: 850-43042 = ECC: 850-43074 = Mobile: +46 (0)730 783289 = ******************************************* = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon May 26 23:56:22 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C99D3A6C23; Mon, 26 May 2008 23:56:22 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AC743A6C23 for ; Mon, 26 May 2008 23:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxDu6WQohRXu for ; Mon, 26 May 2008 23:56:21 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id A5FF93A6B64 for ; Mon, 26 May 2008 23:56:20 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so1561396fga.41 for ; Mon, 26 May 2008 23:56:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=+DrdxV3pQPm6gkgjGNF/+YrUt99VCr0ov3TKO9TO35Q=; b=QHOUTOR8iD8CYXK902QEvsLtJNWhf0fjyeaLzQX9xUak8AXa0X6eiYoNTLS/vA3XZGL8iREIeJ0mruGxRQXXi1eSaF2AOKpeQdk4wwElA6hvOe4yXrXBGZIOSO6+xGccmA0/pji5clnXHKRO/Om42GIs9DNd/AZ47BOJFGFC0uk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=E+i8vn5fC9XQshbkNI/+3EAYZohEW8dGjEjAIJaa+xAVoloW3lrTJ3N813MtXEQWiIssXjRA15I8U1LygOfKA3pddPhxYagLIY7ai0jBtlC8fdHnbyH/I3S77PjZsk0J08row53RzVwfNLEZPiO4yucKWYoj5wzyMRT3/it24Rk= Received: by 10.86.89.1 with SMTP id m1mr2890779fgb.20.1211871382696; Mon, 26 May 2008 23:56:22 -0700 (PDT) Received: by 10.86.77.2 with HTTP; Mon, 26 May 2008 23:56:22 -0700 (PDT) Message-ID: Date: Tue, 27 May 2008 08:56:22 +0200 From: "Mayutan A." To: "Ingemar Johansson S" In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0507A3658A@esealmw109.eemea.ericsson.se> MIME-Version: 1.0 References: <026F8EEDAD2C4342A993203088C1FC0507A3658A@esealmw109.eemea.ericsson.se> Cc: pcn@ietf.org Subject: Re: [PCN] Usecases and Benefits of end to end ECN support in PCN Domains X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2136031967==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org --===============2136031967== Content-Type: multipart/alternative; boundary="----=_Part_1269_7670516.1211871382687" ------=_Part_1269_7670516.1211871382687 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi My two cents: Since PCN is defined for inelastic traffic, when an adaptive application is denied admission, it can adapt its sending rate and try again. This is similar to the application receiving a congestion marked packet and therefore lowering its rate (for e.g a video streaming application lowering the quality or the video streamed). Eventually the PCN aims at end-to-end deployment and thus favour= s adaptive applications. Mayutan On Mon, May 26, 2008 at 9:56 AM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Hi > > The ECN-PCN usecases draft has been updated. The main addition is the > section 3.5 suggested by Ken Carlberg. > http://tools.ietf.org/id/draft-sarker-pcn-ecn-pcn-usecases-01.txt > > Comments are welcome > /Ingemar > ******************************************* > Ingemar Johansson > Senior Research Engineer, IETF "nethead" > EAB/TVP - Multimedia Technologies > Ericsson Research Ericsson AB > Box 920 S-971 28 Lule=E5, Sweden > Tel: +46 (0)8 4043042 > ECN: 850-43042 > ECC: 850-43074 > Mobile: +46 (0)730 783289 > ******************************************* > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > --=20 Mayutan Arumaithurai 0049-551-2712647 (Home number) 0049-176-20322049 (mobile number) ------=_Part_1269_7670516.1211871382687 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi
My two cents:

Since PCN is defined for inelastic traffic, whe= n an adaptive application is denied admission, it can adapt its sending rat= e and try again. This is similar to the application
receiving a congesti= on marked packet and therefore lowering its rate (for e.g a video streaming= application lowering the quality or the video streamed). Eventually the PC= N aims at end-to-end deployment and thus favours adaptive applications.&nbs= p;

Mayutan

On Mon, May 26, 2008 at 9:56 = AM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
Hi

The ECN-PCN usecases draft has been updated. The main addition is the secti= on 3.5 suggested by Ken Carlberg.
http://tools.ietf.org/id/draft-sarker-pcn-ecn-pcn-usec= ases-01.txt

Comments are welcome
/Ingemar
*******************************************
Ingemar Johansson
Senior Research Engineer, IETF "nethead"
EAB/TVP - Multimedia Technologies
Ericsson Research Ericsson AB
Box 920 S-971 28 Lule=E5, Sweden
Tel: +46 (0)8 4043042
ECN: 850-43042
ECC: 850-43074
Mobile: +46 (0)730 783289
*******************************************
_______________________________________________
PCN mailing list
PCN@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pcn



--
Mayutan Arumaithurai0049-551-2712647 (Home number)
0049-176-20322049 (mobile number) ------=_Part_1269_7670516.1211871382687-- --===============2136031967== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============2136031967==-- From pcn-bounces@ietf.org Tue May 27 00:03:50 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C143A67B3; Tue, 27 May 2008 00:03:50 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C6D43A67A1 for ; Tue, 27 May 2008 00:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sukH3Qh0DNe1 for ; Tue, 27 May 2008 00:03:44 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id AE6663A67CF for ; Tue, 27 May 2008 00:03:43 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 7D20DA0602; Tue, 27 May 2008 09:03:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 70666A05FA; Tue, 27 May 2008 09:03:47 +0200 (CEST) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 2E688A05E0; Tue, 27 May 2008 09:03:45 +0200 (CEST) Message-ID: <483BB224.2080900@informatik.uni-wuerzburg.de> Date: Tue, 27 May 2008 09:03:00 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Mayutan A." References: <026F8EEDAD2C4342A993203088C1FC0507A3658A@esealmw109.eemea.ericsson.se> In-Reply-To: X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Usecases and Benefits of end to end ECN support in PCN Domains X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Mayutan, it's similar, but not the same. While ECN allows rate adaptation for = flows in progress, your alternative allows it only for flows that are = not yet permitted. An end-to-end deployment of PCN is not within the = current charter. Regards, Michael Mayutan A. wrote: > Hi > My two cents: > > Since PCN is defined for inelastic traffic, when an adaptive = > application is denied admission, it can adapt its sending rate and try = > again. This is similar to the application > receiving a congestion marked packet and therefore lowering its rate = > (for e.g a video streaming application lowering the quality or the = > video streamed). Eventually the PCN aims at end-to-end deployment and = > thus favours adaptive applications. = > > Mayutan > > On Mon, May 26, 2008 at 9:56 AM, Ingemar Johansson S = > > wrote: > > Hi > > The ECN-PCN usecases draft has been updated. The main addition is > the section 3.5 suggested by Ken Carlberg. > http://tools.ietf.org/id/draft-sarker-pcn-ecn-pcn-usecases-01.txt > > Comments are welcome > /Ingemar > ******************************************* > Ingemar Johansson > Senior Research Engineer, IETF "nethead" > EAB/TVP - Multimedia Technologies > Ericsson Research Ericsson AB > Box 920 S-971 28 Lule=E5, Sweden > Tel: +46 (0)8 4043042 > ECN: 850-43042 > ECC: 850-43074 > Mobile: +46 (0)730 783289 > ******************************************* > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > > > > > -- = > Mayutan Arumaithurai > 0049-551-2712647 (Home number) > 0049-176-20322049 (mobile number) > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > = -- = Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue May 27 01:30:33 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 575D43A6C24; Tue, 27 May 2008 01:30:33 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0CA63A6853 for ; Tue, 27 May 2008 01:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.018 X-Spam-Level: X-Spam-Status: No, score=-6.018 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHpDFR+1Zu9n for ; Tue, 27 May 2008 01:30:31 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 551BD28C210 for ; Tue, 27 May 2008 01:30:31 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B1D1F215D8; Tue, 27 May 2008 10:30:34 +0200 (CEST) X-AuditID: c1b4fb3e-ab192bb000004ec0-04-483bc6aa3a24 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8CE5C2164B; Tue, 27 May 2008 10:30:34 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 May 2008 10:30:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 May 2008 10:30:33 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0507A6CF4E@esealmw109.eemea.ericsson.se> In-Reply-To: <483BB224.2080900@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Usecases and Benefits of end to end ECN support in PCN Domains thread-index: Aci/x8/LHHNtFGorQxqJhYu6pIpFTAAC5+ow References: <026F8EEDAD2C4342A993203088C1FC0507A3658A@esealmw109.eemea.ericsson.se> <483BB224.2080900@informatik.uni-wuerzburg.de> From: "Ingemar Johansson S" To: , "Mayutan A." X-OriginalArrivalTime: 27 May 2008 08:30:34.0289 (UTC) FILETIME=[EEA58A10:01C8BFD3] X-Brightmail-Tracker: AAAAAA== Cc: pcn@ietf.org Subject: Re: [PCN] Usecases and Benefits of end to end ECN support in PCN Domains X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Agree with Michael, the use case below sounds in my opinion like something = that is done during the session setup and with interaction between the clie= nt and the admission control scheme, I don't believe that ECN can be used f= or this purpose as there is no flow running. /Ingemar > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] = > Sent: den 27 maj 2008 09:03 > To: Mayutan A. > Cc: Ingemar Johansson S; pcn@ietf.org > Subject: Re: [PCN] Usecases and Benefits of end to end ECN = > support in PCN Domains > = > Hi Mayutan, > = > it's similar, but not the same. While ECN allows rate = > adaptation for flows in progress, your alternative allows it = > only for flows that are not yet permitted. An end-to-end = > deployment of PCN is not within the current charter. > = > Regards, > = > Michael > = > Mayutan A. wrote: > > Hi > > My two cents: > > > > Since PCN is defined for inelastic traffic, when an adaptive = > > application is denied admission, it can adapt its sending = > rate and try = > > again. This is similar to the application receiving a congestion = > > marked packet and therefore lowering its rate (for e.g a video = > > streaming application lowering the quality or the video streamed). = > > Eventually the PCN aims at end-to-end deployment and thus favours = > > adaptive applications. > > > > Mayutan > > > > On Mon, May 26, 2008 at 9:56 AM, Ingemar Johansson S = > > > > wrote: > > > > Hi > > > > The ECN-PCN usecases draft has been updated. The main = > addition is > > the section 3.5 suggested by Ken Carlberg. > > = > http://tools.ietf.org/id/draft-sarker-pcn-ecn-pcn-usecases-01.txt > > > > Comments are welcome > > /Ingemar > > ******************************************* > > Ingemar Johansson > > Senior Research Engineer, IETF "nethead" > > EAB/TVP - Multimedia Technologies > > Ericsson Research Ericsson AB > > Box 920 S-971 28 Lule=E5, Sweden > > Tel: +46 (0)8 4043042 > > ECN: 850-43042 > > ECC: 850-43074 > > Mobile: +46 (0)730 783289 > > ******************************************* > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > > > > > > > > > -- > > Mayutan Arumaithurai > > 0049-551-2712647 (Home number) > > 0049-176-20322049 (mobile number) > > = > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > = > = > -- > Dr. Michael Menth, Assistant Professor > University of Wuerzburg, Institute of Computer Science Am = > Hubland, D-97074 Wuerzburg, Germany, room B206 > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 = > mailto:menth@informatik.uni-wuerzburg.de > http://www3.informatik.uni-wuerzburg.de/research/ngn > = > = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue May 27 04:48:32 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15CFD3A69A8; Tue, 27 May 2008 04:48:32 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB6A53A69A8 for ; Tue, 27 May 2008 04:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5-xzyxU0f9M for ; Tue, 27 May 2008 04:48:29 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 98CD33A68CE for ; Tue, 27 May 2008 04:48:27 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so1615252fga.41 for ; Tue, 27 May 2008 04:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=RIKMZw+etmmVv7wQFhICpxV54VYRrJz45EW6BjOmxDo=; b=oii0S7kjLi8Ga6CUiX1Y4KF9x9G20vh7Zl3mZLevtDH4wzfbCgEm/LrhVagqyz5PJXEC6zCKoD6vNsYj0dnmAyq72eqJjFppj58msylFHYJ6kiTZhGgIiv9KUGYTmVRJCfnwkAO8g15+RXSZYjbnua7auSHfN44DoMLmsbS9qwI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=eN0pmZL+UjapRHYmgejOrGxEni9JOw/1nzUW5AaaiYstJ4YEaEeDqxNUnRZRa8ibK+KjmzKljRLQWp80LPtJscgUpwiNm2F6haDdhrFuPF2vtrQ/t4bh/PtlpE5WKM+HmgrWfsquylU5IArdDwHcf30CtHHcP8sNBcZ5nHLeuYk= Received: by 10.86.78.4 with SMTP id a4mr1689167fgb.17.1211888911878; Tue, 27 May 2008 04:48:31 -0700 (PDT) Received: by 10.86.77.2 with HTTP; Tue, 27 May 2008 04:48:31 -0700 (PDT) Message-ID: Date: Tue, 27 May 2008 13:48:31 +0200 From: "Mayutan A." To: "Ingemar Johansson S" In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0507A6CF4E@esealmw109.eemea.ericsson.se> MIME-Version: 1.0 References: <026F8EEDAD2C4342A993203088C1FC0507A3658A@esealmw109.eemea.ericsson.se> <483BB224.2080900@informatik.uni-wuerzburg.de> <026F8EEDAD2C4342A993203088C1FC0507A6CF4E@esealmw109.eemea.ericsson.se> Cc: pcn@ietf.org Subject: Re: [PCN] Usecases and Benefits of end to end ECN support in PCN Domains X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1962157436==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org --===============1962157436== Content-Type: multipart/alternative; boundary="----=_Part_1968_14414445.1211888911868" ------=_Part_1968_14414445.1211888911868 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, Thanks Michael and Ingemar, I get the difference now. I was talking about UDP applications trying to get some acceptable QoS during connection setup, whereas the draft proposal discusses about applications that can adapt on the fly depending on the congestion in the network. The point I was making is that in a PCN domain, once an application flow is admitted, the domain ensures that it provides all accepted flows with a guaranteed QoS as long as there aren't any unexpected node/link failures. But I agree that during the initial stages when not many domains are PCN capable, the adaptive applications can play a part in adapting its rate on receiving ECN marked packets and adjusting accordingly. Cheers, Mayutan On Tue, May 27, 2008 at 10:30 AM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Hi > > Agree with Michael, the use case below sounds in my opinion like somethin= g > that is done during the session setup and with interaction between the > client and the admission control scheme, I don't believe that ECN can be > used for this purpose as there is no flow running. > > /Ingemar > > > -----Original Message----- > > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > Sent: den 27 maj 2008 09:03 > > To: Mayutan A. > > Cc: Ingemar Johansson S; pcn@ietf.org > > Subject: Re: [PCN] Usecases and Benefits of end to end ECN > > support in PCN Domains > > > > Hi Mayutan, > > > > it's similar, but not the same. While ECN allows rate > > adaptation for flows in progress, your alternative allows it > > only for flows that are not yet permitted. An end-to-end > > deployment of PCN is not within the current charter. > > > > Regards, > > > > Michael > > > > Mayutan A. wrote: > > > Hi > > > My two cents: > > > > > > Since PCN is defined for inelastic traffic, when an adaptive > > > application is denied admission, it can adapt its sending > > rate and try > > > again. This is similar to the application receiving a congestion > > > marked packet and therefore lowering its rate (for e.g a video > > > streaming application lowering the quality or the video streamed). > > > Eventually the PCN aims at end-to-end deployment and thus favours > > > adaptive applications. > > > > > > Mayutan > > > > > > On Mon, May 26, 2008 at 9:56 AM, Ingemar Johansson S > > > > > > wrote: > > > > > > Hi > > > > > > The ECN-PCN usecases draft has been updated. The main > > addition is > > > the section 3.5 suggested by Ken Carlberg. > > > > > http://tools.ietf.org/id/draft-sarker-pcn-ecn-pcn-usecases-01.txt > > > > > > Comments are welcome > > > /Ingemar > > > ******************************************* > > > Ingemar Johansson > > > Senior Research Engineer, IETF "nethead" > > > EAB/TVP - Multimedia Technologies > > > Ericsson Research Ericsson AB > > > Box 920 S-971 28 Lule=E5, Sweden > > > Tel: +46 (0)8 4043042 > > > ECN: 850-43042 > > > ECC: 850-43074 > > > Mobile: +46 (0)730 783289 > > > ******************************************* > > > _______________________________________________ > > > PCN mailing list > > > PCN@ietf.org > > > https://www.ietf.org/mailman/listinfo/pcn > > > > > > > > > > > > > > > -- > > > Mayutan Arumaithurai > > > 0049-551-2712647 (Home number) > > > 0049-176-20322049 (mobile number) > > > > > ---------------------------------------------------------------------- > > > -- > > > > > > _______________________________________________ > > > PCN mailing list > > > PCN@ietf.org > > > https://www.ietf.org/mailman/listinfo/pcn > > > > > > > -- > > Dr. Michael Menth, Assistant Professor > > University of Wuerzburg, Institute of Computer Science Am > > Hubland, D-97074 Wuerzburg, Germany, room B206 > > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > > mailto:menth@informatik.uni-wuerzburg.de > > http://www3.informatik.uni-wuerzburg.de/research/ngn > > > > > --=20 Mayutan Arumaithurai 0049-551-2712647 (Home number) 0049-176-20322049 (mobile number) ------=_Part_1968_14414445.1211888911868 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi,

Thanks Michael and Ingemar, I get the difference now. I was tal= king about UDP applications trying to get some acceptable QoS during connec= tion setup, whereas the draft proposal discusses about applications that ca= n adapt on the fly depending on the congestion in the network. The point I = was making is that in a PCN domain, once an application flow is admitted, t= he domain ensures that it provides all accepted flows with a guaranteed  QoS as long as there aren't any unexpected node/link failures.

= But I agree that during the initial stages when not many domains are PCN ca= pable, the adaptive applications can play a part in adapting its rate on re= ceiving ECN marked packets and adjusting accordingly.

Cheers,
Mayutan



On Tue, M= ay 27, 2008 at 10:30 AM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
Hi

Agree with Michael, the use case below sounds in my opinion like something = that is done during the session setup and with interaction between the clie= nt and the admission control scheme, I don't believe that ECN can be us= ed for this purpose as there is no flow running.

/Ingemar

> -----Original Message-----
> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]
> Sent: den 27 maj 2008 09:03
> To: Mayutan A.
> Cc: Ingemar Johansson S; pcn@ietf.org<= /a>
> Subject: Re: [PCN] Usecases and Benefits of end to end ECN
> support in PCN Domains
>
> Hi Mayutan,
>
> it's similar, but not the same. While ECN allows rate
> adaptation for flows in progress, your alternative allows it
> only for flows that are not yet permitted. An end-to-end
> deployment of PCN is not within the current charter.
>
> Regards,
>
>     Michael
>
> Mayutan A. wrote:
> > Hi
> > My two cents:
> >
> > Since PCN is defined for inelastic traffic, when an adaptive
> > application is denied admission, it can adapt its sending
> rate and try
> > again. This is similar to the application receiving a congestion<= br> > > marked packet and therefore lowering its rate (for e.g a video > > streaming application lowering the quality or the video streamed)= .
> > Eventually the PCN aims at end-to-end deployment and thus favours=
> > adaptive applications.
> >
> > Mayutan
> >
> > On Mon, May 26, 2008 at 9:56 AM, Ingemar Johansson S
> > <ingemar.s= .johansson@ericsson.com
> > <mailto:in= gemar.s.johansson@ericsson.com>> wrote:
> >
> >     Hi
> >
> >     The ECN-PCN usecases draft has been updated. The ma= in
> addition is
> >     the section 3.5 suggested by Ken Carlberg.
> >
> http://tools.ietf.org/id/draft-sarker-pcn-ecn-pcn= -usecases-01.txt
> >
> >     Comments are welcome
> >     /Ingemar
> >     *******************************************
> >     Ingemar Johansson
> >     Senior Research Engineer, IETF "nethead"<= br> > >     EAB/TVP - Multimedia Technologies
> >     Ericsson Research Ericsson AB
> >     Box 920 S-971 28 Lule=E5, Sweden
> >     Tel: +46 (0)8 4043042
> >     ECN: 850-43042
> >     ECC: 850-43074
> >     Mobile: +46 (0)730 783289
> >     *******************************************
> >     _______________________________________________
> >     PCN mailing list
> >     PCN@ietf.org &l= t;mailto:PCN@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/pcn
> >
> >
> >
> >
> > --
> > Mayutan Arumaithurai
> > 0049-551-2712647 (Home number)
> > 0049-176-20322049 (mobile number)
> >
> ----------------------------------------------------------------------=
> > --
> >
> > _______________________________________________
> > PCN mailing list
> > PCN@ietf.org
> > https://www.ietf.org/mailman/listinfo/pcn
> >
>
> --
> Dr. Michael Menth, Assistant Professor
> University of Wuerzburg, Institute of Computer Science Am
> Hubland, D-97074 Wuerzburg, Germany, room B206
> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
> mailto:menth@info= rmatik.uni-wuerzburg.de
> http://www3.informatik.uni-wuerzburg.de/research/ngn
>
>



--
Mayutan Aru= maithurai
0049-551-2712647 (Home number)
0049-176-20322049 (mobile n= umber) ------=_Part_1968_14414445.1211888911868-- --===============1962157436== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1962157436==-- From pcn-bounces@ietf.org Tue May 27 08:04:21 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61E7C3A69C5; Tue, 27 May 2008 08:04:21 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74C143A693E for ; Tue, 27 May 2008 08:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tKwS-OvzhtA for ; Tue, 27 May 2008 08:04:19 -0700 (PDT) Received: from mta2.dhs.gov (mta2.dhs.gov [152.121.181.37]) by core3.amsl.com (Postfix) with ESMTP id 71ED33A69C5 for ; Tue, 27 May 2008 08:04:18 -0700 (PDT) Received: from dhsmail1.dhs.gov (dhsmail1.dhs.gov [161.214.63.26]) by mta2.dhs.gov with ESMTP; Tue, 27 May 2008 11:04:22 -0400 Received: from dhsmail1.dhs.gov (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0B26E22ED; Tue, 27 May 2008 11:04:22 -0400 (EDT) Received: from ZAS1UG-0361.DHSNET.DS1.DHS (unknown [10.79.65.246]) by dhsmail1.dhs.gov (Postfix) with ESMTP id CA1392215; Tue, 27 May 2008 11:04:21 -0400 (EDT) Received: from ZAU1UG-0316.DHSNET.DS1.DHS ([10.79.65.217]) by ZAS1UG-0361.DHSNET.DS1.DHS with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 May 2008 11:04:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 May 2008 11:04:21 -0400 Message-Id: <78DDCF1918AA074CAD06EC3052B2DB1A71BCB5@ZAU1UG-0316.DHSNET.DS1.DHS> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Usecases and Benefits of end to end ECN support in PCNDomains Thread-Index: Aci/76NBsGOOgjUCT7250BjdS1aX4QAGqssg From: "Nguyen, An P" To: "Mayutan A." X-OriginalArrivalTime: 27 May 2008 15:04:22.0134 (UTC) FILETIME=[F1F09160:01C8C00A] Cc: pcn@ietf.org Subject: Re: [PCN] Usecases and Benefits of end to end ECN support in PCNDomains X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1075055104==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1075055104== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C00A.F1BF7B3A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8C00A.F1BF7B3A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mayutan, =20 Just a question for you: Would accepted flows with a guaranteed QoS get = rerouted in a PCN domain if there is a node/link failure? =20 Thanks, =20 An =20 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Mayutan A. Sent: Tuesday, May 27, 2008 7:49 AM To: Ingemar Johansson S Cc: pcn@ietf.org Subject: Re: [PCN] Usecases and Benefits of end to end ECN support in = PCNDomains =20 Hi,=20 Thanks Michael and Ingemar, I get the difference now. I was talking = about UDP applications trying to get some acceptable QoS during = connection setup, whereas the draft proposal discusses about = applications that can adapt on the fly depending on the congestion in = the network. The point I was making is that in a PCN domain, once an = application flow is admitted, the domain ensures that it provides all = accepted flows with a guaranteed QoS as long as there aren't any = unexpected node/link failures.=20 But I agree that during the initial stages when not many domains are PCN = capable, the adaptive applications can play a part in adapting its rate = on receiving ECN marked packets and adjusting accordingly. Cheers, Mayutan=20 On Tue, May 27, 2008 at 10:30 AM, Ingemar Johansson S = wrote: Hi Agree with Michael, the use case below sounds in my opinion like = something that is done during the session setup and with interaction = between the client and the admission control scheme, I don't believe = that ECN can be used for this purpose as there is no flow running. /Ingemar > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: den 27 maj 2008 09:03 > To: Mayutan A. > Cc: Ingemar Johansson S; pcn@ietf.org > Subject: Re: [PCN] Usecases and Benefits of end to end ECN > support in PCN Domains > > Hi Mayutan, > > it's similar, but not the same. While ECN allows rate > adaptation for flows in progress, your alternative allows it > only for flows that are not yet permitted. An end-to-end > deployment of PCN is not within the current charter. > > Regards, > > Michael > > Mayutan A. wrote: > > Hi > > My two cents: > > > > Since PCN is defined for inelastic traffic, when an adaptive > > application is denied admission, it can adapt its sending > rate and try > > again. This is similar to the application receiving a congestion > > marked packet and therefore lowering its rate (for e.g a video > > streaming application lowering the quality or the video streamed). > > Eventually the PCN aims at end-to-end deployment and thus favours > > adaptive applications. > > > > Mayutan > > > > On Mon, May 26, 2008 at 9:56 AM, Ingemar Johansson S > > > > wrote: > > > > Hi > > > > The ECN-PCN usecases draft has been updated. The main > addition is > > the section 3.5 suggested by Ken Carlberg. > > > http://tools.ietf.org/id/draft-sarker-pcn-ecn-pcn-usecases-01.txt > > > > Comments are welcome > > /Ingemar > > ******************************************* > > Ingemar Johansson > > Senior Research Engineer, IETF "nethead" > > EAB/TVP - Multimedia Technologies > > Ericsson Research Ericsson AB > > Box 920 S-971 28 Lule=E5, Sweden > > Tel: +46 (0)8 4043042 > > ECN: 850-43042 > > ECC: 850-43074 > > Mobile: +46 (0)730 783289 > > ******************************************* > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > > > > > > > > > -- > > Mayutan Arumaithurai > > 0049-551-2712647 (Home number) > > 0049-176-20322049 (mobile number) > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > > > -- > Dr. Michael Menth, Assistant Professor > University of Wuerzburg, Institute of Computer Science Am > Hubland, D-97074 Wuerzburg, Germany, room B206 > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > mailto:menth@informatik.uni-wuerzburg.de > http://www3.informatik.uni-wuerzburg.de/research/ngn > > --=20 Mayutan Arumaithurai 0049-551-2712647 (Home number)=20 0049-176-20322049 (mobile number)=20 ------_=_NextPart_001_01C8C00A.F1BF7B3A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Mayutan,

 

Just a question for you: Would = accepted flows with a guaranteed QoS get rerouted in a PCN domain if there is a = node/link failure?

 

Thanks,

=

 

An

 

From: = pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = Behalf Of Mayutan A.
Sent: Tuesday, May 27, = 2008 7:49 AM
To: Ingemar Johansson = S
Cc: pcn@ietf.org
Subject: Re: [PCN] = Usecases and Benefits of end to end ECN support in = PCNDomains

 

Hi,

Thanks Michael and Ingemar, I get the difference now. I was talking = about UDP applications trying to get some acceptable QoS during connection setup, = whereas the draft proposal discusses about applications that can adapt on the = fly depending on the congestion in the network. The point I was making is = that in a PCN domain, once an application flow is admitted, the domain ensures = that it provides all accepted flows with a guaranteed  QoS as long as there = aren't any unexpected node/link failures.

But I agree that during the initial stages when not many domains are PCN capable, the adaptive applications can play a part in adapting its rate = on receiving ECN marked packets and adjusting accordingly.

Cheers,
Mayutan


On Tue, May 27, 2008 at 10:30 AM, Ingemar Johansson S <ingemar.s.johansson@eric= sson.com> wrote:

Hi

Agree with Michael, the use case below sounds in my opinion like = something that is done during the session setup and with interaction between the client = and the admission control scheme, I don't believe that ECN can be used for = this purpose as there is no flow running.

/Ingemar


> -----Original Message-----
> From: Michael Menth [mailto:menth@informatik.uni-wu= erzburg.de]
> Sent: den 27 maj 2008 09:03
> To: Mayutan A.
> Cc: Ingemar Johansson S; pcn@ietf.org
> Subject: Re: [PCN] Usecases and Benefits of end to end ECN
> support in PCN Domains
>
> Hi Mayutan,
>
> it's similar, but not the same. While ECN allows rate
> adaptation for flows in progress, your alternative allows it
> only for flows that are not yet permitted. An end-to-end
> deployment of PCN is not within the current charter.
>
> Regards,
>
>     Michael
>
> Mayutan A. wrote:
> > Hi
> > My two cents:
> >
> > Since PCN is defined for inelastic traffic, when an = adaptive
> > application is denied admission, it can adapt its sending
> rate and try
> > again. This is similar to the application receiving a = congestion
> > marked packet and therefore lowering its rate (for e.g a = video
> > streaming application lowering the quality or the video = streamed).
> > Eventually the PCN aims at end-to-end deployment and thus = favours
> > adaptive applications.
> >
> > Mayutan
> >
> > On Mon, May 26, 2008 at 9:56 AM, Ingemar Johansson S
> > <ingemar.s.johansson@eric= sson.com
> > <mailto:ingemar.s.johansson@eric= sson.com>> wrote:
> >
> >     Hi
> >
> >     The ECN-PCN usecases draft has been updated. The = main
> addition is
> >     the section 3.5 suggested by Ken Carlberg.
> >
> http://tools.ietf.org/id/draft-sarker-pcn-ecn-pcn-useca= ses-01.txt
> >
> >     Comments are welcome
> >     /Ingemar
> >     *******************************************
> >     Ingemar Johansson
> >     Senior Research Engineer, IETF = "nethead"
> >     EAB/TVP - Multimedia Technologies
> >     Ericsson Research Ericsson AB
> >     Box 920 S-971 28 Lule=E5, Sweden
> >     Tel: +46 (0)8 4043042
> >     ECN: 850-43042
> >     ECC: 850-43074
> >     Mobile: +46 (0)730 783289
> >     *******************************************
> >     = _______________________________________________
> >     PCN mailing list
> >     PCN@ietf.org <mailto:PCN@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/pcn
> >
> >
> >
> >
> > --
> > Mayutan Arumaithurai
> > 0049-551-2712647 (Home number)
> > 0049-176-20322049 (mobile number)
> >
> = ---------------------------------------------------------------------- > > --
> >
> > _______________________________________________
> > PCN mailing list
> > PCN@ietf.org
> > https://www.ietf.org/mailman/listinfo/pcn
> >
>
> --
> Dr. Michael Menth, Assistant Professor
> University of = Wuerzburg, Institute of Computer = Science Am
> Hubland, D-97074 Wuerzburg, Germany, room B206
> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
> mailto:menth@informatik.uni-wu= erzburg.de
> http://www3.informatik.uni-wuerzburg.de/research/ngn
>
>




--
Mayutan Arumaithurai
0049-551-2712647 (Home number)
0049-176-20322049 (mobile number)

------_=_NextPart_001_01C8C00A.F1BF7B3A-- --===============1075055104== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1075055104==-- From pcn-bounces@ietf.org Tue May 27 08:34:01 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 498213A6C31; Tue, 27 May 2008 08:34:01 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 938623A69F0 for ; Tue, 27 May 2008 08:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7NB2dYMFBpC for ; Tue, 27 May 2008 08:33:59 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 64F9C3A69C5 for ; Tue, 27 May 2008 08:33:58 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so1654944fga.41 for ; Tue, 27 May 2008 08:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=4X1rtOEHcaJXwLhduGDskBOtLYkdYtVnOc88lMp1pwc=; b=U6qk3ITwt9N6hdOcNz5yOoCIETXu+roMVTwU9VVs6ixzraNxnB2y2V4QiqWe7PS9/saqnU0xZxndHbHI00oBqva9wclZGAohHnMD+IPrkHmFlYWY8dGHpS7tTRE3eY89WYTXZzZYO6JwO3yHs4wn0QVj/IjkszxE+xOTYlYTrDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=r9Edz2hPSD5H1m+z1lLG6eFBJBm+IakAHefu31JZCfXOT2tnzvTaZRyv5DIj4aQd9AF5xA1UN6gd/H6XvcQarA0hyT4Qso4fl9yi8yQG+p3bQGKMVai35qA16qUg7BQgj8TW3DGxaZ/N2Do3pupaB6usnTf5X7wyN3XvT46r6uM= Received: by 10.86.49.3 with SMTP id w3mr476100fgw.4.1211902442917; Tue, 27 May 2008 08:34:02 -0700 (PDT) Received: by 10.86.77.2 with HTTP; Tue, 27 May 2008 08:34:02 -0700 (PDT) Message-ID: Date: Tue, 27 May 2008 17:34:02 +0200 From: "Mayutan A." To: "Nguyen, An P" In-Reply-To: <78DDCF1918AA074CAD06EC3052B2DB1A71BCB5@ZAU1UG-0316.DHSNET.DS1.DHS> MIME-Version: 1.0 References: <78DDCF1918AA074CAD06EC3052B2DB1A71BCB5@ZAU1UG-0316.DHSNET.DS1.DHS> Cc: pcn@ietf.org Subject: Re: [PCN] Usecases and Benefits of end to end ECN support in PCNDomains X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1612440430==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org --===============1612440430== Content-Type: multipart/alternative; boundary="----=_Part_3072_4837980.1211902442920" ------=_Part_3072_4837980.1211902442920 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, See inline: On Tue, May 27, 2008 at 5:04 PM, Nguyen, An P wrote: > Mayutan, > > > > Just a question for you: Would accepted flows with a guaranteed QoS get > rerouted in a PCN domain if there is a node/link failure? > > I have already mentioned that in my previous mail "The point I was making is that in a PCN domain, once an application flow i= s admitted, the domain ensures that it provides all accepted flows with a guaranteed QoS as long as there aren't any unexpected node/link failures. = " Yes, when there is a route failure, flows get rerouted in the PCN domain an= d Flow termination comes into play. In this case, an *adaptive* application might be able to prevent its flow getting terminated. Anyways, would copying the original ECN fields into an IP option header field at the Ingress and then recopying it back into the ECN fields by the egress solve this problem. Or would encapsulation /decapsulation solve this= . Just brain-storming here. Thanks, Mayutan > > Thanks, > > > > An > > > ------------------------------ > > *From:* pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] *On Behalf Of = *Mayutan > A. > *Sent:* Tuesday, May 27, 2008 7:49 AM > *To:* Ingemar Johansson S > *Cc:* pcn@ietf.org > > *Subject:* Re: [PCN] Usecases and Benefits of end to end ECN support in > PCNDomains > > > > Hi, > > Thanks Michael and Ingemar, I get the difference now. I was talking about > UDP applications trying to get some acceptable QoS during connection setu= p, > whereas the draft proposal discusses about applications that can adapt on > the fly depending on the congestion in the network. The point I was makin= g > is that in a PCN domain, once an application flow is admitted, the domain > ensures that it provides all accepted flows with a guaranteed QoS as lon= g > as there aren't any unexpected node/link failures. > > But I agree that during the initial stages when not many domains are PCN > capable, the adaptive applications can play a part in adapting its rate o= n > receiving ECN marked packets and adjusting accordingly. > > Cheers, > Mayutan > > > On Tue, May 27, 2008 at 10:30 AM, Ingemar Johansson S < > ingemar.s.johansson@ericsson.com> wrote: > > Hi > > Agree with Michael, the use case below sounds in my opinion like somethin= g > that is done during the session setup and with interaction between the > client and the admission control scheme, I don't believe that ECN can be > used for this purpose as there is no flow running. > > /Ingemar > > > > -----Original Message----- > > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > Sent: den 27 maj 2008 09:03 > > To: Mayutan A. > > Cc: Ingemar Johansson S; pcn@ietf.org > > Subject: Re: [PCN] Usecases and Benefits of end to end ECN > > support in PCN Domains > > > > Hi Mayutan, > > > > it's similar, but not the same. While ECN allows rate > > adaptation for flows in progress, your alternative allows it > > only for flows that are not yet permitted. An end-to-end > > deployment of PCN is not within the current charter. > > > > Regards, > > > > Michael > > > > Mayutan A. wrote: > > > Hi > > > My two cents: > > > > > > Since PCN is defined for inelastic traffic, when an adaptive > > > application is denied admission, it can adapt its sending > > rate and try > > > again. This is similar to the application receiving a congestion > > > marked packet and therefore lowering its rate (for e.g a video > > > streaming application lowering the quality or the video streamed). > > > Eventually the PCN aims at end-to-end deployment and thus favours > > > adaptive applications. > > > > > > Mayutan > > > > > > On Mon, May 26, 2008 at 9:56 AM, Ingemar Johansson S > > > > > > wrote: > > > > > > Hi > > > > > > The ECN-PCN usecases draft has been updated. The main > > addition is > > > the section 3.5 suggested by Ken Carlberg. > > > > > http://tools.ietf.org/id/draft-sarker-pcn-ecn-pcn-usecases-01.txt > > > > > > Comments are welcome > > > /Ingemar > > > ******************************************* > > > Ingemar Johansson > > > Senior Research Engineer, IETF "nethead" > > > EAB/TVP - Multimedia Technologies > > > Ericsson Research Ericsson AB > > > Box 920 S-971 28 Lule=E5, Sweden > > > Tel: +46 (0)8 4043042 > > > ECN: 850-43042 > > > ECC: 850-43074 > > > Mobile: +46 (0)730 783289 > > > ******************************************* > > > _______________________________________________ > > > PCN mailing list > > > PCN@ietf.org > > > https://www.ietf.org/mailman/listinfo/pcn > > > > > > > > > > > > > > > -- > > > Mayutan Arumaithurai > > > 0049-551-2712647 (Home number) > > > 0049-176-20322049 (mobile number) > > > > > ---------------------------------------------------------------------- > > > -- > > > > > > _______________________________________________ > > > PCN mailing list > > > PCN@ietf.org > > > https://www.ietf.org/mailman/listinfo/pcn > > > > > > > -- > > Dr. Michael Menth, Assistant Professor > > University of Wuerzburg, Institute of Computer Science Am > > Hubland, D-97074 Wuerzburg, Germany, room B206 > > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > > mailto:menth@informatik.uni-wuerzburg.de > > http://www3.informatik.uni-wuerzburg.de/research/ngn > > > > > > > > > -- > Mayutan Arumaithurai > 0049-551-2712647 (Home number) > 0049-176-20322049 (mobile number) > --=20 Mayutan Arumaithurai 0049-551-2712647 (Home number) 0049-176-20322049 (mobile number) ------=_Part_3072_4837980.1211902442920 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi,

See inline:


On Tue, May 2= 7, 2008 at 5:04 PM, Nguyen, An P <An.P.Nguyen@dhs.gov> wrote:

Mayutan,

 

Just a question for you: Would acc= epted flows with a guaranteed QoS get rerouted in a PCN domain if there is a node/link failure?

I have already mentioned that in my previous mail

"The point I was making is that in a PCN domain, once an application f= low is admitted, the domain ensures that it provides all accepted flows with a guaranteed  QoS as long as there aren't any unexpected node/link failures. "<= br>
Yes, when there is a route failure, flows get rerouted in the PCN domain and Flow termination comes into play. In this case, an adaptive application might be able to prevent its flow getting terminated.

An= yways, would copying the original ECN fields into an IP option header field= at the Ingress and then recopying it back into the ECN fields by the egres= s solve this problem. Or would encapsulation /decapsulation solve this. Jus= t brain-storming here.

Thanks,
Mayutan 


 

Thanks,

 

An

 

From: pcn-bounces@ietf.or= g [mailto:pcn-bounc= es@ietf.org] On Behalf Of = Mayutan A.
Sent: Tuesday, May 27, 200= 8 7:49 AM
To: Ingemar Johansson S Cc: pcn@ietf.org


Subject: Re: [PCN] Usecase= s and Benefits of end to end ECN support in PCNDomains
<= /p>

 

Hi,

Thanks Michael and Ingemar, I get the difference now. I was talking about U= DP applications trying to get some acceptable QoS during connection setup, whe= reas the draft proposal discusses about applications that can adapt on the fly depending on the congestion in the network. The point I was making is that = in a PCN domain, once an application flow is admitted, the domain ensures that i= t provides all accepted flows with a guaranteed  QoS as long as there ar= en't any unexpected node/link failures.

But I agree that during the initial stages when not many domains are PCN capable, the adaptive applications can play a part in adapting its rate on receiving ECN marked packets and adjusting accordingly.

Cheers,
Mayutan


On Tue, May 27, 2008 at 10:30 AM, Ingemar Johansson S <ingemar.s.johansson= @ericsson.com> wrote:

Hi

Agree with Michael, the use case below sounds in my opinion like something = that is done during the session setup and with interaction between the client an= d the admission control scheme, I don't believe that ECN can be used for = this purpose as there is no flow running.

/Ingemar


> -----Original Message-----
> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]
> Sent: den 27 maj 2008 09:03
> To: Mayutan A.
> Cc: Ingemar Johansson S; pcn@ietf.org
> Subject: Re: [PCN] Usecases and Benefits of end to end ECN
> support in PCN Domains
>
> Hi Mayutan,
>
> it's similar, but not the same. While ECN allows rate
> adaptation for flows in progress, your alternative allows it
> only for flows that are not yet permitted. An end-to-end
> deployment of PCN is not within the current charter.
>
> Regards,
>
>     Michael
>
> Mayutan A. wrote:
> > Hi
> > My two cents:
> >
> > Since PCN is defined for inelastic traffic, when an adaptive
> > application is denied admission, it can adapt its sending
> rate and try
> > again. This is similar to the application receiving a congestion<= br> > > marked packet and therefore lowering its rate (for e.g a video > > streaming application lowering the quality or the video streamed)= .
> > Eventually the PCN aims at end-to-end deployment and thus favours=
> > adaptive applications.
> >
> > Mayutan
> >
> > On Mon, May 26, 2008 at 9:56 AM, Ingemar Johansson S
> > <ingemar.s.johansson@ericsson.com
> > <mailto:ingemar.s.johansson@ericsson.com>> wrote:
> >
> >     Hi
> >
> >     The ECN-PCN usecases draft has been updated. The ma= in
> addition is
> >     the section 3.5 suggested by Ken Carlberg.
> >
> http://tools.ietf.org/id/draft-sarker-pcn-ecn-pcn= -usecases-01.txt
> >
> >     Comments are welcome
> >     /Ingemar
> >     *******************************************
> >     Ingemar Johansson
> >     Senior Research Engineer, IETF "nethead"<= br> > >     EAB/TVP - Multimedia Technologies
> >     Ericsson Research Ericsson AB
> >     Box 920 S-971 28 Lule=E5, Sweden
> >     Tel: +46 (0)8 4043042
> >     ECN: 850-43042
> >     ECC: 850-43074
> >     Mobile: +46 (0)730 783289
> >     *******************************************
> >     _______________________________________________
> >     PCN mailing list
> >     P= CN@ietf.org <mailto:PCN@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/pcn
> >
> >
> >
> >
> > --
> > Mayutan Arumaithurai
> > 0049-551-2712647 (Home number)
> > 0049-176-20322049 (mobile number)
> >
> ----------------------------------------------------------------------=
> > --
> >
> > _______________________________________________
> > PCN mailing list
> > PCN@ietf.org
> > https://www.ietf.org/mailman/listinfo/pcn
> >
>
> --
> Dr. Michael Menth, Assistant Professor
> University of Wuerzburg, Institute of Computer Science Am
> Hubland, D-97074 Wuerzburg, Germany, room B206
> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
> mailto:menth@informatik.uni-wuerzburg.de
> http://www3.informatik.uni-wuerzburg.de/research/ngn
>
>




--
Mayutan Arumaithurai
0049-551-2712647 (Home number)
0049-176-20322049 (mobile number)




--
Mayutan Arumaithurai0049-551-2712647 (Home number)
0049-176-20322049 (mobile number) ------=_Part_3072_4837980.1211902442920-- --===============1612440430== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1612440430==-- From pcn-bounces@ietf.org Tue May 27 23:23:14 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACEE828C0F8; Tue, 27 May 2008 23:23:14 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FA8E28C0F8 for ; Tue, 27 May 2008 23:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=1.344, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNILbkEszKD6 for ; Tue, 27 May 2008 23:23:11 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id B81813A6A52 for ; Tue, 27 May 2008 23:23:10 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Wed, 28 May 2008 08:23:05 +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, 28 May 2008 08:23:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 08:25:37 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C01452B24@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Usecases and Benefits of end to end ECN support inPCNDomains thread-index: AcjADxxSg5Z7pY3UQc+NgBBr7mCzRAAexCIg References: <78DDCF1918AA074CAD06EC3052B2DB1A71BCB5@ZAU1UG-0316.DHSNET.DS1.DHS> From: "Geib, Ruediger" To: , X-OriginalArrivalTime: 28 May 2008 06:23:04.0839 (UTC) FILETIME=[49A1D970:01C8C08B] Cc: pcn@ietf.org Subject: Re: [PCN] Usecases and Benefits of end to end ECN support inPCNDomains X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1204408677==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1204408677== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C08B.495B8FEA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8C08B.495B8FEA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mayutan, =20 the general statement that termination starts after rerouting isn't = automatically true. It depends on =20 - how your network is engineered / provisioned - the PCN traffic levels of the failed link(s) and the link(s) to which = traffic is rerouted =20 To me, PCN definitely isn't meant to be operated in non engineered = networks. I expect somewhat=20 tough SLAs on the probability of facing an admission stop indication = (below 0.01%?). The SLA on the=20 occurance of termination will be tougher. =20 I expect termination marks within a PCN domain under commercial = operational conditions to be a=20 possible, but rare event. =20 Regards, =20 Rudiger ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Mayutan A. Sent: Tuesday, May 27, 2008 5:34 PM To: Nguyen, An P Cc: pcn@ietf.org Subject: Re: [PCN] Usecases and Benefits of end to end ECN support = inPCNDomains =09 =09 Hi,=20 =09 See inline: =09 =09 =09 On Tue, May 27, 2008 at 5:04 PM, Nguyen, An P = wrote: =09 Mayutan, =20 Just a question for you: Would accepted flows with a guaranteed QoS = get rerouted in a PCN domain if there is a node/link failure? =09 I have already mentioned that in my previous mail=20 =09 "The point I was making is that in a PCN domain, once an application = flow is admitted, the domain ensures that it provides all accepted flows = with a guaranteed QoS as long as there aren't any unexpected node/link = failures. " =09 Yes, when there is a route failure, flows get rerouted in the PCN = domain and Flow termination comes into play. In this case, an adaptive = application might be able to prevent its flow getting terminated. =09 Anyways, would copying the original ECN fields into an IP option header = field at the Ingress and then recopying it back into the ECN fields by = the egress solve this problem. Or would encapsulation /decapsulation = solve this. Just brain-storming here.=20 =09 Thanks, Mayutan =20 =09 =09 =09 =20 Thanks, =20 An =20 =09 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Mayutan A. Sent: Tuesday, May 27, 2008 7:49 AM To: Ingemar Johansson S Cc: pcn@ietf.org=20 Subject: Re: [PCN] Usecases and Benefits of end to end ECN support in = PCNDomains =09 =20 Hi,=20 =09 Thanks Michael and Ingemar, I get the difference now. I was talking = about UDP applications trying to get some acceptable QoS during = connection setup, whereas the draft proposal discusses about = applications that can adapt on the fly depending on the congestion in = the network. The point I was making is that in a PCN domain, once an = application flow is admitted, the domain ensures that it provides all = accepted flows with a guaranteed QoS as long as there aren't any = unexpected node/link failures.=20 =09 But I agree that during the initial stages when not many domains are = PCN capable, the adaptive applications can play a part in adapting its = rate on receiving ECN marked packets and adjusting accordingly. =09 Cheers, Mayutan=20 =09 =09 =09 On Tue, May 27, 2008 at 10:30 AM, Ingemar Johansson S = wrote: Hi =09 Agree with Michael, the use case below sounds in my opinion like = something that is done during the session setup and with interaction = between the client and the admission control scheme, I don't believe = that ECN can be used for this purpose as there is no flow running. =09 /Ingemar =09 > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: den 27 maj 2008 09:03 > To: Mayutan A. > Cc: Ingemar Johansson S; pcn@ietf.org > Subject: Re: [PCN] Usecases and Benefits of end to end ECN > support in PCN Domains > > Hi Mayutan, > > it's similar, but not the same. While ECN allows rate > adaptation for flows in progress, your alternative allows it > only for flows that are not yet permitted. An end-to-end > deployment of PCN is not within the current charter. > > Regards, > > Michael > > Mayutan A. wrote: > > Hi > > My two cents: > > > > Since PCN is defined for inelastic traffic, when an adaptive > > application is denied admission, it can adapt its sending > rate and try > > again. This is similar to the application receiving a congestion > > marked packet and therefore lowering its rate (for e.g a video > > streaming application lowering the quality or the video streamed). > > Eventually the PCN aims at end-to-end deployment and thus favours > > adaptive applications. > > > > Mayutan > > > > On Mon, May 26, 2008 at 9:56 AM, Ingemar Johansson S > > > > wrote: > > > > Hi > > > > The ECN-PCN usecases draft has been updated. The main > addition is > > the section 3.5 suggested by Ken Carlberg. > > > http://tools.ietf.org/id/draft-sarker-pcn-ecn-pcn-usecases-01.txt > > > > Comments are welcome > > /Ingemar > > ******************************************* > > Ingemar Johansson > > Senior Research Engineer, IETF "nethead" > > EAB/TVP - Multimedia Technologies > > Ericsson Research Ericsson AB > > Box 920 S-971 28 Lule=E5, Sweden > > Tel: +46 (0)8 4043042 > > ECN: 850-43042 > > ECC: 850-43074 > > Mobile: +46 (0)730 783289 > > ******************************************* > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > > > > > > > > > -- > > Mayutan Arumaithurai > > 0049-551-2712647 (Home number) > > 0049-176-20322049 (mobile number) > > > = ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > > > -- > Dr. Michael Menth, Assistant Professor > University of Wuerzburg, Institute of Computer Science Am > Hubland, D-97074 Wuerzburg, Germany, room B206 > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > mailto:menth@informatik.uni-wuerzburg.de > http://www3.informatik.uni-wuerzburg.de/research/ngn > > =09 =09 =09 --=20 Mayutan Arumaithurai 0049-551-2712647 (Home number)=20 0049-176-20322049 (mobile number)=20 --=20 Mayutan Arumaithurai 0049-551-2712647 (Home number)=20 0049-176-20322049 (mobile number)=20 ------_=_NextPart_001_01C8C08B.495B8FEA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Mayutan,
 
the general statement that termination starts = after=20 rerouting isn't automatically true. It depends on
 
- how your network is engineered /=20 provisioned
- the PCN traffic levels of the failed link(s) = and the=20 link(s) to which traffic is rerouted
 
To me, PCN definitely isn't meant to be = operated in non=20 engineered networks. I expect somewhat
tough SLAs on the probability of facing an = admission stop=20 indication (below 0.01%?). The SLA on the
occurance of termination will be=20 tougher.
 
I expect termination marks within a PCN = domain under=20 commercial operational conditions to be a
possible, but rare event.
 
Regards,
 
Rudiger

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of Mayutan = A.
Sent:=20 Tuesday, May 27, 2008 5:34 PM
To: Nguyen, An P
Cc: = pcn@ietf.org
Subject: Re: [PCN] Usecases and Benefits of end = to end=20 ECN support inPCNDomains

Hi,

See inline:


On Tue, May 27, 2008 at 5:04 PM, Nguyen, An P = <An.P.Nguyen@dhs.gov> = wrote:

Mayutan,

 

Just a = question for=20 you: Would accepted flows with a guaranteed QoS get rerouted in a = PCN domain=20 if there is a node/link failure?

I have already mentioned that in my previous mail

"The = point I=20 was making is that in a PCN domain, once an application flow is = admitted, the=20 domain ensures that it provides all accepted flows with a = guaranteed  QoS=20 as long as there aren't any unexpected node/link failures. = "

Yes, when=20 there is a route failure, flows get rerouted in the PCN domain and = Flow=20 termination comes into play. In this case, an adaptive = application=20 might be able to prevent its flow getting terminated.

Anyways, = would=20 copying the original ECN fields into an IP option header field at the = Ingress=20 and then recopying it back into the ECN fields by the egress solve = this=20 problem. Or would encapsulation /decapsulation solve this. Just = brain-storming=20 here.

Thanks,
Mayutan 


 

Thanks,

 

An

 

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of Mayutan = A.
Sent: Tuesday, May 27, 2008 = 7:49=20 AM
To: Ingemar = Johansson=20 S
Cc: pcn@ietf.org


Subject:=20 Re: [PCN] Usecases and Benefits of end to end ECN support in=20 PCNDomains

 

Hi,

Thanks Michael and Ingemar, I = get the=20 difference now. I was talking about UDP applications trying to get = some=20 acceptable QoS during connection setup, whereas the draft proposal = discusses=20 about applications that can adapt on the fly depending on the = congestion in=20 the network. The point I was making is that in a PCN domain, once an = application flow is admitted, the domain ensures that it provides = all=20 accepted flows with a guaranteed  QoS as long as there aren't = any=20 unexpected node/link failures.

But I agree that during the = initial=20 stages when not many domains are PCN capable, the adaptive = applications can=20 play a part in adapting its rate on receiving ECN marked packets and = adjusting accordingly.

Cheers,
Mayutan=20


On Tue,=20 May 27, 2008 at 10:30 AM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>=20 wrote:

Hi

Agree with Michael, the use case = below=20 sounds in my opinion like something that is done during the session = setup=20 and with interaction between the client and the admission control = scheme, I=20 don't believe that ECN can be used for this purpose as there is no = flow=20 running.

/Ingemar


> -----Original = Message-----
> From:=20 Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]
> Sent: = den 27=20 maj 2008 09:03
> To: Mayutan A.
> Cc: Ingemar Johansson = S; pcn@ietf.org
> Subject:=20 Re: [PCN] Usecases and Benefits of end to end ECN
> support in = PCN=20 Domains
>
> Hi Mayutan,
>
> it's similar, = but not=20 the same. While ECN allows rate
> adaptation for flows in = progress,=20 your alternative allows it
> only for flows that are not yet=20 permitted. An end-to-end
> deployment of PCN is not within the = current=20 charter.
>
> Regards,
>
>    =20 Michael
>
> Mayutan A. wrote:
> > Hi
> = > My=20 two cents:
> >
> > Since PCN is defined for = inelastic=20 traffic, when an adaptive
> > application is denied = admission, it=20 can adapt its sending
> rate and try
> > again. This = is=20 similar to the application receiving a congestion
> > = marked packet=20 and therefore lowering its rate (for e.g a video
> > = streaming=20 application lowering the quality or the video streamed).
> = >=20 Eventually the PCN aims at end-to-end deployment and thus = favours
>=20 > adaptive applications.
> >
> > = Mayutan
>=20 >
> > On Mon, May 26, 2008 at 9:56 AM, Ingemar Johansson = S
> > <ingemar.s.johansson@ericsson.com
> >=20 <mailto:ingemar.s.johansson@ericsson.com>> = wrote:
>=20 >
> >     Hi
> >
> >   =  =20 The ECN-PCN usecases draft has been updated. The main
> = addition=20 is
> >     the section 3.5 suggested by Ken=20 Carlberg.
> >
> http://tools.ietf.org/id/draft-sarker-pcn-ecn-pcn-usecase= s-01.txt
>=20 >
> >     Comments are welcome
> > =  =20   /Ingemar
> >    =20 *******************************************
> >   =  =20 Ingemar Johansson
> >     Senior Research = Engineer, IETF=20 "nethead"
> >     EAB/TVP - Multimedia=20 Technologies
> >     Ericsson Research Ericsson=20 AB
> >     Box 920 S-971 28 Lule=E5, = Sweden
> >=20     Tel: +46 (0)8 4043042
> >     ECN:=20 850-43042
> >     ECC: 850-43074
> > =  =20   Mobile: +46 (0)730 783289
> >    =20 *******************************************
> >   =  =20 _______________________________________________
> >   =  =20 PCN mailing list
> >     PCN@ietf.org <mailto:PCN@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/pcn
>=20 >
> >
> >
> >
> > --
> = >=20 Mayutan Arumaithurai
> > 0049-551-2712647 (Home = number)
>=20 > 0049-176-20322049 (mobile number)
> >
>=20 = ---------------------------------------------------------------------->=20 > --
> >
> >=20 _______________________________________________
> > PCN = mailing=20 list
> > PCN@ietf.org
> > https://www.ietf.org/mailman/listinfo/pcn
>=20 >
>
> --
> Dr. Michael Menth, Assistant=20 Professor
> University of Wuerzburg, Institute of Computer = Science=20 Am
> Hubland, D-97074 Wuerzburg, Germany, room B206
> = phone:=20 (+49)-931/888-6644, fax: (+49)-931/888-6632
> mailto:menth@informatik.uni-wuerzburg.de
> http://www3.informatik.uni-wuerzburg.de/research/ngn<= BR>>
>



--
Mayutan Arumaithurai
0049-551-2712647 = (Home number)=20
0049-176-20322049 (mobile number)=20




--
Mayutan Arumaithurai
0049-551-2712647 (Home = number)=20
0049-176-20322049 (mobile number) ------_=_NextPart_001_01C8C08B.495B8FEA-- --===============1204408677== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1204408677==-- From pcn-bounces@ietf.org Wed May 28 04:09:29 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F421328C13E; Wed, 28 May 2008 04:09:28 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 772D63A683D for ; Wed, 28 May 2008 04:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.04 X-Spam-Level: X-Spam-Status: No, score=-6.04 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e036zJyDhZG2 for ; Wed, 28 May 2008 04:09:22 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 14C3028C1EB for ; Wed, 28 May 2008 04:09:18 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4F7E620C5E; Wed, 28 May 2008 13:09:25 +0200 (CEST) X-AuditID: c1b4fb3c-ab095bb00000193b-ae-483d3d655926 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 22F8820B8B; Wed, 28 May 2008 13:09:25 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 May 2008 13:09:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 13:09:23 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0507AAC749@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Usecases and Benefits of end to end ECN support inPCNDomains thread-index: AcjADyEPGPK2xlfeS8SuwXhto2hiOwAol9Cw References: <78DDCF1918AA074CAD06EC3052B2DB1A71BCB5@ZAU1UG-0316.DHSNET.DS1.DHS> From: "Ingemar Johansson S" To: "Mayutan A." , "Nguyen, An P" X-OriginalArrivalTime: 28 May 2008 11:09:25.0033 (UTC) FILETIME=[49D36990:01C8C0B3] X-Brightmail-Tracker: AAAAAA== Cc: pcn@ietf.org Subject: Re: [PCN] Usecases and Benefits of end to end ECN support inPCNDomains X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0620329240==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0620329240== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C0B3.492EF39F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8C0B3.492EF39F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi =20 I belive that one possible use case (as mentioned in the draft) would be = to cope with flash-crowds or to be able to elevate emergency services = and perhaps also to be able to cope with link failures in a graceful = way. For this purpose it would be possible to ECN mark flows (or = aggregates).=20 Now, depending on implementaion most applications will preferrably = respond to ECN marks with e.g a reduced bitrate (within rougly a = roundtrip time). There is however a risk that applications does not = respond to ECN marks, for this pupose the ingress or egress nodes with = meter/marker/shaper possibilities could have the possibility to e.g = demote flows that does not follow the rules. =20 How ECN are to be able to be maintained thorugh a PCN domain is = currently an open question. The options I see are either tunneling or = use of extra DSCP codepoints. =20 /Ingemar =20 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Mayutan A. Sent: den 27 maj 2008 17:34 To: Nguyen, An P Cc: pcn@ietf.org Subject: Re: [PCN] Usecases and Benefits of end to end ECN support = inPCNDomains =09 =09 Hi,=20 =09 See inline: =09 =09 =09 On Tue, May 27, 2008 at 5:04 PM, Nguyen, An P = wrote: =09 Mayutan, =20 Just a question for you: Would accepted flows with a guaranteed QoS = get rerouted in a PCN domain if there is a node/link failure? =09 I have already mentioned that in my previous mail=20 =09 "The point I was making is that in a PCN domain, once an application = flow is admitted, the domain ensures that it provides all accepted flows = with a guaranteed QoS as long as there aren't any unexpected node/link = failures. " =09 Yes, when there is a route failure, flows get rerouted in the PCN = domain and Flow termination comes into play. In this case, an adaptive = application might be able to prevent its flow getting terminated. =09 Anyways, would copying the original ECN fields into an IP option header = field at the Ingress and then recopying it back into the ECN fields by = the egress solve this problem. Or would encapsulation /decapsulation = solve this. Just brain-storming here.=20 =09 Thanks, Mayutan =20 =09 =09 =09 =20 Thanks, =20 An =20 =09 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Mayutan A. Sent: Tuesday, May 27, 2008 7:49 AM To: Ingemar Johansson S Cc: pcn@ietf.org=20 Subject: Re: [PCN] Usecases and Benefits of end to end ECN support in = PCNDomains =09 =20 Hi,=20 =09 Thanks Michael and Ingemar, I get the difference now. I was talking = about UDP applications trying to get some acceptable QoS during = connection setup, whereas the draft proposal discusses about = applications that can adapt on the fly depending on the congestion in = the network. The point I was making is that in a PCN domain, once an = application flow is admitted, the domain ensures that it provides all = accepted flows with a guaranteed QoS as long as there aren't any = unexpected node/link failures.=20 =09 But I agree that during the initial stages when not many domains are = PCN capable, the adaptive applications can play a part in adapting its = rate on receiving ECN marked packets and adjusting accordingly. =09 Cheers, Mayutan=20 =09 =09 =09 On Tue, May 27, 2008 at 10:30 AM, Ingemar Johansson S = wrote: Hi =09 Agree with Michael, the use case below sounds in my opinion like = something that is done during the session setup and with interaction = between the client and the admission control scheme, I don't believe = that ECN can be used for this purpose as there is no flow running. =09 /Ingemar =09 > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: den 27 maj 2008 09:03 > To: Mayutan A. > Cc: Ingemar Johansson S; pcn@ietf.org > Subject: Re: [PCN] Usecases and Benefits of end to end ECN > support in PCN Domains > > Hi Mayutan, > > it's similar, but not the same. While ECN allows rate > adaptation for flows in progress, your alternative allows it > only for flows that are not yet permitted. An end-to-end > deployment of PCN is not within the current charter. > > Regards, > > Michael > > Mayutan A. wrote: > > Hi > > My two cents: > > > > Since PCN is defined for inelastic traffic, when an adaptive > > application is denied admission, it can adapt its sending > rate and try > > again. This is similar to the application receiving a congestion > > marked packet and therefore lowering its rate (for e.g a video > > streaming application lowering the quality or the video streamed). > > Eventually the PCN aims at end-to-end deployment and thus favours > > adaptive applications. > > > > Mayutan > > > > On Mon, May 26, 2008 at 9:56 AM, Ingemar Johansson S > > > > wrote: > > > > Hi > > > > The ECN-PCN usecases draft has been updated. The main > addition is > > the section 3.5 suggested by Ken Carlberg. > > > http://tools.ietf.org/id/draft-sarker-pcn-ecn-pcn-usecases-01.txt > > > > Comments are welcome > > /Ingemar > > ******************************************* > > Ingemar Johansson > > Senior Research Engineer, IETF "nethead" > > EAB/TVP - Multimedia Technologies > > Ericsson Research Ericsson AB > > Box 920 S-971 28 Lule=E5, Sweden > > Tel: +46 (0)8 4043042 > > ECN: 850-43042 > > ECC: 850-43074 > > Mobile: +46 (0)730 783289 > > ******************************************* > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > > > > > > > > > -- > > Mayutan Arumaithurai > > 0049-551-2712647 (Home number) > > 0049-176-20322049 (mobile number) > > > = ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > > > -- > Dr. Michael Menth, Assistant Professor > University of Wuerzburg, Institute of Computer Science Am > Hubland, D-97074 Wuerzburg, Germany, room B206 > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > mailto:menth@informatik.uni-wuerzburg.de > http://www3.informatik.uni-wuerzburg.de/research/ngn > > =09 =09 =09 --=20 Mayutan Arumaithurai 0049-551-2712647 (Home number)=20 0049-176-20322049 (mobile number)=20 --=20 Mayutan Arumaithurai 0049-551-2712647 (Home number)=20 0049-176-20322049 (mobile number)=20 ------_=_NextPart_001_01C8C0B3.492EF39F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
I belive that one possible use case (as = mentioned in the=20 draft) would be to cope with flash-crowds or to be able to elevate = emergency=20 services and perhaps also to be able to cope with link failures in a = graceful=20 way. For this purpose it would be possible to ECN mark flows (or = aggregates).=20
Now, depending on implementaion most = applications=20 will preferrably respond to ECN marks with e.g a reduced bitrate = (within=20 rougly a roundtrip time). There is however a risk that applications does = not=20 respond to ECN marks, for this pupose the ingress or egress nodes with=20 meter/marker/shaper possibilities could have the possibility to e.g = demote flows=20 that does not follow the rules.
 
How ECN are to be able to be maintained thorugh = a PCN=20 domain is currently an open question. The options I see are either = tunneling or=20 use of extra DSCP codepoints.
 
/Ingemar
 

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of Mayutan = A.
Sent:=20 den 27 maj 2008 17:34
To: Nguyen, An P
Cc:=20 pcn@ietf.org
Subject: Re: [PCN] Usecases and Benefits of end = to end=20 ECN support inPCNDomains

Hi,

See inline:


On Tue, May 27, 2008 at 5:04 PM, Nguyen, An P = <An.P.Nguyen@dhs.gov> = wrote:

Mayutan,

 

Just a = question for=20 you: Would accepted flows with a guaranteed QoS get rerouted in a = PCN domain=20 if there is a node/link failure?

I have already mentioned that in my previous mail

"The = point I=20 was making is that in a PCN domain, once an application flow is = admitted, the=20 domain ensures that it provides all accepted flows with a = guaranteed  QoS=20 as long as there aren't any unexpected node/link failures. = "

Yes, when=20 there is a route failure, flows get rerouted in the PCN domain and = Flow=20 termination comes into play. In this case, an adaptive = application=20 might be able to prevent its flow getting terminated.

Anyways, = would=20 copying the original ECN fields into an IP option header field at the = Ingress=20 and then recopying it back into the ECN fields by the egress solve = this=20 problem. Or would encapsulation /decapsulation solve this. Just = brain-storming=20 here.

Thanks,
Mayutan 


 

Thanks,

 

An

 

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of Mayutan = A.
Sent: Tuesday, May 27, 2008 = 7:49=20 AM
To: Ingemar = Johansson=20 S
Cc: pcn@ietf.org


Subject:=20 Re: [PCN] Usecases and Benefits of end to end ECN support in=20 PCNDomains

 

Hi,

Thanks Michael and Ingemar, I = get the=20 difference now. I was talking about UDP applications trying to get = some=20 acceptable QoS during connection setup, whereas the draft proposal = discusses=20 about applications that can adapt on the fly depending on the = congestion in=20 the network. The point I was making is that in a PCN domain, once an = application flow is admitted, the domain ensures that it provides = all=20 accepted flows with a guaranteed  QoS as long as there aren't = any=20 unexpected node/link failures.

But I agree that during the = initial=20 stages when not many domains are PCN capable, the adaptive = applications can=20 play a part in adapting its rate on receiving ECN marked packets and = adjusting accordingly.

Cheers,
Mayutan=20


On Tue,=20 May 27, 2008 at 10:30 AM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>=20 wrote:

Hi

Agree with Michael, the use case = below=20 sounds in my opinion like something that is done during the session = setup=20 and with interaction between the client and the admission control = scheme, I=20 don't believe that ECN can be used for this purpose as there is no = flow=20 running.

/Ingemar


> -----Original = Message-----
> From:=20 Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]
> Sent: = den 27=20 maj 2008 09:03
> To: Mayutan A.
> Cc: Ingemar Johansson = S; pcn@ietf.org
> Subject:=20 Re: [PCN] Usecases and Benefits of end to end ECN
> support in = PCN=20 Domains
>
> Hi Mayutan,
>
> it's similar, = but not=20 the same. While ECN allows rate
> adaptation for flows in = progress,=20 your alternative allows it
> only for flows that are not yet=20 permitted. An end-to-end
> deployment of PCN is not within the = current=20 charter.
>
> Regards,
>
>    =20 Michael
>
> Mayutan A. wrote:
> > Hi
> = > My=20 two cents:
> >
> > Since PCN is defined for = inelastic=20 traffic, when an adaptive
> > application is denied = admission, it=20 can adapt its sending
> rate and try
> > again. This = is=20 similar to the application receiving a congestion
> > = marked packet=20 and therefore lowering its rate (for e.g a video
> > = streaming=20 application lowering the quality or the video streamed).
> = >=20 Eventually the PCN aims at end-to-end deployment and thus = favours
>=20 > adaptive applications.
> >
> > = Mayutan
>=20 >
> > On Mon, May 26, 2008 at 9:56 AM, Ingemar Johansson = S
> > <ingemar.s.johansson@ericsson.com
> >=20 <mailto:ingemar.s.johansson@ericsson.com>> = wrote:
>=20 >
> >     Hi
> >
> >   =  =20 The ECN-PCN usecases draft has been updated. The main
> = addition=20 is
> >     the section 3.5 suggested by Ken=20 Carlberg.
> >
> http://tools.ietf.org/id/draft-sarker-pcn-ecn-pcn-usecase= s-01.txt
>=20 >
> >     Comments are welcome
> > =  =20   /Ingemar
> >    =20 *******************************************
> >   =  =20 Ingemar Johansson
> >     Senior Research = Engineer, IETF=20 "nethead"
> >     EAB/TVP - Multimedia=20 Technologies
> >     Ericsson Research Ericsson=20 AB
> >     Box 920 S-971 28 Lule=E5, = Sweden
> >=20     Tel: +46 (0)8 4043042
> >     ECN:=20 850-43042
> >     ECC: 850-43074
> > =  =20   Mobile: +46 (0)730 783289
> >    =20 *******************************************
> >   =  =20 _______________________________________________
> >   =  =20 PCN mailing list
> >     PCN@ietf.org <mailto:PCN@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/pcn
>=20 >
> >
> >
> >
> > --
> = >=20 Mayutan Arumaithurai
> > 0049-551-2712647 (Home = number)
>=20 > 0049-176-20322049 (mobile number)
> >
>=20 = ---------------------------------------------------------------------->=20 > --
> >
> >=20 _______________________________________________
> > PCN = mailing=20 list
> > PCN@ietf.org
> > https://www.ietf.org/mailman/listinfo/pcn
>=20 >
>
> --
> Dr. Michael Menth, Assistant=20 Professor
> University of Wuerzburg, Institute of Computer = Science=20 Am
> Hubland, D-97074 Wuerzburg, Germany, room B206
> = phone:=20 (+49)-931/888-6644, fax: (+49)-931/888-6632
> mailto:menth@informatik.uni-wuerzburg.de
> http://www3.informatik.uni-wuerzburg.de/research/ngn<= BR>>
>



--
Mayutan Arumaithurai
0049-551-2712647 = (Home number)=20
0049-176-20322049 (mobile number)=20




--
Mayutan Arumaithurai
0049-551-2712647 (Home = number)=20
0049-176-20322049 (mobile number) ------_=_NextPart_001_01C8C0B3.492EF39F-- --===============0620329240== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0620329240==-- From pcn-bounces@ietf.org Wed May 28 06:37:52 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 730273A6A11; Wed, 28 May 2008 06:37:52 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3A828C0FA for ; Wed, 28 May 2008 06:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kn4f7V5pIM+P for ; Wed, 28 May 2008 06:37:50 -0700 (PDT) Received: from portland.eukhost.com (portland.eukhost.com [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 25AFF3A69A5 for ; Wed, 28 May 2008 06:37:50 -0700 (PDT) Received: from c-69-255-78-171.hsd1.md.comcast.net ([69.255.78.171]:53797 helo=[192.168.1.120]) by portland.eukhost.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1K1Lqi-0003Ij-KZ for pcn@ietf.org; Wed, 28 May 2008 13:37:53 +0000 Message-Id: <134B71ED-F91C-485C-A264-E9C70FD332CC@g11.org.uk> From: "carlberg@g11.org.uk" To: pcn@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 28 May 2008 09:37:52 -0400 References: X-Mailer: Apple Mail (2.919.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk Subject: [PCN] Fwd: [NSIS] Status update about GIST X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1667490602==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org --===============1667490602== Content-Type: multipart/alternative; boundary=Apple-Mail-5--401044760 --Apple-Mail-5--401044760 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit There had been a discussion on the use of RAO on this list prior to the Philly IETF, so its probably constructive to forward the following from the NSIS list. -ken Begin forwarded message: > From: "Hancock, Robert" > Date: May 28, 2008 8:40:37 AM EDT > To: , , > > Subject: Re: [NSIS] Status update about GIST > > john, > >> -----Original Message----- >> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On >> Behalf Of john.loughney@nokia.com >> Sent: 28 May 2008 03:19 >> To: Stiemerling@nw.neclab.eu; nsis@ietf.org >> Subject: Re: [NSIS] Status update about GIST >> >> Martin, >> >> Does this mean that the use RAO is basically thought of as a bad >> thing >> by the IESG? > > my interpretation of the discussion is that: > > IF your protocol > * uses RAO, and > * has any likelihood of significant deployment on the Internet > (where "significant" is defined as "more than RSVP for QoS") > THEN > * it will be experimental > > ... at least for IPv4. the IPv6 case is (at least to me) much > less clear cut: theoretically/architecturally they should be > the same, but the practical/engineering issues are quite different. > > one of the routing ADs is going to write a draft explaining this. > > robert h. > >> >> John >> >> -----Original Message----- >> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On >> Behalf Of >> ext Martin Stiemerling >> Sent: Tuesday, May 27, 2008 6:36 PM >> To: nsis >> Subject: [NSIS] Status update about GIST >> >> Hi all, >> >> It has been a bit silent the last weeks about what is >> actually happening >> with GIST. You might still remember that GIST go sent to the IESG and >> underwent the IESG review and discussion. >> >> The GIST spec got quite an amount of ABSTAINS during the IESG >> review and >> therefore is blocked. Most of the IESG members have had concerns >> about >> GIST and this led to the ABSTAINS. >> >> However, to get things progressed, Magnus initiated a joint telechat >> between the IESG, Robert, Henning and me to discuss the ABSTAINS. The >> call took place on Thursday, May 15, 5:30 pm CEST. Here is >> brief summary >> (that reassembles my memory): >> >> The discussion with the IESG centered around the Router Alert >> Options in >> IPv4 but also touching IPv6. The general concern about thiss is that >> NSIS could lead to a flood of IP packets including IP RAO options and >> that this could effect existing RSVP-TE deployments, plus all current >> routers (as IP options go to the slow path), and finally that packets >> with RAO options are anyhow filtered at the edges of the >> Internet. This >> cause most of the ABSTAINS and the call for GIST being pushed to the >> experimental track instead the standards track. >> >> The issues associated with RAO were discussed for quite some while (I >> remember 1 hours or so) and we couldn't find any agreement >> for the IESG >> on staying with RAO as part of the GIST spec AND going for standards >> track. The envisioned solutions to this is, revert to packet >> filtering >> mechanism (e.g. 5-tuple) to intercept GIST packets, instead of RAO, >> in >> the GIST specification. This would be allowed to go GIST as standard >> track. The RAO part will be cut out of the GIST spec and pushed to a >> separate document. This new document will go on experimental track. >> >> This splitting will also effect the NSLPs, as they are also >> definin RAO >> usage. >> >> Martin >> >> >> >> stiemerling@nw.neclab.eu >> >> NEC Laboratories Europe - Network Research Division NEC >> Europe Limited | >> Registered Office: NEC House, 1 Victoria Road, London W3 6BL | >> Registered in England 2832014 >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www.ietf.org/mailman/listinfo/nsis >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www.ietf.org/mailman/listinfo/nsis >> > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www.ietf.org/mailman/listinfo/nsis --Apple-Mail-5--401044760 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable There had been a discussion on = the use of RAO on this list prior to the Philly IETF, so its probably = constructive to forward the following from the NSIS = list.

-ken


Begin = forwarded message:

From: = "Hancock, Robert" <robert.hancock@roke.co.uk>
Date: May 28, 2008 8:40:37 AM = EDT
Subject: = Re: [NSIS] Status update about GIST

john, =

-----Original = Message-----
From: = nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On
Behalf Of john.loughney@nokia.com
Sent: 28 May 2008 = 03:19
To: Stiemerling@nw.neclab.eu; = nsis@ietf.org
Subject: Re: [NSIS] Status update about = GIST

Martin,

Does this mean = that the use RAO is basically thought of as a bad = thing
by the = IESG?

my interpretation of the discussion is that: =

IF your protocol
* uses RAO, and
* has any likelihood of = significant deployment on the Internet
 (where "significant" is = defined as "more than RSVP for QoS")
THEN
* it will be = experimental

... at least for IPv4. the IPv6 case is (at least to = me) much
less clear cut: theoretically/architecturally they should = be
the same, but the practical/engineering issues are quite = different.

one of the routing ADs is going to write a draft = explaining this.

robert h.


John

-----Original = Message-----
From: = nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On
Behalf = Of
ext Martin = Stiemerling
Sent: Tuesday, May = 27, 2008 6:36 PM
To: = nsis
Subject: [NSIS] Status = update about GIST

Hi = all,

It has been a = bit silent the last weeks about what is
actually happening
with GIST. You might still remember that GIST go sent to = the IESG and
underwent the = IESG review and discussion.

The GIST spec = got quite an amount of ABSTAINS during the IESG =
review = and
therefore is blocked. Most = of the IESG members have had concerns about
GIST and this led to the ABSTAINS. =

However, to get things progressed, Magnus initiated a = joint telechat
between the = IESG, Robert, Henning and me to discuss the ABSTAINS. = The
call took place on = Thursday, May 15, 5:30 pm CEST. Here is
brief summary
(that reassembles my memory):

The discussion = with the IESG centered around the Router Alert =
Options = in
IPv4 but also touching = IPv6. The general concern about thiss is = that
NSIS could lead to a = flood of IP packets including IP RAO options = and
that this could effect = existing RSVP-TE deployments, plus all = current
routers (as IP options = go to the slow path), and finally that = packets
with RAO options are = anyhow filtered at the edges of the
Internet. This
cause most of the ABSTAINS and the call for GIST being = pushed to the
experimental = track instead the standards track.

The issues = associated with RAO were discussed for quite some while = (I
remember 1 hours or so) and = we couldn't find any agreement
for the IESG
on = staying with RAO as part of the GIST spec AND going for = standards
track. The = envisioned solutions to this is, revert to packet = filtering
mechanism (e.g. = 5-tuple) to intercept GIST packets, instead of RAO, = in
the GIST specification. = This would be allowed to go GIST as standard
track. The RAO part will be cut out of the GIST spec and = pushed to a
separate document. = This new document will go on experimental track. =

This splitting will also effect the NSLPs, as they are = also
definin = RAO
usage. =

 Martin



stiemerling@nw.neclab.eu
<= /blockquote>

NEC Laboratories Europe - Network Research Division NEC =
Europe Limited = |
Registered Office: NEC = House, 1 Victoria Road, London W3 6BL |
Registered in England 2832014
_______________________________________________
nsis mailing = list
nsis@ietf.org
https://www.ietf.org/m= ailman/listinfo/nsis
_______________________________________________
nsis mailing = list
nsis@ietf.org
https://www.ietf.org/m= ailman/listinfo/nsis

___________________________________________= ____
nsis mailing list
nsis@ietf.org
https://www.ietf.org/ma= ilman/listinfo/nsis

= --Apple-Mail-5--401044760-- --===============1667490602== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1667490602==-- From pcn-bounces@ietf.org Wed May 28 06:48:24 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF0E928C113; Wed, 28 May 2008 06:48:24 -0700 (PDT) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDFD728C113 for ; Wed, 28 May 2008 06:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xg3vN8J19SRq for ; Wed, 28 May 2008 06:48:19 -0700 (PDT) Received: from rsys001x.roke.co.uk (rsys001x.roke.co.uk [193.118.201.108]) by core3.amsl.com (Postfix) with ESMTP id 4B6D028C10A for ; Wed, 28 May 2008 06:48:19 -0700 (PDT) Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id m4SDl2AM027048; Wed, 28 May 2008 14:47:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 14:47:02 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fwd: [NSIS] Status update about GIST Thread-Index: AcjAyCG0dQo6s/REQ7GXJ19PHyCFfAAABZgQ References: <134B71ED-F91C-485C-A264-E9C70FD332CC@g11.org.uk> From: "Hancock, Robert" To: , X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk Subject: Re: [PCN] Fwd: [NSIS] Status update about GIST X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0258977335==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0258977335== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C0C9.4EF85636" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8C0C9.4EF85636 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ken, =20 indeed - i'd forgotten the PCN discussions on this. =20 however, it's worth pointing out that there's potentially a difference of applicability of the argument in the PCN case. In my understanding of PCN, it will only get implemented in a per-operator-domain-internal fashion, so an operator will be free to deploy PCN or not depending on their confidence in the RAO implementations of their current routers; and deploying PCN in one domain won't cause RAO-related problems for anyone else. =20 whether or not that's a real difference i can't say. but my recommendation would be: - make sure that any base spec does not depend on RAO - for anything that does depend on RAO, ask for AD guidance early (e.g. now) =20 robert h. ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of carlberg@g11.org.uk Sent: 28 May 2008 14:38 To: pcn@ietf.org Subject: [PCN] Fwd: [NSIS] Status update about GIST =09 =09 There had been a discussion on the use of RAO on this list prior to the Philly IETF, so its probably constructive to forward the following from the NSIS list.=20 -ken Begin forwarded message: From: "Hancock, Robert" Date: May 28, 2008 8:40:37 AM EDT To: , , Subject: Re: [NSIS] Status update about GIST john,=20 =09 =09 -----Original Message----- =09 From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 =09 Behalf Of john.loughney@nokia.com =09 Sent: 28 May 2008 03:19 =09 To: Stiemerling@nw.neclab.eu; nsis@ietf.org =09 Subject: Re: [NSIS] Status update about GIST =09 Martin, =09 Does this mean that the use RAO is basically thought of as a bad thing =09 by the IESG? =09 my interpretation of the discussion is that:=20 =09 IF your protocol * uses RAO, and * has any likelihood of significant deployment on the Internet (where "significant" is defined as "more than RSVP for QoS") THEN=20 * it will be experimental =09 ... at least for IPv4. the IPv6 case is (at least to me) much less clear cut: theoretically/architecturally they should be the same, but the practical/engineering issues are quite different. =09 one of the routing ADs is going to write a draft explaining this. =09 robert h. =09 [[reh]] [other stuff snipped]=20 ------_=_NextPart_001_01C8C0C9.4EF85636 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
ken,
 
indeed - i'd forgotten the PCN discussions on=20 this.
 
however, it's worth pointing out that there's = potentially a=20 difference of applicability of the argument in the PCN case. In my = understanding=20 of PCN, it will only get implemented in a per-operator-domain-internal = fashion,=20 so an operator will be free to deploy PCN or not depending on their = confidence=20 in the RAO implementations of their current routers; and deploying PCN = in one=20 domain won't cause RAO-related problems for anyone = else.
 
whether or not that's a real = difference i can't=20 say. but my recommendation would be:
- make sure that any base spec does not = depend on=20 RAO
- for anything that does depend on RAO, ask for = AD guidance=20 early (e.g. now)
 
robert h.

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of=20 carlberg@g11.org.uk
Sent: 28 May 2008 = 14:38
To:=20 pcn@ietf.org
Subject: [PCN] Fwd: [NSIS] Status update about=20 GIST

There had been a discussion on the use of RAO on this list = prior to=20 the Philly IETF, so its probably constructive to forward the following = from=20 the NSIS list.

-ken


Begin forwarded message:

From: "Hancock, = Robert" <robert.hancock@roke.co.uk&g= t;
Date: May 28, = 2008 8:40:37 AM=20 EDT
To: <john.loughney@nokia.com>, = <Stiemerling@nw.neclab.eu>= ,=20 <nsis@ietf.org>
Subject: = Re: = [NSIS] Status=20 update about GIST

john, =

-----Original = Message-----
From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On=20
Behalf Of john.loughney@nokia.com
Sent: 28 May 2008 03:19
To: Stiemerling@nw.neclab.eu; = nsis@ietf.org
Subject: Re: [NSIS] Status update about=20 GIST

Martin,

Does this mean that the use RAO is = basically=20 thought of as a bad thing
by the IESG?

my = interpretation=20 of the discussion is that:

IF your protocol
* uses RAO, = and
*=20 has any likelihood of significant deployment on the = Internet
 (where=20 "significant" is defined as "more than RSVP for QoS")
THEN
* = it will=20 be experimental

... at least for IPv4. the IPv6 case is (at = least to=20 me) much
less clear cut: theoretically/architecturally they = should=20 be
the same, but the practical/engineering issues are quite=20 different.

one of the routing ADs is going to write a draft=20 explaining this.

robert h.

[[reh]] [other stuff=20 = snipped] 
= ------_=_NextPart_001_01C8C0C9.4EF85636-- --===============0258977335== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0258977335==--