From pcn-bounces@ietf.org Fri Dec 01 02:41:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq31O-0006Gi-0Z; Fri, 01 Dec 2006 02:41:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq31M-0006Dm-L4 for pcn@ietf.org; Fri, 01 Dec 2006 02:41:20 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq31E-0008WN-Hk for pcn@ietf.org; Fri, 01 Dec 2006 02:41:20 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2FB3253C; Fri, 1 Dec 2006 08:40:47 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 08:40:46 +0100 Received: from ericsson.com ([147.214.26.58]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 08:40:46 +0100 Message-ID: <456FDC7E.6090205@ericsson.com> Date: Fri, 01 Dec 2006 08:40:46 +0100 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Anna Charny (acharny)" Subject: Re: [PCN] PCN updated charter References: <6.2.5.6.0.20061130151750.0337a6b8@nortel.com> In-Reply-To: <6.2.5.6.0.20061130151750.0337a6b8@nortel.com> X-OriginalArrivalTime: 01 Dec 2006 07:40:46.0805 (UTC) FILETIME=[03A96850:01C7151C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.6 (/) X-Scan-Signature: 958aa603499a3de6b2b87d68741ed60e Cc: Lars Eggert , pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2080843019==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============2080843019== Content-Type: multipart/alternative; boundary="------------000809020806080703030903" This is a multi-part message in MIME format. --------------000809020806080703030903 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit it is a decsion to take-out the application deployment model already? I would recommend that we include this model a part of the first phase of the working group. I am very interest to contribute from this scenario perspective. regards Lasse Kwok-Ho Chan wrote: > Anna: > Thank you for the agreements. > I agree with your agreements, hence the only response I have is > at the bottom of the E-Mail with and . > > Bottom line at the Top: > Keeping the Application/SIP Deployment Model document in the > first phase PCN Charter is beneficial to the WG. > Having it in the first phase PCN Charter will help rather then hurt > the WG. > And there are accountable resource in the WG to get the work done. > > -- Kwok -- > > At 01:20 PM 11/30/2006, Anna Charny \(acharny\) wrote: > >Hi Kwok, > > > > >>Anna begin> > > >> > > >>PWE3-related deployment model has already been taken out of the > >updated > > >>charter, based on the BOF input. > > >> > > >>As to SIP-related one - there is one aspect of it that actually > > >>potentially affects the marking at the ingress node, namely the > > >>aggregation assumptions, and especially aggregation level on a > > >>per-ingress-egress aggregate. This specific model is likely to assume > > > > >>both lower levels of aggregation on the PCN internal links, but > > >>especially on a per-ingress-egress pair basis. From the work available > > > > >>by now it seems relatively clear that if the core marking is to > > >>accommodate this, the decision on *when* to mark packes may be > > >>affected, and that additional flexibility in the marking at the > > >>internal > > >>node may be potentially needed. So in the very least this needs to > >be > > >>"kept in mind" even if the SIP (or application-related) deployment is > > >>taken out of the charter. > > > > > > > >Anna, I disagree with you on your points of: > > >>"This specific model is likely to assume both lower levels of > > >>aggregation on the PCN internal links, but especially on a > >per-ingress- > > >>egress pair basis." > > > > >There are no strict requirements that Application (SIP) based usage of > > >PCN must use lower levels of aggregation on the PCN internal links. > > >Nor requirements that Application (SIP) based usage must use lower > > >levels of aggregation on a per-ingress-egress pair basis. > > >I believe we should try to push the envelop of applicability as much as > > >we can. > > > >I fully agree that we should push the envelop of applicability as much > >as we can. With respect to the aggregation level discussion it means > >that we might want to look into how low hese levels of aggregation could > >be. I merely stated that for a SIP-based model one might expect a lower > >degree of aggregation than that of an Intserv-over-diffserv model. I > >think we are in agrrement that it would be beneficial if the WG looked > >into the issue of how low the level of aggregation can be, and how it > >affects the marking (if at all). > > > > >We've indicated in our earlier work (for example, showing you our > > >simulation work so we can cover different aspects of the problem space > > > the usage of lower levels of aggregation (at different parts of the > >PCN >region) because there are deployment scenarios (with interested > >users) > > >that will benefit from such work. > > > >Yes. That is right. I do not think there is any disgreement on that. > > > > >Further more, as you know, there are encouraging simulation results on > > >lower levels of aggregation on a per-ingress-egress pair basis. > > >The degree of "how low" will be details that can be indicated in the > > >work of the PCN (to-be)WG. > > > >Yes. I agree with that. In my opinion, perhaps the most important > >aspect of the Sip/application based deployment model is the possible > >limits of aggregation appropriate for that deployment model. What I was > >trying to say is that IF the decision is made to move the SIP-deployment > >model to a later phase, the exploration of the limits of aggregation > >appropriate for that deplyment model may nevertheless need to stay in > >scope of the early work of the WG, as it may affect the router behavior > >that needs to be standardized. > > > > >On you point of " > > >>"From the work available by now it seems relatively clear that if the > > >>core marking is to accommodate this, the decision on *when* to mark > > >>packets may be affected, and that additional flexibility in the > >marking > > >>at the internal node may be potentially needed. So in the very least > > > > >>this needs to be "kept in mind" even if the SIP (or application- > > >>related) deployment is taken out of the charter." > > > > >IMHO, it should NOT be the goal of the WG to change the Standards Track > > >work (the internal mode when to mark packets, marking syntax, the > > >marking semantics) between the different (re-chartering) phases of > > >the(to-be) WG. > > > >I do agree with that. I do not think I was agruing for changing the > >router marking semantics between recharterings at all. In fact I was > >arguing for exactly the opposite. I was saying that a possible > >difference in the aggregation level between different deployment models > >*may* have impact on the marking semantics and potentially edge behavior > >(my understanding is that the jury is out on this yet, although there > >are good indications that both models may in fact use the same > >semantics). > >Therefore this aspect (potential impact of appropriate level of > >aggregation on the marking semantics) needs to be looked at early on, if > >SIP/Application deployment model is to be considered at any phase on > >the work (now or later)at all. I was in fact arguing that it needs to be > >looked at before rechartering. > > > >But as to other aspects of the SIP/Application model (beyond the > >aggregation level and its impact on the marking semantics and edge > >behavior), I do not personally see a reason why they can not wait till > >after rechartering. > > > The SIP/Application Deployment Model document will put the applicability > of this work in place. It is always good to do this explicitly > rather then implicitly. > This will provide clarity and openness to the work done by the WG. > > The content for SIP/Application Deployment Model document is not really > new work for the people writing it. > The SIP/Application Deployment Model document will help the WG to > understand > one possible environment of how PCN can be used. > Further more the SIP/Application Deployment Model document is there so > the simulation results (for the work we agreed to above) can be > understood. > > And there are already people doing this work that is beneficial to the WG. > > And we should have more than one Deployment Model for PCN. This will > strengthen > the Standards Track part of the work we are doing. > > Hence I propose to keep the SIP/Application Deployment Model document > as part > of the first phase Charter of PCN. > > > > >Anna > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > --------------000809020806080703030903 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit it is a decsion to take-out the application deployment model already?

I would recommend that we include this model a part of the first phase of the working group.
I am very interest to contribute from this scenario perspective.

regards Lasse

Kwok-Ho Chan wrote:
RE: [PCN] PCN updated charter

Anna:
Thank you for the agreements.
I agree with your agreements, hence the only response I have is
at the bottom of the E-Mail with <Kwok_Start> and <Kwok_End>.

Bottom line at the Top:
Keeping the Application/SIP Deployment Model document in the
first phase PCN Charter is beneficial to the WG.
Having it in the first phase PCN Charter will help rather then hurt the WG.
And there are accountable resource in the WG to get the work done.

-- Kwok --

At 01:20 PM 11/30/2006, Anna Charny \(acharny\) wrote:
>Hi Kwok,
>
> >>Anna begin>
> >>
> >>PWE3-related deployment model has already been taken out of the
>updated
> >>charter, based on the BOF input.
> >>
> >>As to SIP-related one  -  there is one aspect of it that actually
> >>potentially affects the marking at the ingress node, namely the
> >>aggregation assumptions, and especially aggregation level on a
> >>per-ingress-egress aggregate.  This specific model is likely to assume
>
> >>both lower levels of aggregation on the PCN internal links, but
> >>especially on a per-ingress-egress pair basis. From the work available
>
> >>by now it seems relatively clear that if the core marking is to
> >>accommodate this,  the decision on *when* to mark packes may be
> >>affected, and that additional flexibility in the marking at the
> >>internal
> >>node may be potentially needed.   So in the very least this needs to
>be
> >>"kept in mind" even if the SIP (or application-related) deployment is
> >>taken out of the charter.
>
> ><Kwok_Start>
> >Anna, I disagree with you on your points of:
> >>"This specific model is likely to assume both lower levels of
> >>aggregation on the PCN internal links, but especially on a
>per-ingress-
> >>egress pair basis."
>
> >There are no strict requirements that Application (SIP) based usage of
> >PCN must use lower levels of aggregation on the PCN internal links.
> >Nor requirements that Application (SIP) based usage must use lower
> >levels of aggregation on a per-ingress-egress pair basis.
> >I believe we should try to push the envelop of applicability as much as
> >we can.
>
>I fully agree that we should push the envelop of applicability as much
>as we can. With respect to the aggregation level discussion it means
>that we might want to look into how low hese levels of aggregation could
>be.  I merely stated that for a SIP-based model one might expect a lower
>degree of aggregation than that of an Intserv-over-diffserv model. I
>think we are in agrrement that it would be beneficial if the WG looked
>into the issue of how low the level of aggregation can be, and how it
>affects the marking (if at all).
>
> >We've indicated in our earlier work (for example, showing you our
> >simulation work so we can cover different aspects of the problem space
> > the usage of lower levels of aggregation (at different parts of the
>PCN >region) because there are deployment scenarios (with interested
>users)
> >that will benefit from such work.
>
>Yes. That is right.  I do not think there is any disgreement on that.
>
> >Further more, as you know, there are encouraging simulation results on
> >lower levels of aggregation on a per-ingress-egress pair basis.
> >The degree of "how low" will be details that can be indicated in the
> >work of the PCN (to-be)WG.
>
>Yes. I agree with that.  In my opinion, perhaps the most important
>aspect of the Sip/application based deployment model is the possible
>limits of aggregation appropriate for that deployment model.  What I was
>trying to say is that IF the decision is made to move the SIP-deployment
>model to a later phase, the exploration of the limits of aggregation
>appropriate for that deplyment model may nevertheless need to stay in
>scope of the early work of the WG, as it may affect the router behavior
>that needs to be standardized.
>
> >On you point of "
> >>"From the work available by now it seems relatively clear that if the
> >>core marking is to accommodate this,  the decision on *when* to mark
> >>packets may be affected, and that additional flexibility in the
>marking
> >>at the internal node may be potentially needed.   So in the very least
>
> >>this needs to be "kept in mind" even if the SIP (or application-
> >>related) deployment is taken out of the charter."
>
> >IMHO, it should NOT be the goal of the WG to change the Standards Track
> >work (the internal mode when to mark packets, marking syntax, the
> >marking semantics) between the different (re-chartering) phases of
> >the(to-be) WG.
>
>I do agree with that. I do not think I was agruing for changing the
>router marking semantics between recharterings at all. In fact I was
>arguing for exactly the opposite.  I was saying that a possible
>difference in the aggregation level between different deployment models
>*may* have impact on the marking semantics and potentially edge behavior
>(my understanding is that the jury is out on this yet, although there
>are good indications that both models may in fact use the same
>semantics).
>Therefore this aspect (potential impact of appropriate level of
>aggregation on the marking semantics) needs to be looked at early on, if
>SIP/Application deployment  model is to be considered at any phase on
>the work (now or later)at all. I was in fact arguing that it needs to be
>looked at before rechartering.
>
>But as to other aspects of the SIP/Application model (beyond the
>aggregation level and its impact on the marking semantics and edge
>behavior), I do not personally see a reason why they can not wait till
>after rechartering.

<Kwok_Start>
The SIP/Application Deployment Model document will put the applicability
of this work in place.  It is always good to do this explicitly
rather then implicitly.
This will provide clarity and openness to the work done by the WG.

The content for SIP/Application Deployment Model document is not really
new work for the people writing it.
The SIP/Application Deployment Model document will help the WG to understand
one possible environment of how PCN can be used.
Further more the SIP/Application Deployment Model document is there so
the simulation results (for the work we agreed to above) can be understood.

And there are already people doing this work that is beneficial to the WG.

And we should have more than one Deployment Model for PCN.  This will
strengthen
the Standards Track part of the work we are doing.

Hence I propose to keep the SIP/Application Deployment Model document as part
of the first phase Charter of PCN.
<Kwok_End>


>Anna


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

--------------000809020806080703030903-- --===============2080843019== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============2080843019==-- From pcn-bounces@ietf.org Fri Dec 01 02:46:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq36c-0000Bo-PA; Fri, 01 Dec 2006 02:46:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq36b-0000Bg-Qa for pcn@ietf.org; Fri, 01 Dec 2006 02:46:45 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq36a-0000pg-9g for pcn@ietf.org; Fri, 01 Dec 2006 02:46:45 -0500 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Fri, 1 Dec 2006 08:46:38 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 08:46:38 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Subject: RE: [PCN] PCN updated charter Date: Fri, 1 Dec 2006 08:46:37 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF9D6@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN updated charter Thread-Index: AccUo3pW11QInA+tS1qTUI2gKD+XXgAAzjiQAB1CP7A= From: "Geib, Ruediger" To: X-OriginalArrivalTime: 01 Dec 2006 07:46:38.0514 (UTC) FILETIME=[D54BF120:01C7151C] X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Anna, thanks for emphasising the different aggregation levels=20 and the proposal to think about different marking=20 mechanisms in each. That seems to me to be a point=20 which may be more important than the question, by=20 which protocol one signals for service. Regards, Rudiger (no more comments) |-----Original Message----- |From: Anna Charny (acharny) [mailto:acharny@cisco.com] |Sent: Thursday, November 30, 2006 7:21 PM |To: Kwok-Ho Chan |Cc: Lars Eggert; pcn@ietf.org |Subject: RE: [PCN] PCN updated charter | | |Hi Kwok, |=20 |>>Anna begin> |>> |>>PWE3-related deployment model has already been taken out of the |updated=20 |>>charter, based on the BOF input. |>> |>>As to SIP-related one - there is one aspect of it that actually=20 |>>potentially affects the marking at the ingress node, namely the=20 |>>aggregation assumptions, and especially aggregation level on a=20 |>>per-ingress-egress aggregate. This specific model is likely=20 |to assume | |>>both lower levels of aggregation on the PCN internal links, but=20 |>>especially on a per-ingress-egress pair basis. From the work=20 |available | |>>by now it seems relatively clear that if the core marking is to=20 |>>accommodate this, the decision on *when* to mark packes may be=20 |>>affected, and that additional flexibility in the marking at the=20 |>>internal |>>node may be potentially needed. So in the very least this needs to |be |>>"kept in mind" even if the SIP (or application-related)=20 |deployment is=20 |>>taken out of the charter. | |> |>Anna, I disagree with you on your points of: |>>"This specific model is likely to assume both lower levels of=20 |>>aggregation on the PCN internal links, but especially on a |per-ingress- |>>egress pair basis." | |>There are no strict requirements that Application (SIP) based=20 |usage of=20 |>PCN must use lower levels of aggregation on the PCN internal links. |>Nor requirements that Application (SIP) based usage must use lower=20 |>levels of aggregation on a per-ingress-egress pair basis. |>I believe we should try to push the envelop of applicability=20 |as much as |>we can. | |I fully agree that we should push the envelop of applicability as much |as we can. With respect to the aggregation level discussion it means |that we might want to look into how low hese levels of=20 |aggregation could |be. I merely stated that for a SIP-based model one might=20 |expect a lower |degree of aggregation than that of an Intserv-over-diffserv model. I |think we are in agrrement that it would be beneficial if the WG looked |into the issue of how low the level of aggregation can be, and how it |affects the marking (if at all). | |>We've indicated in our earlier work (for example, showing you our=20 |>simulation work so we can cover different aspects of the problem space |> the usage of lower levels of aggregation (at different parts of the |PCN >region) because there are deployment scenarios (with interested |users) |>that will benefit from such work. | |Yes. That is right. I do not think there is any disgreement on that. | |>Further more, as you know, there are encouraging simulation=20 |results on=20 |>lower levels of aggregation on a per-ingress-egress pair basis. |>The degree of "how low" will be details that can be indicated in the |>work of the PCN (to-be)WG. | |Yes. I agree with that. In my opinion, perhaps the most important |aspect of the Sip/application based deployment model is the possible |limits of aggregation appropriate for that deployment model. =20 |What I was |trying to say is that IF the decision is made to move the=20 |SIP-deployment |model to a later phase, the exploration of the limits of aggregation |appropriate for that deplyment model may nevertheless need to stay in |scope of the early work of the WG, as it may affect the router behavior |that needs to be standardized. | |>On you point of " |>>"From the work available by now it seems relatively clear that if the |>>core marking is to accommodate this, the decision on *when* to mark |>>packets may be affected, and that additional flexibility in the |marking |>>at the internal node may be potentially needed. So in the=20 |very least | |>>this needs to be "kept in mind" even if the SIP (or application- |>>related) deployment is taken out of the charter." | |>IMHO, it should NOT be the goal of the WG to change the=20 |Standards Track |>work (the internal mode when to mark packets, marking syntax, the=20 |>marking semantics) between the different (re-chartering) phases of=20 |>the(to-be) WG.=20 | |I do agree with that. I do not think I was agruing for changing the |router marking semantics between recharterings at all. In fact I was |arguing for exactly the opposite. I was saying that a possible |difference in the aggregation level between different deployment models |*may* have impact on the marking semantics and potentially=20 |edge behavior |(my understanding is that the jury is out on this yet, although there |are good indications that both models may in fact use the same |semantics). =20 |Therefore this aspect (potential impact of appropriate level of |aggregation on the marking semantics) needs to be looked at=20 |early on, if |SIP/Application deployment model is to be considered at any phase on |the work (now or later)at all. I was in fact arguing that it=20 |needs to be |looked at before rechartering. | |But as to other aspects of the SIP/Application model (beyond the |aggregation level and its impact on the marking semantics and edge |behavior), I do not personally see a reason why they can not wait till |after rechartering. =20 | |Anna | |_______________________________________________ |PCN mailing list |PCN@ietf.org |https://www1.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Dec 01 05:00:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq5Ba-0004WG-3L; Fri, 01 Dec 2006 05:00:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq5BY-0004Vs-Fw for pcn@ietf.org; Fri, 01 Dec 2006 05:00:00 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq5BS-0003F7-Ss for pcn@ietf.org; Fri, 01 Dec 2006 05:00:00 -0500 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 09:59:38 +0000 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Dec 2006 09:59:37 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN updated charter Date: Fri, 1 Dec 2006 09:59:35 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CEE5@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650D7719D5@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN updated charter Thread-Index: AccT/4+UymL8PT7DTgq3/m9pfto2/AAY6jsQAA9YqQAAIQCNwA== From: To: , , X-OriginalArrivalTime: 01 Dec 2006 09:59:37.0385 (UTC) FILETIME=[69130990:01C7152F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi, I agree with joe that there is some dependency between marking behaviour in routers, reaction by edge nodes and the encoding. To me this suggests it's appropriate to work on them at the same time. So I'd prefer it if the 'phase 1' of the charter could include work on all three. I also think the choice of encoding depends on the router & edge behaviours more strongly than the other way round (ie more strongly than the router & edge behaviours depend on the encoding). So an alternative way to segment the work could be to do the router & edge behaviours first & the encoding second? Best wishes, Phil > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com] > Sent: 30 November 2006 17:12 > To: Eardley,PL,Philip,CXR9 R; lars.eggert@netlab.nec.de; pcn@ietf.org > Subject: RE: [PCN] PCN updated charter >=20 > Lars wrote: > "But that wasn't my point. Without even going into the semantics of > various markings, a number of issues have been brought up with regards > to _encoding_ this information using the ECN bits, DSCPs, IP options, > etc. This should be worked out first, because the encoding choices may > limit what marking semantics can be defined later, which in turn affects > what edge behaviors are possible." > [Joe]I think that it would be appropriate for the WG to reach agreement > on what bits could be used for PCN before finalizing on the marking > behavior in the routers or edge/host behavior. However, there are some > dependences between, marking behavior in routers, reaction by edge nodes > and the encoding. >=20 >=20 > Regards, Joe > QoS & Network Architecture > Telephone: 613-763-6098 (ESN 393-6098) > Email: babiarz@nortel.com >=20 > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: Thursday, November 30, 2006 4:47 AM > To: lars.eggert@netlab.nec.de; pcn@ietf.org > Subject: RE: [PCN] PCN updated charter >=20 > >>This [=3D the encoding choice] should be worked out first, because = the > encoding choices may limit what marking semantics can be defined later, > which in turn affects what edge behaviors are possible. > >> >=20 > I'm not sure the encoding choices do limit the marking semantics that > much. I think the main impact of the encoding choice is on non-PCN > things like compatibility with RFC3168 & DSCP usage. >=20 > phil >=20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@netlab.nec.de] > Sent: 29 November 2006 21:44 > To: pcn@ietf.org > Subject: Re: [PCN] PCN updated charter >=20 > On Nov 29, 2006, at 13:19, Anna Charny (acharny) wrote: > > Perhaps stressing in the charter that the WG will consider the > > implications of the lower levels of ingress-egress aggregation on the > > marking mechanisms may address this issue? >=20 > Maybe. I think I need to digest this issue a bit more. >=20 > > With respect to your discussion with Ken on the problem statement > > draft, > > I do not see any problem with combining it with the architecture > > document. A large portion of the work has been already done in > > this in > > the various individual drafts, so this particular deliverable does not > > appear to be terribly limiting to me either way. >=20 > Right. The existing documents may have much of the required material > already. Whether there will be one vs. a number of documents that > convey this content is mostly a matter of presentation. >=20 > > I interpret he above to mean that you propose to work on the encoding > > and the actual marking decisions at the internal PCN router (as > > well as > > one deployment model and prob statement), but that the edge behavior > > should come later (after re-chartering). Is that a correct > > interpretation? >=20 > Right. >=20 > > I worry about taking the consideration of edge behaviors out of the > > charter. > > The primary cause of this worry is that edge behaviors depend on the > > meaning of the marking. For example, if the marking is "red- > > like" (e.g. > > virtual-queue based) its meaning is quite different than if the > > marking > > is excess-rate based (e.g. token-bucket based", and the appropriate > > edge > > behavior, to do "the right thing", needs to reflect the meaning of > > the > > marking. I just cannot see how you can completely divorce one from > > the > > other meaningfully. >=20 > I agree that the meaning of the markings is important for the edge > algorithm and that the two are difficult to separate. >=20 > But that wasn't my point. Without even going into the semantics of > various markings, a number of issues have been brought up with > regards to _encoding_ this information using the ECN bits, DSCPs, IP > options, etc. This should be worked out first, because the encoding > choices may limit what marking semantics can be defined later, which > in turn affects what edge behaviors are possible. >=20 > > Another point is that if the first phase of the work does only the > > marking behavior, and does not get re-chartered, than the product > > of the > > WG might not result in a standard that allows interoperability (as > > different edge devices may do things incompatible with the meaning of > > the marking and/or with each other). >=20 > If this first phase of work completes successfully, I fully expect a > rechartering to occur, and the initial charter should probably > contain an explicit rechartering milestone together with a brief > paragraph about what the goal of the rechartering should be. >=20 > If for some reason the WG runs aground in the first phase or decides > not to recharter, yes, the set of RFCs it has produced won't be > terribly useful. Frankly, that isn't the worst possible outcome in > such a case. (But I don't think there is a real danger of this here.) >=20 > > So I would argue against taking the consideration of edge behaviors > > out > > of the charter, even in the first phase. >=20 > Lars >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Dec 01 05:40:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq5ow-0000mT-Nr; Fri, 01 Dec 2006 05:40:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq5ow-0000mA-2C for pcn@ietf.org; Fri, 01 Dec 2006 05:40:42 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq5ou-0007p9-Gy for pcn@ietf.org; Fri, 01 Dec 2006 05:40:42 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id kB1AeR5T028705; Fri, 1 Dec 2006 11:40:37 +0100 (MET) From: "Georgios Karagiannis" To: "'Kwok-Ho Chan'" , "'Anna Charny \(acharny\)'" Subject: RE: [PCN] PCN updated charter Date: Fri, 1 Dec 2006 11:40:22 +0100 Message-ID: <000d01c71535$1fef3990$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <6.2.5.6.0.20061130151750.0337a6b8@nortel.com> Thread-Index: AccUxHOpiwjg6Z4cQ+WNOysJ09tw6wAcH6xg X-Spam-Score: 0.413 () AWL,J_CHICKENPOX_52 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 01 Dec 2006 11:40:38 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: 'Lars Eggert' , pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Anna I agree with Kwok on the following: > Keeping the Application/SIP Deployment Model document in the > first phase PCN Charter is beneficial to the WG. > Having it in the first phase PCN Charter will help rather > then hurt the WG. > And there are accountable resource in the WG to get the work done. Best regards, Georgios > -----Original Message----- > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > Sent: donderdag 30 november 2006 21:58 > To: Anna Charny (acharny) > Cc: Lars Eggert; pcn@ietf.org > Subject: RE: [PCN] PCN updated charter > > Anna: > Thank you for the agreements. > I agree with your agreements, hence the only response I have > is at the bottom of the E-Mail with and . > > Bottom line at the Top: > Keeping the Application/SIP Deployment Model document in the > first phase PCN Charter is beneficial to the WG. > Having it in the first phase PCN Charter will help rather > then hurt the WG. > And there are accountable resource in the WG to get the work done. > > -- Kwok -- > > At 01:20 PM 11/30/2006, Anna Charny \(acharny\) wrote: > >Hi Kwok, > > > > >>Anna begin> > > >> > > >>PWE3-related deployment model has already been taken out of the > >updated > > >>charter, based on the BOF input. > > >> > > >>As to SIP-related one - there is one aspect of it that actually > > >>potentially affects the marking at the ingress node, namely the > > >>aggregation assumptions, and especially aggregation level on a > > >>per-ingress-egress aggregate. This specific model is likely to > > >>assume > > > > >>both lower levels of aggregation on the PCN internal links, but > > >>especially on a per-ingress-egress pair basis. From the work > > >>available > > > > >>by now it seems relatively clear that if the core marking is to > > >>accommodate this, the decision on *when* to mark packes may be > > >>affected, and that additional flexibility in the marking at the > > >>internal > > >>node may be potentially needed. So in the very least > this needs to > >be > > >>"kept in mind" even if the SIP (or application-related) > deployment > > >>is taken out of the charter. > > > > > > > >Anna, I disagree with you on your points of: > > >>"This specific model is likely to assume both lower levels of > > >>aggregation on the PCN internal links, but especially on a > >per-ingress- > > >>egress pair basis." > > > > >There are no strict requirements that Application (SIP) > based usage > > >of PCN must use lower levels of aggregation on the PCN > internal links. > > >Nor requirements that Application (SIP) based usage must use lower > > >levels of aggregation on a per-ingress-egress pair basis. > > >I believe we should try to push the envelop of > applicability as much > > >as we can. > > > >I fully agree that we should push the envelop of > applicability as much > >as we can. With respect to the aggregation level discussion it means > >that we might want to look into how low hese levels of aggregation > >could be. I merely stated that for a SIP-based model one > might expect > >a lower degree of aggregation than that of an Intserv-over-diffserv > >model. I think we are in agrrement that it would be > beneficial if the > >WG looked into the issue of how low the level of aggregation can be, > >and how it affects the marking (if at all). > > > > >We've indicated in our earlier work (for example, showing you our > > >simulation work so we can cover different aspects of the problem > > >space the usage of lower levels of aggregation (at > different parts > > >of the > >PCN >region) because there are deployment scenarios (with interested > >users) > > >that will benefit from such work. > > > >Yes. That is right. I do not think there is any disgreement on that. > > > > >Further more, as you know, there are encouraging > simulation results > > >on lower levels of aggregation on a per-ingress-egress pair basis. > > >The degree of "how low" will be details that can be > indicated in the > > >work of the PCN (to-be)WG. > > > >Yes. I agree with that. In my opinion, perhaps the most important > >aspect of the Sip/application based deployment model is the possible > >limits of aggregation appropriate for that deployment model. What I > >was trying to say is that IF the decision is made to move the > >SIP-deployment model to a later phase, the exploration of > the limits of > >aggregation appropriate for that deplyment model may > nevertheless need > >to stay in scope of the early work of the WG, as it may affect the > >router behavior that needs to be standardized. > > > > >On you point of " > > >>"From the work available by now it seems relatively clear that if > > >>the core marking is to accommodate this, the decision on > *when* to > > >>mark packets may be affected, and that additional > flexibility in the > >marking > > >>at the internal node may be potentially needed. So in > the very least > > > > >>this needs to be "kept in mind" even if the SIP (or application- > > >>related) deployment is taken out of the charter." > > > > >IMHO, it should NOT be the goal of the WG to change the Standards > > >Track work (the internal mode when to mark packets, > marking syntax, > > >the marking semantics) between the different > (re-chartering) phases > > >of > > >the(to-be) WG. > > > >I do agree with that. I do not think I was agruing for changing the > >router marking semantics between recharterings at all. In fact I was > >arguing for exactly the opposite. I was saying that a possible > >difference in the aggregation level between different > deployment models > >*may* have impact on the marking semantics and potentially edge > >behavior (my understanding is that the jury is out on this yet, > >although there are good indications that both models may in fact use > >the same semantics). > >Therefore this aspect (potential impact of appropriate level of > >aggregation on the marking semantics) needs to be looked at > early on, > >if SIP/Application deployment model is to be considered at > any phase > >on the work (now or later)at all. I was in fact arguing that > it needs > >to be looked at before rechartering. > > > >But as to other aspects of the SIP/Application model (beyond the > >aggregation level and its impact on the marking semantics and edge > >behavior), I do not personally see a reason why they can not > wait till > >after rechartering. > > > The SIP/Application Deployment Model document will put the > applicability of this work in place. It is always good to do > this explicitly rather then implicitly. > This will provide clarity and openness to the work done by the WG. > > The content for SIP/Application Deployment Model document is > not really new work for the people writing it. > The SIP/Application Deployment Model document will help the > WG to understand one possible environment of how PCN can be used. > Further more the SIP/Application Deployment Model document is > there so the simulation results (for the work we agreed to > above) can be understood. > > And there are already people doing this work that is > beneficial to the WG. > > And we should have more than one Deployment Model for PCN. > This will strengthen the Standards Track part of the work we > are doing. > > Hence I propose to keep the SIP/Application Deployment Model > document as part of the first phase Charter of PCN. > > > > >Anna > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Dec 01 09:45:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq9do-00035Y-MA; Fri, 01 Dec 2006 09:45:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq9dn-00035O-6z for pcn@ietf.org; Fri, 01 Dec 2006 09:45:27 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq9dl-00044C-Id for pcn@ietf.org; Fri, 01 Dec 2006 09:45:27 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 01 Dec 2006 06:45:25 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id kB1EjOB1030156; Fri, 1 Dec 2006 06:45:24 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kB1EjAOf000278; Fri, 1 Dec 2006 06:45:21 -0800 (PST) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 09:44:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN updated charter Date: Fri, 1 Dec 2006 09:44:54 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN updated charter Thread-Index: AccT/4+UymL8PT7DTgq3/m9pfto2/AAY6jsQAA9YqQAAIQCNwAAMgZGg From: "Anna Charny \(acharny\)" To: , , , X-OriginalArrivalTime: 01 Dec 2006 14:44:55.0798 (UTC) FILETIME=[44719160:01C71557] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6850; t=1164984324; x=1165848324; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20\(acharny\)=22=20 |Subject:=20RE=3A=20[PCN]=20PCN=20=20updated=20charter |Sender:=20; bh=puuoNnUrOZtSHiZjVnPSsyyHTldLRJlQ+C1sLEDrZvU=; b=VoN8MuihEpxaN8JW3Xd3H2iOxE8bOx6kzeXhK4/1mTTYHTozSGRS4s6oaK9NwF6B+DkQPhDf 05IuyMVX41NPSR8BqdRHtBfXz2X0eFzASuXtJRzjDvEo1Ad9M2HFXeVy; Authentication-Results: sj-dkim-8; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Phil, Yes, I agree. If we have to split the work on the encoding and the marking/edge mechanisms in two phases, I too would prefer to work on the mechanisms first, and the encoding second. =20 Anna =20 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Friday, December 01, 2006 5:00 AM To: babiarz@nortel.com; lars.eggert@netlab.nec.de; pcn@ietf.org Subject: RE: [PCN] PCN updated charter Hi, I agree with joe that there is some dependency between marking behaviour in routers, reaction by edge nodes and the encoding. To me this suggests it's appropriate to work on them at the same time. So I'd prefer it if the 'phase 1' of the charter could include work on all three. I also think the choice of encoding depends on the router & edge behaviours more strongly than the other way round (ie more strongly than the router & edge behaviours depend on the encoding). So an alternative way to segment the work could be to do the router & edge behaviours first & the encoding second? Best wishes, Phil > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com] > Sent: 30 November 2006 17:12 > To: Eardley,PL,Philip,CXR9 R; lars.eggert@netlab.nec.de; pcn@ietf.org > Subject: RE: [PCN] PCN updated charter >=20 > Lars wrote: > "But that wasn't my point. Without even going into the semantics of=20 > various markings, a number of issues have been brought up with regards > to _encoding_ this information using the ECN bits, DSCPs, IP options,=20 > etc. This should be worked out first, because the encoding choices may > limit what marking semantics can be defined later, which in turn affects > what edge behaviors are possible." > [Joe]I think that it would be appropriate for the WG to reach agreement > on what bits could be used for PCN before finalizing on the marking=20 > behavior in the routers or edge/host behavior. However, there are some > dependences between, marking behavior in routers, reaction by edge nodes > and the encoding. >=20 >=20 > Regards, Joe > QoS & Network Architecture > Telephone: 613-763-6098 (ESN 393-6098) > Email: babiarz@nortel.com >=20 > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: Thursday, November 30, 2006 4:47 AM > To: lars.eggert@netlab.nec.de; pcn@ietf.org > Subject: RE: [PCN] PCN updated charter >=20 > >>This [=3D the encoding choice] should be worked out first, because = the > encoding choices may limit what marking semantics can be defined later, > which in turn affects what edge behaviors are possible. > >> >=20 > I'm not sure the encoding choices do limit the marking semantics that=20 > much. I think the main impact of the encoding choice is on non-PCN=20 > things like compatibility with RFC3168 & DSCP usage. >=20 > phil >=20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@netlab.nec.de] > Sent: 29 November 2006 21:44 > To: pcn@ietf.org > Subject: Re: [PCN] PCN updated charter >=20 > On Nov 29, 2006, at 13:19, Anna Charny (acharny) wrote: > > Perhaps stressing in the charter that the WG will consider the=20 > > implications of the lower levels of ingress-egress aggregation on the > > marking mechanisms may address this issue? >=20 > Maybe. I think I need to digest this issue a bit more. >=20 > > With respect to your discussion with Ken on the problem statement=20 > > draft, I do not see any problem with combining it with the=20 > > architecture document. A large portion of the work has been already > > done in this in the various individual drafts, so this particular=20 > > deliverable does not > > appear to be terribly limiting to me either way. >=20 > Right. The existing documents may have much of the required material=20 > already. Whether there will be one vs. a number of documents that=20 > convey this content is mostly a matter of presentation. >=20 > > I interpret he above to mean that you propose to work on the encoding > > and the actual marking decisions at the internal PCN router (as well > > as one deployment model and prob statement), but that the edge=20 > > behavior should come later (after re-chartering). Is that a correct > > interpretation? >=20 > Right. >=20 > > I worry about taking the consideration of edge behaviors out of the=20 > > charter. > > The primary cause of this worry is that edge behaviors depend on the > > meaning of the marking. For example, if the marking is "red- like"=20 > > (e.g. > > virtual-queue based) its meaning is quite different than if the=20 > > marking is excess-rate based (e.g. token-bucket based", and the=20 > > appropriate edge behavior, to do "the right thing", needs to=20 > > reflect the meaning of the marking. I just cannot see how you can=20 > > completely divorce one from the other meaningfully. >=20 > I agree that the meaning of the markings is important for the edge=20 > algorithm and that the two are difficult to separate. >=20 > But that wasn't my point. Without even going into the semantics of=20 > various markings, a number of issues have been brought up with regards > to _encoding_ this information using the ECN bits, DSCPs, IP options,=20 > etc. This should be worked out first, because the encoding choices may > limit what marking semantics can be defined later, which in turn=20 > affects what edge behaviors are possible. >=20 > > Another point is that if the first phase of the work does only the=20 > > marking behavior, and does not get re-chartered, than the product of > > the WG might not result in a standard that allows interoperability=20 > > (as different edge devices may do things incompatible with the=20 > > meaning of > > the marking and/or with each other). >=20 > If this first phase of work completes successfully, I fully expect a=20 > rechartering to occur, and the initial charter should probably contain > an explicit rechartering milestone together with a brief paragraph=20 > about what the goal of the rechartering should be. >=20 > If for some reason the WG runs aground in the first phase or decides=20 > not to recharter, yes, the set of RFCs it has produced won't be=20 > terribly useful. Frankly, that isn't the worst possible outcome in=20 > such a case. (But I don't think there is a real danger of this here.) >=20 > > So I would argue against taking the consideration of edge behaviors=20 > > out of the charter, even in the first phase. >=20 > Lars >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Dec 01 10:00:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq9s6-0004k6-G6; Fri, 01 Dec 2006 10:00:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq9s4-0004iy-SC for pcn@ietf.org; Fri, 01 Dec 2006 10:00:12 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq9ry-0007Iw-Bl for pcn@ietf.org; Fri, 01 Dec 2006 10:00:12 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8E3C51072; Fri, 1 Dec 2006 16:00:03 +0100 (CET) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 16:00:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN updated charter Date: Fri, 1 Dec 2006 16:00:02 +0100 Message-ID: <582B939025E978418C0B92DC134ADE9F1391BA@esealmw106.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN updated charter Thread-Index: AccT/4+UymL8PT7DTgq3/m9pfto2/AAY6jsQAA9YqQAAIQCNwAAMgZGgAAA8e9A= From: "Lars Westberg \(KI/EAB\)" To: "Anna Charny \(acharny\)" , , , , X-OriginalArrivalTime: 01 Dec 2006 15:00:02.0690 (UTC) FILETIME=[60FE4E20:01C71559] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org That's a very good proposal.=20 Protcol design should be a pretty easy task after the function is understood. In the work with RMD, we have seen a difficulties to specify requirement for congestion related to: -duration regulationtime for congestion.=20 How fast can a certain method=20 down-regulate the traffic in case on congestion.=20 -should the congestion function be used for single-fault or=20 double conditions ? If the utilization of non-best effort traffic is lower that 50% of all links, a simplified approach can be used because, congestion is very rare.=20 It would be nice to get the view from the working group. Regards Lasse=20 -----Original Message----- From: Anna Charny (acharny) [mailto:acharny@cisco.com]=20 Sent: den 1 december 2006 15:45 To: philip.eardley@bt.com; babiarz@nortel.com; lars.eggert@netlab.nec.de; pcn@ietf.org Subject: RE: [PCN] PCN updated charter Hi Phil, Yes, I agree. If we have to split the work on the encoding and the marking/edge mechanisms in two phases, I too would prefer to work on the mechanisms first, and the encoding second. =20 Anna =20 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Friday, December 01, 2006 5:00 AM To: babiarz@nortel.com; lars.eggert@netlab.nec.de; pcn@ietf.org Subject: RE: [PCN] PCN updated charter Hi, I agree with joe that there is some dependency between marking behaviour in routers, reaction by edge nodes and the encoding. To me this suggests it's appropriate to work on them at the same time. So I'd prefer it if the 'phase 1' of the charter could include work on all three. I also think the choice of encoding depends on the router & edge behaviours more strongly than the other way round (ie more strongly than the router & edge behaviours depend on the encoding). So an alternative way to segment the work could be to do the router & edge behaviours first & the encoding second? Best wishes, Phil > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com] > Sent: 30 November 2006 17:12 > To: Eardley,PL,Philip,CXR9 R; lars.eggert@netlab.nec.de; pcn@ietf.org > Subject: RE: [PCN] PCN updated charter >=20 > Lars wrote: > "But that wasn't my point. Without even going into the semantics of=20 > various markings, a number of issues have been brought up with regards > to _encoding_ this information using the ECN bits, DSCPs, IP options,=20 > etc. This should be worked out first, because the encoding choices may > limit what marking semantics can be defined later, which in turn affects > what edge behaviors are possible." > [Joe]I think that it would be appropriate for the WG to reach agreement > on what bits could be used for PCN before finalizing on the marking=20 > behavior in the routers or edge/host behavior. However, there are some > dependences between, marking behavior in routers, reaction by edge nodes > and the encoding. >=20 >=20 > Regards, Joe > QoS & Network Architecture > Telephone: 613-763-6098 (ESN 393-6098) > Email: babiarz@nortel.com >=20 > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: Thursday, November 30, 2006 4:47 AM > To: lars.eggert@netlab.nec.de; pcn@ietf.org > Subject: RE: [PCN] PCN updated charter >=20 > >>This [=3D the encoding choice] should be worked out first, because = the > encoding choices may limit what marking semantics can be defined later, > which in turn affects what edge behaviors are possible. > >> >=20 > I'm not sure the encoding choices do limit the marking semantics that=20 > much. I think the main impact of the encoding choice is on non-PCN=20 > things like compatibility with RFC3168 & DSCP usage. >=20 > phil >=20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@netlab.nec.de] > Sent: 29 November 2006 21:44 > To: pcn@ietf.org > Subject: Re: [PCN] PCN updated charter >=20 > On Nov 29, 2006, at 13:19, Anna Charny (acharny) wrote: > > Perhaps stressing in the charter that the WG will consider the=20 > > implications of the lower levels of ingress-egress aggregation on the > > marking mechanisms may address this issue? >=20 > Maybe. I think I need to digest this issue a bit more. >=20 > > With respect to your discussion with Ken on the problem statement=20 > > draft, I do not see any problem with combining it with the=20 > > architecture document. A large portion of the work has been already > > done in this in the various individual drafts, so this particular=20 > > deliverable does not > > appear to be terribly limiting to me either way. >=20 > Right. The existing documents may have much of the required material=20 > already. Whether there will be one vs. a number of documents that=20 > convey this content is mostly a matter of presentation. >=20 > > I interpret he above to mean that you propose to work on the encoding > > and the actual marking decisions at the internal PCN router (as well > > as one deployment model and prob statement), but that the edge=20 > > behavior should come later (after re-chartering). Is that a correct > > interpretation? >=20 > Right. >=20 > > I worry about taking the consideration of edge behaviors out of the=20 > > charter. > > The primary cause of this worry is that edge behaviors depend on the > > meaning of the marking. For example, if the marking is "red- like"=20 > > (e.g. > > virtual-queue based) its meaning is quite different than if the=20 > > marking is excess-rate based (e.g. token-bucket based", and the=20 > > appropriate edge behavior, to do "the right thing", needs to=20 > > reflect the meaning of the marking. I just cannot see how you can=20 > > completely divorce one from the other meaningfully. >=20 > I agree that the meaning of the markings is important for the edge=20 > algorithm and that the two are difficult to separate. >=20 > But that wasn't my point. Without even going into the semantics of=20 > various markings, a number of issues have been brought up with regards > to _encoding_ this information using the ECN bits, DSCPs, IP options,=20 > etc. This should be worked out first, because the encoding choices may > limit what marking semantics can be defined later, which in turn=20 > affects what edge behaviors are possible. >=20 > > Another point is that if the first phase of the work does only the=20 > > marking behavior, and does not get re-chartered, than the product of > > the WG might not result in a standard that allows interoperability=20 > > (as different edge devices may do things incompatible with the=20 > > meaning of > > the marking and/or with each other). >=20 > If this first phase of work completes successfully, I fully expect a=20 > rechartering to occur, and the initial charter should probably contain > an explicit rechartering milestone together with a brief paragraph=20 > about what the goal of the rechartering should be. >=20 > If for some reason the WG runs aground in the first phase or decides=20 > not to recharter, yes, the set of RFCs it has produced won't be=20 > terribly useful. Frankly, that isn't the worst possible outcome in=20 > such a case. (But I don't think there is a real danger of this here.) >=20 > > So I would argue against taking the consideration of edge behaviors=20 > > out of the charter, even in the first phase. >=20 > Lars >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Dec 01 15:31:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqF2D-0000gH-8s; Fri, 01 Dec 2006 15:31:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqF2B-0000fx-KS for pcn@ietf.org; Fri, 01 Dec 2006 15:30:59 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqF2A-0005yn-5t for pcn@ietf.org; Fri, 01 Dec 2006 15:30:59 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kB1KNku11104; Fri, 1 Dec 2006 15:23:46 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN updated charter Date: Fri, 1 Dec 2006 15:30:52 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650D7C190F@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN updated charter Thread-Index: AccT/4+UymL8PT7DTgq3/m9pfto2/AAY6jsQAA9YqQAAIQCNwAAMgZGgAAtp6GA= From: "Jozef Babiarz" To: "Anna Charny \(acharny\)" , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Anna, Phil, If we split the work between router marking behavior/edge mechanisms and encoding, do we not need to validate that the agreed router marking behavior can be performed with the available encoding method(s) and bits? My view is that there are lot of restrictions (i.e., RFC3168 and draft-ietf-tsvwg-ecn-alternates-00) on what bits in the IP header can be used and how they should be used. These dependencies need to be factored in when the group selects the router marking behavior.=20 Joe. -----Original Message----- From: Anna Charny (acharny) [mailto:acharny@cisco.com]=20 Sent: Friday, December 01, 2006 9:45 AM To: philip.eardley@bt.com; Babiarz, Jozef (CAR:0S03); lars.eggert@netlab.nec.de; pcn@ietf.org Subject: RE: [PCN] PCN updated charter Hi Phil, Yes, I agree. If we have to split the work on the encoding and the marking/edge mechanisms in two phases, I too would prefer to work on the mechanisms first, and the encoding second. =20 Anna =20 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Friday, December 01, 2006 5:00 AM To: babiarz@nortel.com; lars.eggert@netlab.nec.de; pcn@ietf.org Subject: RE: [PCN] PCN updated charter Hi, I agree with joe that there is some dependency between marking behaviour in routers, reaction by edge nodes and the encoding. To me this suggests it's appropriate to work on them at the same time. So I'd prefer it if the 'phase 1' of the charter could include work on all three. I also think the choice of encoding depends on the router & edge behaviours more strongly than the other way round (ie more strongly than the router & edge behaviours depend on the encoding). So an alternative way to segment the work could be to do the router & edge behaviours first & the encoding second? Best wishes, Phil > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com] > Sent: 30 November 2006 17:12 > To: Eardley,PL,Philip,CXR9 R; lars.eggert@netlab.nec.de; pcn@ietf.org > Subject: RE: [PCN] PCN updated charter >=20 > Lars wrote: > "But that wasn't my point. Without even going into the semantics of=20 > various markings, a number of issues have been brought up with regards > to _encoding_ this information using the ECN bits, DSCPs, IP options,=20 > etc. This should be worked out first, because the encoding choices may > limit what marking semantics can be defined later, which in turn affects > what edge behaviors are possible." > [Joe]I think that it would be appropriate for the WG to reach agreement > on what bits could be used for PCN before finalizing on the marking=20 > behavior in the routers or edge/host behavior. However, there are some > dependences between, marking behavior in routers, reaction by edge nodes > and the encoding. >=20 >=20 > Regards, Joe > QoS & Network Architecture > Telephone: 613-763-6098 (ESN 393-6098) > Email: babiarz@nortel.com >=20 > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: Thursday, November 30, 2006 4:47 AM > To: lars.eggert@netlab.nec.de; pcn@ietf.org > Subject: RE: [PCN] PCN updated charter >=20 > >>This [=3D the encoding choice] should be worked out first, because = the > encoding choices may limit what marking semantics can be defined later, > which in turn affects what edge behaviors are possible. > >> >=20 > I'm not sure the encoding choices do limit the marking semantics that=20 > much. I think the main impact of the encoding choice is on non-PCN=20 > things like compatibility with RFC3168 & DSCP usage. >=20 > phil >=20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@netlab.nec.de] > Sent: 29 November 2006 21:44 > To: pcn@ietf.org > Subject: Re: [PCN] PCN updated charter >=20 > On Nov 29, 2006, at 13:19, Anna Charny (acharny) wrote: > > Perhaps stressing in the charter that the WG will consider the=20 > > implications of the lower levels of ingress-egress aggregation on the > > marking mechanisms may address this issue? >=20 > Maybe. I think I need to digest this issue a bit more. >=20 > > With respect to your discussion with Ken on the problem statement=20 > > draft, I do not see any problem with combining it with the=20 > > architecture document. A large portion of the work has been already > > done in this in the various individual drafts, so this particular=20 > > deliverable does not > > appear to be terribly limiting to me either way. >=20 > Right. The existing documents may have much of the required material=20 > already. Whether there will be one vs. a number of documents that=20 > convey this content is mostly a matter of presentation. >=20 > > I interpret he above to mean that you propose to work on the encoding > > and the actual marking decisions at the internal PCN router (as well > > as one deployment model and prob statement), but that the edge=20 > > behavior should come later (after re-chartering). Is that a correct > > interpretation? >=20 > Right. >=20 > > I worry about taking the consideration of edge behaviors out of the=20 > > charter. > > The primary cause of this worry is that edge behaviors depend on the > > meaning of the marking. For example, if the marking is "red- like"=20 > > (e.g. > > virtual-queue based) its meaning is quite different than if the=20 > > marking is excess-rate based (e.g. token-bucket based", and the=20 > > appropriate edge behavior, to do "the right thing", needs to=20 > > reflect the meaning of the marking. I just cannot see how you can=20 > > completely divorce one from the other meaningfully. >=20 > I agree that the meaning of the markings is important for the edge=20 > algorithm and that the two are difficult to separate. >=20 > But that wasn't my point. Without even going into the semantics of=20 > various markings, a number of issues have been brought up with regards > to _encoding_ this information using the ECN bits, DSCPs, IP options,=20 > etc. This should be worked out first, because the encoding choices may > limit what marking semantics can be defined later, which in turn=20 > affects what edge behaviors are possible. >=20 > > Another point is that if the first phase of the work does only the=20 > > marking behavior, and does not get re-chartered, than the product of > > the WG might not result in a standard that allows interoperability=20 > > (as different edge devices may do things incompatible with the=20 > > meaning of > > the marking and/or with each other). >=20 > If this first phase of work completes successfully, I fully expect a=20 > rechartering to occur, and the initial charter should probably contain > an explicit rechartering milestone together with a brief paragraph=20 > about what the goal of the rechartering should be. >=20 > If for some reason the WG runs aground in the first phase or decides=20 > not to recharter, yes, the set of RFCs it has produced won't be=20 > terribly useful. Frankly, that isn't the worst possible outcome in=20 > such a case. (But I don't think there is a real danger of this here.) >=20 > > So I would argue against taking the consideration of edge behaviors=20 > > out of the charter, even in the first phase. >=20 > Lars >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Dec 01 15:36:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqF7l-0002HZ-7P; Fri, 01 Dec 2006 15:36:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqF7k-0002HT-2t for pcn@ietf.org; Fri, 01 Dec 2006 15:36:44 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqF7i-0000I4-Bw for pcn@ietf.org; Fri, 01 Dec 2006 15:36:44 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-1.cisco.com with ESMTP; 01 Dec 2006 12:36:41 -0800 X-IronPort-AV: i="4.09,486,1157353200"; d="scan'208"; a="755771669:sNHT102303108" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB1KaeHj025855; Fri, 1 Dec 2006 15:36:40 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB1KaXYN026400; Fri, 1 Dec 2006 15:36:40 -0500 (EST) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 15:36:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN updated charter Date: Fri, 1 Dec 2006 15:36:36 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN updated charter Thread-Index: AccT/4+UymL8PT7DTgq3/m9pfto2/AAY6jsQAA9YqQAAIQCNwAAMgZGgAAtp6GAAAOKkUA== From: "Anna Charny \(acharny\)" To: "Jozef Babiarz" , , , X-OriginalArrivalTime: 01 Dec 2006 20:36:37.0195 (UTC) FILETIME=[65DB39B0:01C71588] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8269; t=1165005400; x=1165869400; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20\(acharny\)=22=20 |Subject:=20RE=3A=20[PCN]=20PCN=20=20updated=20charter |Sender:=20 |To:=20=22Jozef=20Babiarz=22=20, =20, =0A=20=20=20=20=20=20=20=20, =20; bh=P5yDmKLs3f933S3aN1fXFfpPOlyzq+KSWeKCrKxv28w=; b=iP+iTpFII+AsGaKiz5Pk4LOR2HhAgQ8IGcUAXsSN0HJRBmWsoC/CZVK7cdTPVDjnsjm/K99p RiXJm1pFHL3V77fMkE92fcjaK0azQF4IvNCZgMiAc8Y5otXajNnlDGSD; Authentication-Results: rtp-dkim-1; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Joe, My view on this is that as long as there are enough states, we do not need to agree on the exact encoding for these states immediately. It seems to me that there are several possibilities identified in existing drafts already discussed in tsvwg that do provide enough states. I think choosing between those does not have to be done immediately? Anna=20 -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: Friday, December 01, 2006 3:31 PM To: Anna Charny (acharny); philip.eardley@bt.com; lars.eggert@netlab.nec.de; pcn@ietf.org Subject: RE: [PCN] PCN updated charter Hi Anna, Phil, If we split the work between router marking behavior/edge mechanisms and encoding, do we not need to validate that the agreed router marking behavior can be performed with the available encoding method(s) and bits? My view is that there are lot of restrictions (i.e., RFC3168 and draft-ietf-tsvwg-ecn-alternates-00) on what bits in the IP header can be used and how they should be used. These dependencies need to be factored in when the group selects the router marking behavior.=20 Joe. -----Original Message----- From: Anna Charny (acharny) [mailto:acharny@cisco.com] Sent: Friday, December 01, 2006 9:45 AM To: philip.eardley@bt.com; Babiarz, Jozef (CAR:0S03); lars.eggert@netlab.nec.de; pcn@ietf.org Subject: RE: [PCN] PCN updated charter Hi Phil, Yes, I agree. If we have to split the work on the encoding and the marking/edge mechanisms in two phases, I too would prefer to work on the mechanisms first, and the encoding second. =20 Anna =20 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Friday, December 01, 2006 5:00 AM To: babiarz@nortel.com; lars.eggert@netlab.nec.de; pcn@ietf.org Subject: RE: [PCN] PCN updated charter Hi, I agree with joe that there is some dependency between marking behaviour in routers, reaction by edge nodes and the encoding. To me this suggests it's appropriate to work on them at the same time. So I'd prefer it if the 'phase 1' of the charter could include work on all three. I also think the choice of encoding depends on the router & edge behaviours more strongly than the other way round (ie more strongly than the router & edge behaviours depend on the encoding). So an alternative way to segment the work could be to do the router & edge behaviours first & the encoding second? Best wishes, Phil > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com] > Sent: 30 November 2006 17:12 > To: Eardley,PL,Philip,CXR9 R; lars.eggert@netlab.nec.de; pcn@ietf.org > Subject: RE: [PCN] PCN updated charter >=20 > Lars wrote: > "But that wasn't my point. Without even going into the semantics of=20 > various markings, a number of issues have been brought up with regards > to _encoding_ this information using the ECN bits, DSCPs, IP options,=20 > etc. This should be worked out first, because the encoding choices may > limit what marking semantics can be defined later, which in turn affects > what edge behaviors are possible." > [Joe]I think that it would be appropriate for the WG to reach agreement > on what bits could be used for PCN before finalizing on the marking=20 > behavior in the routers or edge/host behavior. However, there are some > dependences between, marking behavior in routers, reaction by edge nodes > and the encoding. >=20 >=20 > Regards, Joe > QoS & Network Architecture > Telephone: 613-763-6098 (ESN 393-6098) > Email: babiarz@nortel.com >=20 > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: Thursday, November 30, 2006 4:47 AM > To: lars.eggert@netlab.nec.de; pcn@ietf.org > Subject: RE: [PCN] PCN updated charter >=20 > >>This [=3D the encoding choice] should be worked out first, because = the > encoding choices may limit what marking semantics can be defined later, > which in turn affects what edge behaviors are possible. > >> >=20 > I'm not sure the encoding choices do limit the marking semantics that=20 > much. I think the main impact of the encoding choice is on non-PCN=20 > things like compatibility with RFC3168 & DSCP usage. >=20 > phil >=20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@netlab.nec.de] > Sent: 29 November 2006 21:44 > To: pcn@ietf.org > Subject: Re: [PCN] PCN updated charter >=20 > On Nov 29, 2006, at 13:19, Anna Charny (acharny) wrote: > > Perhaps stressing in the charter that the WG will consider the=20 > > implications of the lower levels of ingress-egress aggregation on the > > marking mechanisms may address this issue? >=20 > Maybe. I think I need to digest this issue a bit more. >=20 > > With respect to your discussion with Ken on the problem statement=20 > > draft, I do not see any problem with combining it with the=20 > > architecture document. A large portion of the work has been already > > done in this in the various individual drafts, so this particular=20 > > deliverable does not > > appear to be terribly limiting to me either way. >=20 > Right. The existing documents may have much of the required material=20 > already. Whether there will be one vs. a number of documents that=20 > convey this content is mostly a matter of presentation. >=20 > > I interpret he above to mean that you propose to work on the encoding > > and the actual marking decisions at the internal PCN router (as well > > as one deployment model and prob statement), but that the edge=20 > > behavior should come later (after re-chartering). Is that a correct > > interpretation? >=20 > Right. >=20 > > I worry about taking the consideration of edge behaviors out of the=20 > > charter. > > The primary cause of this worry is that edge behaviors depend on the > > meaning of the marking. For example, if the marking is "red- like"=20 > > (e.g. > > virtual-queue based) its meaning is quite different than if the=20 > > marking is excess-rate based (e.g. token-bucket based", and the=20 > > appropriate edge behavior, to do "the right thing", needs to=20 > > reflect the meaning of the marking. I just cannot see how you can=20 > > completely divorce one from the other meaningfully. >=20 > I agree that the meaning of the markings is important for the edge=20 > algorithm and that the two are difficult to separate. >=20 > But that wasn't my point. Without even going into the semantics of=20 > various markings, a number of issues have been brought up with regards > to _encoding_ this information using the ECN bits, DSCPs, IP options,=20 > etc. This should be worked out first, because the encoding choices may > limit what marking semantics can be defined later, which in turn=20 > affects what edge behaviors are possible. >=20 > > Another point is that if the first phase of the work does only the=20 > > marking behavior, and does not get re-chartered, than the product of > > the WG might not result in a standard that allows interoperability=20 > > (as different edge devices may do things incompatible with the=20 > > meaning of > > the marking and/or with each other). >=20 > If this first phase of work completes successfully, I fully expect a=20 > rechartering to occur, and the initial charter should probably contain > an explicit rechartering milestone together with a brief paragraph=20 > about what the goal of the rechartering should be. >=20 > If for some reason the WG runs aground in the first phase or decides=20 > not to recharter, yes, the set of RFCs it has produced won't be=20 > terribly useful. Frankly, that isn't the worst possible outcome in=20 > such a case. (But I don't think there is a real danger of this here.) >=20 > > So I would argue against taking the consideration of edge behaviors=20 > > out of the charter, even in the first phase. >=20 > Lars >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Dec 01 15:49:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqFJx-0004om-4W; Fri, 01 Dec 2006 15:49:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqFJw-0004iI-9K for pcn@ietf.org; Fri, 01 Dec 2006 15:49:20 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqFJv-000526-QN for pcn@ietf.org; Fri, 01 Dec 2006 15:49:20 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kB1Kg8u12595; Fri, 1 Dec 2006 15:42:08 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN updated charter Date: Fri, 1 Dec 2006 15:49:14 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650D7C196F@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN updated charter Thread-Index: AccT/4+UymL8PT7DTgq3/m9pfto2/AAY6jsQAA9YqQAAIQCNwAAMgZGgAAtp6GAAAOKkUAAASC+Q From: "Jozef Babiarz" To: "Anna Charny \(acharny\)" , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Anna,=20 Agree. However we may need to study carefully "draft-ietf-tsvwg-ecn-alternates-00" now RFC 4774 as well RFC 3168 when defining router marking behavior.=20 Joe. -----Original Message----- From: Anna Charny (acharny) [mailto:acharny@cisco.com]=20 Sent: Friday, December 01, 2006 3:37 PM To: Babiarz, Jozef (CAR:0S03); philip.eardley@bt.com; lars.eggert@netlab.nec.de; pcn@ietf.org Subject: RE: [PCN] PCN updated charter Hi Joe, My view on this is that as long as there are enough states, we do not need to agree on the exact encoding for these states immediately. It seems to me that there are several possibilities identified in existing drafts already discussed in tsvwg that do provide enough states. I think choosing between those does not have to be done immediately? Anna=20 -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: Friday, December 01, 2006 3:31 PM To: Anna Charny (acharny); philip.eardley@bt.com; lars.eggert@netlab.nec.de; pcn@ietf.org Subject: RE: [PCN] PCN updated charter Hi Anna, Phil, If we split the work between router marking behavior/edge mechanisms and encoding, do we not need to validate that the agreed router marking behavior can be performed with the available encoding method(s) and bits? My view is that there are lot of restrictions (i.e., RFC3168 and draft-ietf-tsvwg-ecn-alternates-00) on what bits in the IP header can be used and how they should be used. These dependencies need to be factored in when the group selects the router marking behavior.=20 Joe. -----Original Message----- From: Anna Charny (acharny) [mailto:acharny@cisco.com] Sent: Friday, December 01, 2006 9:45 AM To: philip.eardley@bt.com; Babiarz, Jozef (CAR:0S03); lars.eggert@netlab.nec.de; pcn@ietf.org Subject: RE: [PCN] PCN updated charter Hi Phil, Yes, I agree. If we have to split the work on the encoding and the marking/edge mechanisms in two phases, I too would prefer to work on the mechanisms first, and the encoding second. =20 Anna =20 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Friday, December 01, 2006 5:00 AM To: babiarz@nortel.com; lars.eggert@netlab.nec.de; pcn@ietf.org Subject: RE: [PCN] PCN updated charter Hi, I agree with joe that there is some dependency between marking behaviour in routers, reaction by edge nodes and the encoding. To me this suggests it's appropriate to work on them at the same time. So I'd prefer it if the 'phase 1' of the charter could include work on all three. I also think the choice of encoding depends on the router & edge behaviours more strongly than the other way round (ie more strongly than the router & edge behaviours depend on the encoding). So an alternative way to segment the work could be to do the router & edge behaviours first & the encoding second? Best wishes, Phil > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com] > Sent: 30 November 2006 17:12 > To: Eardley,PL,Philip,CXR9 R; lars.eggert@netlab.nec.de; pcn@ietf.org > Subject: RE: [PCN] PCN updated charter >=20 > Lars wrote: > "But that wasn't my point. Without even going into the semantics of=20 > various markings, a number of issues have been brought up with regards > to _encoding_ this information using the ECN bits, DSCPs, IP options,=20 > etc. This should be worked out first, because the encoding choices may > limit what marking semantics can be defined later, which in turn affects > what edge behaviors are possible." > [Joe]I think that it would be appropriate for the WG to reach agreement > on what bits could be used for PCN before finalizing on the marking=20 > behavior in the routers or edge/host behavior. However, there are some > dependences between, marking behavior in routers, reaction by edge nodes > and the encoding. >=20 >=20 > Regards, Joe > QoS & Network Architecture > Telephone: 613-763-6098 (ESN 393-6098) > Email: babiarz@nortel.com >=20 > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: Thursday, November 30, 2006 4:47 AM > To: lars.eggert@netlab.nec.de; pcn@ietf.org > Subject: RE: [PCN] PCN updated charter >=20 > >>This [=3D the encoding choice] should be worked out first, because = the > encoding choices may limit what marking semantics can be defined later, > which in turn affects what edge behaviors are possible. > >> >=20 > I'm not sure the encoding choices do limit the marking semantics that=20 > much. I think the main impact of the encoding choice is on non-PCN=20 > things like compatibility with RFC3168 & DSCP usage. >=20 > phil >=20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@netlab.nec.de] > Sent: 29 November 2006 21:44 > To: pcn@ietf.org > Subject: Re: [PCN] PCN updated charter >=20 > On Nov 29, 2006, at 13:19, Anna Charny (acharny) wrote: > > Perhaps stressing in the charter that the WG will consider the=20 > > implications of the lower levels of ingress-egress aggregation on the > > marking mechanisms may address this issue? >=20 > Maybe. I think I need to digest this issue a bit more. >=20 > > With respect to your discussion with Ken on the problem statement=20 > > draft, I do not see any problem with combining it with the=20 > > architecture document. A large portion of the work has been already > > done in this in the various individual drafts, so this particular=20 > > deliverable does not > > appear to be terribly limiting to me either way. >=20 > Right. The existing documents may have much of the required material=20 > already. Whether there will be one vs. a number of documents that=20 > convey this content is mostly a matter of presentation. >=20 > > I interpret he above to mean that you propose to work on the encoding > > and the actual marking decisions at the internal PCN router (as well > > as one deployment model and prob statement), but that the edge=20 > > behavior should come later (after re-chartering). Is that a correct > > interpretation? >=20 > Right. >=20 > > I worry about taking the consideration of edge behaviors out of the=20 > > charter. > > The primary cause of this worry is that edge behaviors depend on the > > meaning of the marking. For example, if the marking is "red- like"=20 > > (e.g. > > virtual-queue based) its meaning is quite different than if the=20 > > marking is excess-rate based (e.g. token-bucket based", and the=20 > > appropriate edge behavior, to do "the right thing", needs to=20 > > reflect the meaning of the marking. I just cannot see how you can=20 > > completely divorce one from the other meaningfully. >=20 > I agree that the meaning of the markings is important for the edge=20 > algorithm and that the two are difficult to separate. >=20 > But that wasn't my point. Without even going into the semantics of=20 > various markings, a number of issues have been brought up with regards > to _encoding_ this information using the ECN bits, DSCPs, IP options,=20 > etc. This should be worked out first, because the encoding choices may > limit what marking semantics can be defined later, which in turn=20 > affects what edge behaviors are possible. >=20 > > Another point is that if the first phase of the work does only the=20 > > marking behavior, and does not get re-chartered, than the product of > > the WG might not result in a standard that allows interoperability=20 > > (as different edge devices may do things incompatible with the=20 > > meaning of > > the marking and/or with each other). >=20 > If this first phase of work completes successfully, I fully expect a=20 > rechartering to occur, and the initial charter should probably contain > an explicit rechartering milestone together with a brief paragraph=20 > about what the goal of the rechartering should be. >=20 > If for some reason the WG runs aground in the first phase or decides=20 > not to recharter, yes, the set of RFCs it has produced won't be=20 > terribly useful. Frankly, that isn't the worst possible outcome in=20 > such a case. (But I don't think there is a real danger of this here.) >=20 > > So I would argue against taking the consideration of edge behaviors=20 > > out of the charter, even in the first phase. >=20 > Lars >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Dec 01 15:59:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqFTm-0001wW-Jc; Fri, 01 Dec 2006 15:59:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqFTl-0001wQ-1a for pcn@ietf.org; Fri, 01 Dec 2006 15:59:29 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqFTi-0007Or-Bf for pcn@ietf.org; Fri, 01 Dec 2006 15:59:29 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 01 Dec 2006 12:59:24 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB1KxONY006153; Fri, 1 Dec 2006 15:59:24 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kB1KxNDM000451; Fri, 1 Dec 2006 15:59:23 -0500 (EST) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 15:59:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN updated charter Date: Fri, 1 Dec 2006 15:59:22 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN updated charter Thread-Index: AccT/4+UymL8PT7DTgq3/m9pfto2/AAY6jsQAA9YqQAAIQCNwAAMgZGgAAtp6GAAAOKkUAAASC+QAACmQiA= From: "Anna Charny \(acharny\)" To: "Jozef Babiarz" , , , X-OriginalArrivalTime: 01 Dec 2006 20:59:23.0842 (UTC) FILETIME=[94710220:01C7158B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8980; t=1165006764; x=1165870764; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20\(acharny\)=22=20 |Subject:=20RE=3A=20[PCN]=20PCN=20=20updated=20charter |Sender:=20 |To:=20=22Jozef=20Babiarz=22=20, =20, =0A=20=20=20=20=20=20=20=20, =20; bh=dBH6oFv1U9ohT0JCB/dCqDMPXiPFhR3k1ZCjAXIk3lg=; b=qOXYi+POa46pI1xaOPnxae7QQI6fsDSQxkG0sdObasssZY8lgmQoVstex2oEe+wAgYSVfSmo 5mXQ/LHkG8BBLCWyxb+/Q+09SSXfwnmwJv0ZhMy8dbaQnf+IOIk4FGP8; Authentication-Results: rtp-dkim-2; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Agreed=20 -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: Friday, December 01, 2006 3:49 PM To: Anna Charny (acharny); philip.eardley@bt.com; lars.eggert@netlab.nec.de; pcn@ietf.org Subject: RE: [PCN] PCN updated charter Hi Anna,=20 Agree. However we may need to study carefully "draft-ietf-tsvwg-ecn-alternates-00" now RFC 4774 as well RFC 3168 when defining router marking behavior.=20 Joe. -----Original Message----- From: Anna Charny (acharny) [mailto:acharny@cisco.com] Sent: Friday, December 01, 2006 3:37 PM To: Babiarz, Jozef (CAR:0S03); philip.eardley@bt.com; lars.eggert@netlab.nec.de; pcn@ietf.org Subject: RE: [PCN] PCN updated charter Hi Joe, My view on this is that as long as there are enough states, we do not need to agree on the exact encoding for these states immediately. It seems to me that there are several possibilities identified in existing drafts already discussed in tsvwg that do provide enough states. I think choosing between those does not have to be done immediately? Anna=20 -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com] Sent: Friday, December 01, 2006 3:31 PM To: Anna Charny (acharny); philip.eardley@bt.com; lars.eggert@netlab.nec.de; pcn@ietf.org Subject: RE: [PCN] PCN updated charter Hi Anna, Phil, If we split the work between router marking behavior/edge mechanisms and encoding, do we not need to validate that the agreed router marking behavior can be performed with the available encoding method(s) and bits? My view is that there are lot of restrictions (i.e., RFC3168 and draft-ietf-tsvwg-ecn-alternates-00) on what bits in the IP header can be used and how they should be used. These dependencies need to be factored in when the group selects the router marking behavior.=20 Joe. -----Original Message----- From: Anna Charny (acharny) [mailto:acharny@cisco.com] Sent: Friday, December 01, 2006 9:45 AM To: philip.eardley@bt.com; Babiarz, Jozef (CAR:0S03); lars.eggert@netlab.nec.de; pcn@ietf.org Subject: RE: [PCN] PCN updated charter Hi Phil, Yes, I agree. If we have to split the work on the encoding and the marking/edge mechanisms in two phases, I too would prefer to work on the mechanisms first, and the encoding second. =20 Anna =20 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Friday, December 01, 2006 5:00 AM To: babiarz@nortel.com; lars.eggert@netlab.nec.de; pcn@ietf.org Subject: RE: [PCN] PCN updated charter Hi, I agree with joe that there is some dependency between marking behaviour in routers, reaction by edge nodes and the encoding. To me this suggests it's appropriate to work on them at the same time. So I'd prefer it if the 'phase 1' of the charter could include work on all three. I also think the choice of encoding depends on the router & edge behaviours more strongly than the other way round (ie more strongly than the router & edge behaviours depend on the encoding). So an alternative way to segment the work could be to do the router & edge behaviours first & the encoding second? Best wishes, Phil > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com] > Sent: 30 November 2006 17:12 > To: Eardley,PL,Philip,CXR9 R; lars.eggert@netlab.nec.de; pcn@ietf.org > Subject: RE: [PCN] PCN updated charter >=20 > Lars wrote: > "But that wasn't my point. Without even going into the semantics of=20 > various markings, a number of issues have been brought up with regards > to _encoding_ this information using the ECN bits, DSCPs, IP options,=20 > etc. This should be worked out first, because the encoding choices may > limit what marking semantics can be defined later, which in turn affects > what edge behaviors are possible." > [Joe]I think that it would be appropriate for the WG to reach agreement > on what bits could be used for PCN before finalizing on the marking=20 > behavior in the routers or edge/host behavior. However, there are some > dependences between, marking behavior in routers, reaction by edge nodes > and the encoding. >=20 >=20 > Regards, Joe > QoS & Network Architecture > Telephone: 613-763-6098 (ESN 393-6098) > Email: babiarz@nortel.com >=20 > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: Thursday, November 30, 2006 4:47 AM > To: lars.eggert@netlab.nec.de; pcn@ietf.org > Subject: RE: [PCN] PCN updated charter >=20 > >>This [=3D the encoding choice] should be worked out first, because = the > encoding choices may limit what marking semantics can be defined later, > which in turn affects what edge behaviors are possible. > >> >=20 > I'm not sure the encoding choices do limit the marking semantics that=20 > much. I think the main impact of the encoding choice is on non-PCN=20 > things like compatibility with RFC3168 & DSCP usage. >=20 > phil >=20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@netlab.nec.de] > Sent: 29 November 2006 21:44 > To: pcn@ietf.org > Subject: Re: [PCN] PCN updated charter >=20 > On Nov 29, 2006, at 13:19, Anna Charny (acharny) wrote: > > Perhaps stressing in the charter that the WG will consider the=20 > > implications of the lower levels of ingress-egress aggregation on the > > marking mechanisms may address this issue? >=20 > Maybe. I think I need to digest this issue a bit more. >=20 > > With respect to your discussion with Ken on the problem statement=20 > > draft, I do not see any problem with combining it with the=20 > > architecture document. A large portion of the work has been already > > done in this in the various individual drafts, so this particular=20 > > deliverable does not > > appear to be terribly limiting to me either way. >=20 > Right. The existing documents may have much of the required material=20 > already. Whether there will be one vs. a number of documents that=20 > convey this content is mostly a matter of presentation. >=20 > > I interpret he above to mean that you propose to work on the encoding > > and the actual marking decisions at the internal PCN router (as well > > as one deployment model and prob statement), but that the edge=20 > > behavior should come later (after re-chartering). Is that a correct > > interpretation? >=20 > Right. >=20 > > I worry about taking the consideration of edge behaviors out of the=20 > > charter. > > The primary cause of this worry is that edge behaviors depend on the > > meaning of the marking. For example, if the marking is "red- like"=20 > > (e.g. > > virtual-queue based) its meaning is quite different than if the=20 > > marking is excess-rate based (e.g. token-bucket based", and the=20 > > appropriate edge behavior, to do "the right thing", needs to=20 > > reflect the meaning of the marking. I just cannot see how you can=20 > > completely divorce one from the other meaningfully. >=20 > I agree that the meaning of the markings is important for the edge=20 > algorithm and that the two are difficult to separate. >=20 > But that wasn't my point. Without even going into the semantics of=20 > various markings, a number of issues have been brought up with regards > to _encoding_ this information using the ECN bits, DSCPs, IP options,=20 > etc. This should be worked out first, because the encoding choices may > limit what marking semantics can be defined later, which in turn=20 > affects what edge behaviors are possible. >=20 > > Another point is that if the first phase of the work does only the=20 > > marking behavior, and does not get re-chartered, than the product of > > the WG might not result in a standard that allows interoperability=20 > > (as different edge devices may do things incompatible with the=20 > > meaning of > > the marking and/or with each other). >=20 > If this first phase of work completes successfully, I fully expect a=20 > rechartering to occur, and the initial charter should probably contain > an explicit rechartering milestone together with a brief paragraph=20 > about what the goal of the rechartering should be. >=20 > If for some reason the WG runs aground in the first phase or decides=20 > not to recharter, yes, the set of RFCs it has produced won't be=20 > terribly useful. Frankly, that isn't the worst possible outcome in=20 > such a case. (But I don't think there is a real danger of this here.) >=20 > > So I would argue against taking the consideration of edge behaviors=20 > > out of the charter, even in the first phase. >=20 > Lars >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Dec 01 20:21:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqJZ7-0002YE-EA; Fri, 01 Dec 2006 20:21:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqJZ6-0002Xu-GJ for pcn@ietf.org; Fri, 01 Dec 2006 20:21:16 -0500 Received: from smtp.hsia.fairmont.com ([142.131.15.59] helo=torntsims03.hsia.fairmont.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqJZ5-0007no-8g for pcn@ietf.org; Fri, 01 Dec 2006 20:21:16 -0500 Received: from [64.169.29.211] (unverified [64.169.29.211]) by torntsims03.hsia.fairmont.com (Vircom SMTPRS 4.2.425.4) with ESMTP id for ; Fri, 1 Dec 2006 19:57:43 -0500 X-Modus-BlackList: 64.169.29.211=OK;lars.eggert@netlab.nec.de=OK X-Modus-Trusted: 64.169.29.211=NO Received: from lars.local ([142.131.243.207]) by [64.169.29.211] (8.13.6/8.13.6) with ESMTP id kB21KrrU003062 for ; Fri, 1 Dec 2006 17:20:53 -0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id B8A7529C38F for ; Fri, 1 Dec 2006 15:36:54 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) To: pcn@ietf.org Message-Id: <145E8647-883E-4F90-9C07-2A1C059538CE@netlab.nec.de> From: Lars Eggert Date: Fri, 1 Dec 2006 15:36:52 -0800 X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on localhost X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on sc1000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Subject: [PCN] gauging interest in PCN X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1795528734==" Errors-To: pcn-bounces@ietf.org --===============1795528734== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-67--122063867; protocol="application/pkcs7-signature" --Apple-Mail-67--122063867 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, independent of the exact initial technical scope, I'm trying to get a feel for the energy of the broader community in the PCN space. There have been a handful of vocal proponents on the list and at the meeting, but I haven't heard from many people not already involved with authoring the set of related drafts. If you're willing to actively participate in a PCN WG (read and review drafts, etc.), please speak up. Lars --Apple-Mail-67--122063867 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMjAx MjMzNjUzWjAjBgkqhkiG9w0BCQQxFgQU7Wg4qJ4WaCtcheYt1SjRlRC21CQwgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBAESU4eSOUsIftb7TGL2H 6U0cOclff0MnBoohx86+VWBAz3a5kPoDbnSuECQRRvKPeUP9CfUXZbHmvwM79uu95OTaAqXRZA2X h7CJ9xH0avKsLkLYy5qBHEw1wqY7kFR7JDJu6kALAmhvXvQNZsg0bLwnJgkWagoqsko7+nuDWIbE waCUqt4qg7Y47tjdFAoNlm8AHW7qjowAWPspG4ntfpXF3rcTPDzbfb/31Tn7utTssXlXoly2QZ0s k+yCq6ymDiGXJx5EWSxtFRXU98Za8bvO/z4fSEYB3GtZuU49ViNGj42bGN15BwRTQO+sgOcDwnKK 9cgkosDQDUMMjQ4kM5IAAAAAAAA= --Apple-Mail-67--122063867-- --===============1795528734== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============1795528734==-- From pcn-bounces@ietf.org Fri Dec 01 20:21:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqJZ3-0002UC-Pq; Fri, 01 Dec 2006 20:21:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqJZ2-0002Tx-E7 for pcn@ietf.org; Fri, 01 Dec 2006 20:21:12 -0500 Received: from smtp.hsia.fairmont.com ([142.131.15.59] helo=torntsims03.hsia.fairmont.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqJZ1-0007m5-58 for pcn@ietf.org; Fri, 01 Dec 2006 20:21:12 -0500 Received: from [64.169.29.211] (unverified [64.169.29.211]) by torntsims03.hsia.fairmont.com (Vircom SMTPRS 4.2.425.4) with ESMTP id for ; Fri, 1 Dec 2006 19:57:39 -0500 X-Modus-BlackList: 64.169.29.211=OK;lars.eggert@netlab.nec.de=OK X-Modus-Trusted: 64.169.29.211=NO Received: from lars.local ([142.131.243.207]) by [64.169.29.211] (8.13.6/8.13.6) with ESMTP id kB21KnZm002987 for ; Fri, 1 Dec 2006 17:20:50 -0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id 68DBF29C373 for ; Fri, 1 Dec 2006 15:24:48 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CEC9@E03MVZ1-UKDY.domain1.systemhost.net> References: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CEC9@E03MVZ1-UKDY.domain1.systemhost.net> Message-Id: <1733DAE6-2468-4DAB-B434-893CB42B0FD4@netlab.nec.de> From: Lars Eggert Subject: Re: [PCN] PCN updated charter Date: Fri, 1 Dec 2006 15:24:46 -0800 To: pcn@ietf.org X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on localhost X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on sc1000 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0990553307==" Errors-To: pcn-bounces@ietf.org --===============0990553307== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-64--122790177; protocol="application/pkcs7-signature" --Apple-Mail-64--122790177 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Nov 30, 2006, at 1:34, wrote: > Perhaps stressing in the charter that the WG will consider the > implications of the lower levels of ingress-egress aggregation on the > marking mechanisms may address this issue? > > > > [phil start] > either like this or as a separate deployment model would work for > me. I > think the most important thing is the impact on the aggregation > assumption, as anna mentions > [phil end] Could you provide a paragraph to add to the charter that would outline this a bit? Lars --Apple-Mail-64--122790177 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMjAx MjMyNDQ3WjAjBgkqhkiG9w0BCQQxFgQUJJO2y2z39WzbklpkjNENvun3hUEwgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBADsaCJjYYNiiGftk+3XE iMjqLL/cktACt2eEEiowRjWOxfuJMGkbhaemu1Q10IIDW1VretDsrpb1mzRqtZurOVIexZk20BGD K0vOG9iRPF1c5Jz1cTrxxpE+IvycDMYFH6oJcIftVTs2qRCTqNJQm4HqN2925huwz5LCUfqHOE/a y3+QXLUQdebQM1Osovcd8WfZenqf0gOzidj32rlbH5+aRAl10nRKOnJN3BbOs2OI9+JA9Ex7X/rP f8LPpIadyYhPAn0cR+ieXF7ON/U8LTQ4ZtdeM+i4nnpxWL+3cIkmAAV7HCbP9vbHwuzEv90+kWV7 Dqcq8erysUxTLhUm3MsAAAAAAAA= --Apple-Mail-64--122790177-- --===============0990553307== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============0990553307==-- From pcn-bounces@ietf.org Fri Dec 01 20:22:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqJac-0008Vs-Bo; Fri, 01 Dec 2006 20:22:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqJab-0008Vn-VW for pcn@ietf.org; Fri, 01 Dec 2006 20:22:49 -0500 Received: from smtp.hsia.fairmont.com ([142.131.15.59] helo=torntsims03.hsia.fairmont.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqJaa-0007ym-O3 for pcn@ietf.org; Fri, 01 Dec 2006 20:22:49 -0500 Received: from [64.169.29.211] (unverified [64.169.29.211]) by torntsims03.hsia.fairmont.com (Vircom SMTPRS 4.2.425.4) with ESMTP id for ; Fri, 1 Dec 2006 19:59:20 -0500 X-Modus-BlackList: 64.169.29.211=OK;lars.eggert@netlab.nec.de=OK X-Modus-Trusted: 64.169.29.211=NO Received: from lars.local ([142.131.243.207]) by [64.169.29.211] (8.13.6/8.13.6) with ESMTP id kB21MV21003550 for ; Fri, 1 Dec 2006 17:22:31 -0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id C896429C376 for ; Fri, 1 Dec 2006 15:25:24 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CECA@E03MVZ1-UKDY.domain1.systemhost.net> References: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CECA@E03MVZ1-UKDY.domain1.systemhost.net> Message-Id: <55F14110-545E-474E-800C-B6EB161F9E18@netlab.nec.de> From: Lars Eggert Subject: Re: [PCN] PCN updated charter Date: Fri, 1 Dec 2006 15:25:23 -0800 To: pcn@ietf.org X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on localhost X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on sc1000 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0139455759==" Errors-To: pcn-bounces@ietf.org --===============0139455759== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-65--122753247; protocol="application/pkcs7-signature" --Apple-Mail-65--122753247 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Nov 30, 2006, at 1:46, wrote: > I'm not sure the encoding choices do limit the marking semantics that > much. I think the main impact of the encoding choice is on non-PCN > things like compatibility with RFC3168 & DSCP usage. That's a second reason why this should IMO be worked on first. Lars --Apple-Mail-65--122753247 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMjAx MjMyNTI0WjAjBgkqhkiG9w0BCQQxFgQU1oXsI268zCHU++s1uP/ogstmxq8wgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBAHD8ut2v5jjxE//nNxCP OrE2kRm9Bi0O2tyQue3SwXPF7bUxGxa3VVsadRXo5ag8v5QhHqabECDPLTJoMUMe4r7yod/DcaBm NTfmQ9FJ/7XPRWtcLlL+1lwVfDb72zqZN7VKcpjkBUQGlQ5Qp59+y4lELl5uhXp2dcOMGa2iu3Qg XXuIE/eTb+Iz67rwqW3mOHEpOoxoqLK+pyU9x+0W7vzG2U9Q+cb0KBijtGuVDW6UnHszG2MV6AqO +Hn2b5epG4Fbi9af/n9JggK65JCwyGuj7z/UTAxea9lxg0e8RT5ewFp6xbJYxwVtu43gu7WdzRUo nGX/2WEp9Ocj4RsEUH0AAAAAAAA= --Apple-Mail-65--122753247-- --===============0139455759== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============0139455759==-- From pcn-bounces@ietf.org Fri Dec 01 21:40:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqKnV-0003u9-JL; Fri, 01 Dec 2006 21:40:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqKnU-0003u3-R4 for pcn@ietf.org; Fri, 01 Dec 2006 21:40:12 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqKnS-0005TJ-HY for pcn@ietf.org; Fri, 01 Dec 2006 21:40:12 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 01 Dec 2006 18:40:09 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB22e9P0009488; Fri, 1 Dec 2006 21:40:09 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kB22e8DM024858; Fri, 1 Dec 2006 21:40:09 -0500 (EST) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 21:40:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN updated charter Date: Fri, 1 Dec 2006 21:40:07 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN updated charter Thread-Index: AccVsD6jJGJLWeJQSPOEbw+ARPfzCwACPXjg From: "Anna Charny \(acharny\)" To: "Lars Eggert" , X-OriginalArrivalTime: 02 Dec 2006 02:40:08.0764 (UTC) FILETIME=[2E9087C0:01C715BB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=834; t=1165027209; x=1165891209; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20\(acharny\)=22=20 |Subject:=20RE=3A=20[PCN]=20PCN=20=20updated=20charter |Sender:=20 |To:=20=22Lars=20Eggert=22=20, =20; bh=W3F1JMS8As/QrRlePSI6c7GI0a86ltPht5p6oVSyRhY=; b=dIfIeCpNtBoz7zCPXphWe1kBX5MHj7nIr8AKsExjeHi0fNmUW6PUSgSf3neBhnhjvsTZYZmM RgBjsZ0iDJGrC8mFGYDTUM28YUjb6mQyYUPVYJ6dm5qpWUk6Qw6AafNF; Authentication-Results: rtp-dkim-2; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org >> Perhaps stressing in the charter that the WG will consider the=20 >> implications of the lower levels of ingress-egress aggregation on the >> marking mechanisms may address this issue? >> >> >> >> [phil start] >> either like this or as a separate deployment model would work for me. >> I think the most important thing is the impact on the aggregation=20 >> assumption, as anna mentions [phil end] >Could you provide a paragraph to add to the charter that would outline=20 >this a bit? > >Lars How about: The WG will work on defining the applicability limits of the proposed mechanisms with respect to the aggregation assumptions on the bottleneck links as well as on a per PCN ingress-egress pair basis. =20 (Note that this was one of the stated requests at the BOF anyway).=20 Anna _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Dec 01 21:56:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqL2s-0003JT-0n; Fri, 01 Dec 2006 21:56:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqL2r-0003Hn-9e for pcn@ietf.org; Fri, 01 Dec 2006 21:56:05 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqL2p-0001GS-Vm for pcn@ietf.org; Fri, 01 Dec 2006 21:56:05 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 01 Dec 2006 18:56:03 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB22u2hJ012960; Fri, 1 Dec 2006 21:56:02 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB22u2YJ009868; Fri, 1 Dec 2006 21:56:02 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 21:56:02 -0500 Received: from jmpolk-wxp.cisco.com ([10.89.16.29]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 21:56:02 -0500 Message-Id: <4.3.2.7.2.20061201204648.02a83f08@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Dec 2006 20:56:01 -0600 To: "Anna Charny \(acharny\)" , "Lars Eggert" , From: "James M. Polk" Subject: RE: [PCN] PCN updated charter In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 02 Dec 2006 02:56:02.0193 (UTC) FILETIME=[66DA4010:01C715BD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1291; t=1165028162; x=1165892162; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[PCN]=20PCN=20=20updated=20charter |Sender:=20 |To:=20=22Anna=20Charny=20\(acharny\)=22=20, =0A=20=20= 20=20=20=20=20=20=22Lars=20Eggert=22=20, =20; bh=c+js6ycTHsJTVztMXXKNasGtvliRk9Btd33d2FcizFc=; b=n78RQD2CLhEOJbdbXwMyUGn0hpKNBJ3m8JcBJiZlMUfwV3X4Uxirm/hItGhbZFhk15MSkO7n 0QoZcmxYeTVQEXVK+gU6bJaZQM9NLGJ3No3Z5AeOjpxV0CPZxG3YAlLv; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org At 09:40 PM 12/1/2006 -0500, Anna Charny \(acharny\) wrote: > >> Perhaps stressing in the charter that the WG will consider the > >> implications of the lower levels of ingress-egress aggregation on the > > >> marking mechanisms may address this issue? > >> > >> > >> > >> [phil start] > >> either like this or as a separate deployment model would work for me. > > >> I think the most important thing is the impact on the aggregation > >> assumption, as anna mentions [phil end] > > >Could you provide a paragraph to add to the charter that would outline > >this a bit? > > > >Lars > >How about: > >The WG will work on defining the applicability limits of the proposed >mechanisms with respect to the aggregation assumptions on the bottleneck >links as well as on a per PCN ingress-egress pair basis. The WG will define applicability limits for all proposed mechnisms for each aggregation assumption. The current aggregations to be covered are bottleneck links, as well as on a per PCN ingress-egress pair basis. (my 2.2 cents) >(Note that this was one of the stated requests at the BOF anyway). > >Anna > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Dec 01 23:38:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqMeH-0001zz-DT; Fri, 01 Dec 2006 23:38:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqMeF-0001xK-FO for pcn@ietf.org; Fri, 01 Dec 2006 23:38:47 -0500 Received: from mx4.tellabs.com ([204.154.129.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqMeE-0004US-8q for pcn@ietf.org; Fri, 01 Dec 2006 23:38:47 -0500 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 02 Dec 2006 04:38:44 +0000 X-SBRS: None X-IronPort-AV: i="4.09,487,1157328000"; d="scan'208"; a="74093966:sNHT19605280" x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] gauging interest in PCN Date: Fri, 1 Dec 2006 22:37:24 -0600 Message-ID: <690D4DF342980C429A48EF7B35D3668607335A87@USNVEX3.tellabs-west.tellabsinc.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] gauging interest in PCN Thread-Index: AccVsD9n9qnW3bd1RMyPEGeFJ93joAAGWcEA From: "Kenney, John B." To: "Lars Eggert" , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org I will participate in a PCN WG. John Kenney -----Original Message----- From: Lars Eggert [mailto:lars.eggert@netlab.nec.de]=20 Sent: Friday, December 01, 2006 6:37 PM To: pcn@ietf.org Subject: [PCN] gauging interest in PCN Hi, independent of the exact initial technical scope, I'm trying to get a =20 feel for the energy of the broader community in the PCN space. There =20 have been a handful of vocal proponents on the list and at the =20 meeting, but I haven't heard from many people not already involved =20 with authoring the set of related drafts. If you're willing to actively participate in a PCN WG (read and =20 review drafts, etc.), please speak up. Lars =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sat Dec 02 07:55:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqUOS-0000GR-Gt; Sat, 02 Dec 2006 07:55:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqUOQ-0000FS-TK for pcn@ietf.org; Sat, 02 Dec 2006 07:54:58 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqUOP-0008Q6-Ki for pcn@ietf.org; Sat, 02 Dec 2006 07:54:58 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kB2Cspr4000833 for ; Sat, 2 Dec 2006 07:54:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] gauging interest in PCN Date: Sat, 2 Dec 2006 14:54:50 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] gauging interest in PCN Thread-Index: AccVsFOU2BAYEP3sRI2rAQT1NFKnpAAYIR4g From: "Romascanu, Dan \(Dan\) " To: "Lars Eggert" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org I am interested in the PCN work and I am willing to participate in a WG, although my bandwidth is currently rather limited.=20 Dan (speaking as an individual) =20 =20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@netlab.nec.de]=20 > Sent: Saturday, December 02, 2006 1:37 AM > To: pcn@ietf.org > Subject: [PCN] gauging interest in PCN >=20 > Hi, >=20 > independent of the exact initial technical scope, I'm trying=20 > to get a feel for the energy of the broader community in the=20 > PCN space. There have been a handful of vocal proponents on=20 > the list and at the meeting, but I haven't heard from many=20 > people not already involved with authoring the set of related drafts. >=20 > If you're willing to actively participate in a PCN WG (read=20 > and review drafts, etc.), please speak up. >=20 > Lars >=20 >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Dec 04 02:23:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr8Aw-0001D3-CE; Mon, 04 Dec 2006 02:23:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr8Au-00019c-HG for pcn@ietf.org; Mon, 04 Dec 2006 02:23:40 -0500 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gr8As-0003c0-29 for pcn@ietf.org; Mon, 04 Dec 2006 02:23:40 -0500 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 1DFC55F70; Mon, 4 Dec 2006 08:23:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 120BA5F59; Mon, 4 Dec 2006 08:23:29 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id F2D015035; Mon, 4 Dec 2006 08:23:28 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id kB47NSs07856; Mon, 4 Dec 2006 08:23:28 +0100 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 8A5656F58E; Mon, 4 Dec 2006 08:21:12 +0100 (CET) Message-ID: <4573CC39.3040306@informatik.uni-wuerzburg.de> Date: Mon, 04 Dec 2006 08:20:25 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [PCN] gauging interest in PCN References: <145E8647-883E-4F90-9C07-2A1C059538CE@netlab.nec.de> In-Reply-To: <145E8647-883E-4F90-9C07-2A1C059538CE@netlab.nec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi, I am interested in working in a PCN WG. Michael Lars Eggert wrote: > Hi, > > independent of the exact initial technical scope, I'm trying to get a > feel for the energy of the broader community in the PCN space. There > have been a handful of vocal proponents on the list and at the > meeting, but I haven't heard from many people not already involved > with authoring the set of related drafts. > > If you're willing to actively participate in a PCN WG (read and review > drafts, etc.), please speak up. > > Lars > > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Dec 04 02:32:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr8JR-0008Ax-Vd; Mon, 04 Dec 2006 02:32:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr8JR-0008Ap-Kr for pcn@ietf.org; Mon, 04 Dec 2006 02:32:29 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gr8JP-0004Zn-8R for pcn@ietf.org; Mon, 04 Dec 2006 02:32:29 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Mon, 4 Dec 2006 08:32:16 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 08:32:15 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] gauging interest in PCN X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 4 Dec 2006 08:32:15 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF9DE@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <145E8647-883E-4F90-9C07-2A1C059538CE@netlab.nec.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] gauging interest in PCN Thread-Index: AccVsEDvERWnDYmXS4ajc2vSH5tC6QBxZt8Q From: "Geib, Ruediger" To: X-OriginalArrivalTime: 04 Dec 2006 07:32:15.0817 (UTC) FILETIME=[52541390:01C71776] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Lars, I'm not an author. I've been active on the list already for=20 a while and I plan to continue to be active. Regards, Rudiger T-Systems Enterprise Services GmbH Senior Expert Systems Integration=20 Technologiezentrum Engineering Networks, Products & Services Packet based Carrier Transport Networks Deutsche-Telekom-Allee 7, D-64295 Darmstadt http://www.t-systems.com =20 |-----Original Message----- |From: Lars Eggert [mailto:lars.eggert@netlab.nec.de] |Sent: Saturday, December 02, 2006 12:37 AM |To: pcn@ietf.org |Subject: [PCN] gauging interest in PCN | | |Hi, | |independent of the exact initial technical scope, I'm trying to get a =20 |feel for the energy of the broader community in the PCN space. There =20 |have been a handful of vocal proponents on the list and at the =20 |meeting, but I haven't heard from many people not already involved =20 |with authoring the set of related drafts. | |If you're willing to actively participate in a PCN WG (read and =20 |review drafts, etc.), please speak up. | |Lars | | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Dec 04 02:52:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr8cL-0006ry-MM; Mon, 04 Dec 2006 02:52:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr8cK-0006rf-Bi for pcn@ietf.org; Mon, 04 Dec 2006 02:52:00 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gr8c9-00079K-Nt for pcn@ietf.org; Mon, 04 Dec 2006 02:52:00 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2A9D94F0002; Mon, 4 Dec 2006 08:51:20 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 08:51:19 +0100 Received: from ericsson.com ([147.214.26.58]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 08:51:18 +0100 Message-ID: <4573D376.4080405@ericsson.com> Date: Mon, 04 Dec 2006 08:51:18 +0100 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lars Eggert Subject: Re: [PCN] gauging interest in PCN References: <145E8647-883E-4F90-9C07-2A1C059538CE@netlab.nec.de> In-Reply-To: <145E8647-883E-4F90-9C07-2A1C059538CE@netlab.nec.de> X-OriginalArrivalTime: 04 Dec 2006 07:51:18.0989 (UTC) FILETIME=[FBB647D0:01C71778] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1752064075==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1752064075== Content-Type: multipart/alternative; boundary="------------060301060103000303040808" This is a multi-part message in MIME format. --------------060301060103000303040808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit i am interested regards Lasse Lars Eggert wrote: > Hi, > > independent of the exact initial technical scope, I'm trying to get a > feel for the energy of the broader community in the PCN space. There > have been a handful of vocal proponents on the list and at the > meeting, but I haven't heard from many people not already involved > with authoring the set of related drafts. > > If you're willing to actively participate in a PCN WG (read and > review drafts, etc.), please speak up. > > Lars > >------------------------------------------------------------------------ > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn > > --------------060301060103000303040808 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit i am interested

regards Lasse

Lars Eggert wrote:
[PCN] gauging interest in PCN

Hi,

independent of the exact initial technical scope, I'm trying to get a 
feel for the energy of the broader community in the PCN space. There 
have been a handful of vocal proponents on the list and at the 
meeting, but I haven't heard from many people not already involved 
with authoring the set of related drafts.

If you're willing to actively participate in a PCN WG (read and 
review drafts, etc.), please speak up.

Lars

 


_______________________________________________
PCN mailing list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn
--------------060301060103000303040808-- --===============1752064075== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============1752064075==-- From pcn-bounces@ietf.org Mon Dec 04 04:38:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrAH9-0001Zo-Mc; Mon, 04 Dec 2006 04:38:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrAH9-0001Zj-0F for pcn@ietf.org; Mon, 04 Dec 2006 04:38:15 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrAH7-0007CE-LH for pcn@ietf.org; Mon, 04 Dec 2006 04:38:14 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id kB49c5ST021699; Mon, 4 Dec 2006 10:38:11 +0100 (MET) From: "Georgios Karagiannis" To: "'Lars Eggert'" , Subject: RE: [PCN] gauging interest in PCN Date: Mon, 4 Dec 2006 10:38:02 +0100 Message-ID: <002401c71787$e7be2310$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccVsDywNgJ/WhywQ0OHg2bXbDtSIQB13Z6Q In-Reply-To: <145E8647-883E-4F90-9C07-2A1C059538CE@netlab.nec.de> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 04 Dec 2006 10:38:12 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Lars I am interested to actively participate in the PCN working group. Best regards, Georgios > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@netlab.nec.de] > Sent: zaterdag 2 december 2006 0:37 > To: pcn@ietf.org > Subject: [PCN] gauging interest in PCN > > Hi, > > independent of the exact initial technical scope, I'm trying > to get a feel for the energy of the broader community in the > PCN space. There have been a handful of vocal proponents on > the list and at the meeting, but I haven't heard from many > people not already involved with authoring the set of related drafts. > > If you're willing to actively participate in a PCN WG (read > and review drafts, etc.), please speak up. > > Lars > > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Dec 04 04:49:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrASJ-0006L2-LJ; Mon, 04 Dec 2006 04:49:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrASH-0006KH-Tq for pcn@ietf.org; Mon, 04 Dec 2006 04:49:45 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrASG-0000H9-IG for pcn@ietf.org; Mon, 04 Dec 2006 04:49:45 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id kB49nd2x022172; Mon, 4 Dec 2006 10:49:42 +0100 (MET) From: "Georgios Karagiannis" To: "'Lars Eggert'" , Date: Mon, 4 Dec 2006 10:49:35 +0100 Message-ID: <002e01c71789$84635810$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccVsD3ipk5rMAYYRlOHK3zOkflnMgB2BKQg In-Reply-To: <1733DAE6-2468-4DAB-B434-893CB42B0FD4@netlab.nec.de> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 04 Dec 2006 10:49:43 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [PCN] Regarding application based deployment model X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Lars A cleaner way of identifying what are the goals and requirements on the PCN functionalities is to work on the following deployment models: * Intserv of diffserv deployment model * Application based deployment model Note that interests were expressed on the PCN mailing list on willing to work on the application based deployment model. Best regards, Georgios > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@netlab.nec.de] > Sent: zaterdag 2 december 2006 0:25 > To: pcn@ietf.org > Subject: Re: [PCN] PCN updated charter > > On Nov 30, 2006, at 1:34, > wrote: > > Perhaps stressing in the charter that the WG will consider the > > implications of the lower levels of ingress-egress > aggregation on the > > marking mechanisms may address this issue? > > > > > > > > [phil start] > > either like this or as a separate deployment model would > work for me. > > I think the most important thing is the impact on the aggregation > > assumption, as anna mentions [phil end] > > Could you provide a paragraph to add to the charter that > would outline this a bit? > > Lars > > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Dec 04 09:06:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrET1-0006NF-Mt; Mon, 04 Dec 2006 09:06:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrET0-0006NA-JG for pcn@ietf.org; Mon, 04 Dec 2006 09:06:46 -0500 Received: from relay-pt1.siemens.pt ([194.145.62.202] helo=relay2.siemens.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrESx-00024W-VH for pcn@ietf.org; Mon, 04 Dec 2006 09:06:46 -0500 Received: from fw-mta1.siemens.pt (fw-mta1.siemens.pt [141.29.156.201]) by relay2.siemens.pt (8.12.8/8.12.9) with ESMTP id kB4DpWr0004059; Mon, 4 Dec 2006 13:51:34 GMT Received: from PTLISI052MSX.PT001.SIEMENS.NET (ptlisi052n02.pt001.siemens.net [141.29.156.66]) by fw-mta1.siemens.pt (Hvm) with ESMTP id kB4E6Ft24901; Mon, 4 Dec 2006 14:06:16 GMT Received: from PTLISI051MSX.PT001.SIEMENS.NET ([141.29.156.78]) by PTLISI052MSX.PT001.SIEMENS.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 14:06:15 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] gauging interest in PCN Date: Mon, 4 Dec 2006 14:06:10 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] gauging interest in PCN Thread-Index: AccXeTvDTKX9ATGvSeGWBUuxHQgH+wAM9BJQ From: "Garcia, Nuno" To: "Lars Eggert" X-OriginalArrivalTime: 04 Dec 2006 14:06:15.0925 (UTC) FILETIME=[5CEE4A50:01C717AD] X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1325742617==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1325742617== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C717AD.5CB1420D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C717AD.5CB1420D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: =20 I'm interested in actively participate in a PCN WG. =20 Best regards, =20 Nuno M. Garcia Lars Eggert wrote: Hi, =09 independent of the exact initial technical scope, I'm trying to get a=20 feel for the energy of the broader community in the PCN space. There=20 have been a handful of vocal proponents on the list and at the=20 meeting, but I haven't heard from many people not already involved=20 with authoring the set of related drafts. =09 If you're willing to actively participate in a PCN WG (read and=20 review drafts, etc.), please speak up. =09 Lars =09 =09 =09 ________________________________ _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn =20 ------_=_NextPart_001_01C717AD.5CB1420D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi:
 
I'm interested in actively participate in a = PCN=20 WG.
 
Best = regards,
 
Nuno M. = Garcia

Lars Eggert wrote:

Hi,

independent of the exact initial = technical scope,=20 I'm trying to get a 
feel for the energy of the broader = community in=20 the PCN space. There 
have been a handful of vocal = proponents on the=20 list and at the 
meeting, but I haven't heard from many = people not=20 already involved 
with authoring the set of related=20 drafts.

If you're willing to actively participate in a PCN WG = (read=20 and 
review drafts, etc.), please speak=20 up.

Lars


_______________________________________________
PCN mailing list
PCN@ietf.org
https://www1.ietf.org=
/mailman/listinfo/pcn
------_=_NextPart_001_01C717AD.5CB1420D-- --===============1325742617== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============1325742617==-- From pcn-bounces@ietf.org Mon Dec 04 10:21:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrFdg-0003hT-JH; Mon, 04 Dec 2006 10:21:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrFdf-0003hO-Oa for pcn@ietf.org; Mon, 04 Dec 2006 10:21:51 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrFde-00038W-7x for pcn@ietf.org; Mon, 04 Dec 2006 10:21:51 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kB4FLli15485 for ; Mon, 4 Dec 2006 10:21:48 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] gauging interest in PCN Date: Mon, 4 Dec 2006 09:21:06 -0600 Message-ID: <7A3E36B3528ED04A880178D337F30C9A103340F8@zrc2hxm1.corp.nortel.com> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650D83EDBF@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] gauging interest in PCN Thread-Index: AccVsEMbZfHDuFIfQ76CSmd7ulC2wQB+R8gAAAOFpgA= From: "Corey Alexander" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org I will participate, at a minimum with reading and reviewing drafts. Corey W. Alexander=20 ESN 444-8320 (972-684-8320)=20 coreya@nortel.com -----Original Message----- From: Lars Eggert [mailto:lars.eggert@netlab.nec.de]=20 Sent: Friday, December 01, 2006 6:37 PM To: pcn@ietf.org Subject: [PCN] gauging interest in PCN Hi, independent of the exact initial technical scope, I'm trying to get a =20 feel for the energy of the broader community in the PCN space. There =20 have been a handful of vocal proponents on the list and at the =20 meeting, but I haven't heard from many people not already involved =20 with authoring the set of related drafts. If you're willing to actively participate in a PCN WG (read and =20 review drafts, etc.), please speak up. Lars _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Dec 04 10:48:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrG3a-0004ih-Je; Mon, 04 Dec 2006 10:48:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrG3Z-0004iI-Kd for pcn@ietf.org; Mon, 04 Dec 2006 10:48:37 -0500 Received: from out002.iad.hostedmail.net ([209.225.56.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrG3Y-0007Nq-Ch for pcn@ietf.org; Mon, 04 Dec 2006 10:48:37 -0500 Received: from ATL1VEXC010.usdom003.tco.tc ([10.158.7.19]) by out002.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 10:48:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Dec 2006 10:48:15 -0500 Message-ID: <941E166DB8C7F543B1FDDE0D8CAF294903D23228@ATL1VEXC010.usdom003.tco.tc> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: gauging interest in PCN Thread-Index: AccWM1Q+fit08nDETwCoHhcJjtoE6ABh/mEg From: "Ken Young" To: X-OriginalArrivalTime: 04 Dec 2006 15:48:33.0161 (UTC) FILETIME=[A7022F90:01C717BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [PCN] RE: gauging interest in PCN X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org I am interested in participating and reading the drafts. Cheers, Ken >> Message: 6 >> Date: Fri, 1 Dec 2006 15:36:52 -0800 >> From: Lars Eggert >> Subject: [PCN] gauging interest in PCN >> To: pcn@ietf.org >> Message-ID: <145E8647-883E-4F90-9C07-2A1C059538CE@netlab.nec.de> >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi, >> >> independent of the exact initial technical scope, I'm trying to get a >> feel for the energy of the broader community in the PCN space. There >> have been a handful of vocal proponents on the list and at the =20 >> meeting, but I haven't heard from many people not already involved =20 >> with authoring the set of related drafts. >> >> If you're willing to actively participate in a PCN WG (read and =20 >> review drafts, etc.), please speak up. >> >> Lars _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Dec 05 06:13:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrYEb-00011v-MU; Tue, 05 Dec 2006 06:13:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrYEa-0000yU-Gn for pcn@ietf.org; Tue, 05 Dec 2006 06:13:12 -0500 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrYEZ-0005um-7s for pcn@ietf.org; Tue, 05 Dec 2006 06:13:12 -0500 Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by mailer.gwdg.de with esmtp (Exim 4.60) (envelope-from ) id 1GrYET-00080D-U9; Tue, 05 Dec 2006 12:13:05 +0100 Received: by s2.ifi.informatik.uni-goettingen.de (Postfix, from userid 1009) id C528DFF86; Tue, 5 Dec 2006 12:13:05 +0100 (CET) References: <145E8647-883E-4F90-9C07-2A1C059538CE@netlab.nec.de> In-Reply-To: <145E8647-883E-4F90-9C07-2A1C059538CE@netlab.nec.de> From: "Xiaoming Fu" To: Lars Eggert Subject: Re: [PCN] gauging interest in PCN Date: Tue, 05 Dec 2006 12:13:05 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Sender: fu@s2.ifi.informatik.uni-goettingen.de Message-Id: <20061205111305.C528DFF86@s2.ifi.informatik.uni-goettingen.de> X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org I am interested in this. Xiaoming Lars Eggert writes: > Hi, > > independent of the exact initial technical scope, I'm trying to get a > feel for the energy of the broader community in the PCN space. There have > been a handful of vocal proponents on the list and at the meeting, but I > haven't heard from many people not already involved with authoring the > set of related drafts. > > If you're willing to actively participate in a PCN WG (read and review > drafts, etc.), please speak up. > > Lars > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Dec 05 13:05:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gref1-0007Sd-Vg; Tue, 05 Dec 2006 13:04:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gref0-0007SY-N3 for pcn@ietf.org; Tue, 05 Dec 2006 13:04:54 -0500 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Greey-0001PD-Dz for pcn@ietf.org; Tue, 05 Dec 2006 13:04:54 -0500 Received: from vpn-2020.gwdg.de ([134.76.2.20]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1Greeu-00044W-Rp; Tue, 05 Dec 2006 19:04:49 +0100 Message-ID: <4575B4C9.8080407@cs.uni-goettingen.de> Date: Tue, 05 Dec 2006 19:04:57 +0100 From: Xiaoming Fu Organization: University of Goettingen, Germany User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [PCN] Regarding application based deployment model References: <002e01c71789$84635810$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <002e01c71789$84635810$4c0d5982@dynamic.ewi.utwente.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:xfu X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: 'Lars Eggert' , pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Georgios, Quick comments (sorry if I miscatch): Georgios Karagiannis wrote: > Hi Lars > > A cleaner way of identifying what are > the goals and requirements on the PCN functionalities > is to work on the following deployment models: > * Intserv of diffserv deployment model > * Application based deployment model IntServ/DiffServ is clear, but what do you mean by app-based deployment model? Do you want to know how the application utilizes the PCN services/func, i.e., an API issue? Xiaoming _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Dec 05 13:51:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrfNn-0001Be-ON; Tue, 05 Dec 2006 13:51:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrfNn-0001BZ-Bt for pcn@ietf.org; Tue, 05 Dec 2006 13:51:11 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrfNl-0007a2-0b for pcn@ietf.org; Tue, 05 Dec 2006 13:51:11 -0500 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kB5Ioj723411; Tue, 5 Dec 2006 13:50:45 -0500 (EST) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 13:50:43 -0500 Message-Id: <6.2.5.6.0.20061205134049.035fa410@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 05 Dec 2006 13:50:42 -0500 To: Xiaoming Fu From: "Kwok-Ho Chan" Subject: Re: [PCN] Regarding application based deployment model In-Reply-To: <4575B4C9.8080407@cs.uni-goettingen.de> References: <002e01c71789$84635810$4c0d5982@dynamic.ewi.utwente.nl> <4575B4C9.8080407@cs.uni-goettingen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 05 Dec 2006 18:50:43.0085 (UTC) FILETIME=[4429FBD0:01C7189E] X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 'Lars Eggert' , pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Xiaoming: Yes to the first part of what you are indicating: By "Application Deployment Model", we mean (as you indicated), a deployment model on how applications may use the information provided by the PCN mechanism. This is in parallel to the "IntServ over DiffServ Deployment Model", which is a deployment model on how IntServ over DiffServ mechanisms may use the information provided by the PCN mechanism. But we are not trying to specify (standardize) an API by the document we are creating. We are seeing both the Application Control and the IntServ over DiffServ Deployment Models as Informational Track documents. Hope this answers your questions. Thanks! -- Kwok -- At 01:04 PM 12/5/2006, Xiaoming Fu wrote: >Georgios, > >Quick comments (sorry if I miscatch): >Georgios Karagiannis wrote: >>Hi Lars >>A cleaner way of identifying what are the goals and requirements on >>the PCN functionalities is to work on the following deployment models: >>* Intserv of diffserv deployment model >>* Application based deployment model > >IntServ/DiffServ is clear, but what do you mean by app-based deployment model? >Do you want to know how the application utilizes the PCN >services/func, i.e., an API issue? > >Xiaoming > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Dec 05 15:29:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grgug-0001vg-HW; Tue, 05 Dec 2006 15:29:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grguf-0001va-RM for pcn@ietf.org; Tue, 05 Dec 2006 15:29:13 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grgue-0001Di-GF for pcn@ietf.org; Tue, 05 Dec 2006 15:29:13 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kB5KLjY26823; Tue, 5 Dec 2006 15:21:45 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Regarding application based deployment model Date: Tue, 5 Dec 2006 15:28:54 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650D8EE9CD@zcarhxm1.corp.nortel.com> In-Reply-To: <6.2.5.6.0.20061205134049.035fa410@nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Regarding application based deployment model Thread-Index: AccYnmpQXLbFALM4Rqetoj4OK6dkpwABy2Ug From: "Jozef Babiarz" To: "Kwok-Ho Chan" , "Xiaoming Fu" X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Lars Eggert , pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Xiaoming:=20 I would like to add to what Kwok wrote that:=20 1./ The PCN WG needs to agree on a router marking behavior and encoding that can be used if different deployment models. 2./ The two proposed deployment models would be used to test through simulations and analysis that infect the selected marking behavior in routers does work satisfactory for both. =20 Application-Controlled Admission and Preemption deployment model addresses situations where pre-congestion information is conveyed via ECN bits or possibility DSCP to the application and the application controls admission of a new flow or should existing admitted flow be terminated (preempted). In the first phase the WG will assume that the application, routers and hosts (IP phones/gateways) are trusted but later after rechartering the group would look at if that is not the case. A SIP example of the Application-Controlled Admission deployment model can be found in http://www.ietf.org/internet-drafts/draft-babiarz-pcn-sip-cap-00.txt. >From the PCN BOF, the suggestion that most agreed with was that the SIP-Controlled Admission and Preemption deployment model be made more generic with SIP as an example so that it could be applied to other signalling protocols and not just SIP. Hope this helps. -----Original Message----- From: Chan, Kwok-Ho (BL60:470)=20 Sent: Tuesday, December 05, 2006 1:51 PM To: Xiaoming Fu Cc: 'Lars Eggert'; pcn@ietf.org Subject: Re: [PCN] Regarding application based deployment model Xiaoming: Yes to the first part of what you are indicating: By "Application Deployment Model", we mean (as you indicated), a deployment model on how applications may use the information provided by the PCN mechanism. This is in parallel to the "IntServ over DiffServ Deployment Model", which is a deployment model on how IntServ over DiffServ mechanisms may use the information provided by the PCN mechanism. But we are not trying to specify (standardize) an API by the document=20 we are creating. We are seeing both the Application Control and the IntServ over=20 DiffServ Deployment Models as Informational Track documents. Hope this answers your questions. Thanks! -- Kwok -- At 01:04 PM 12/5/2006, Xiaoming Fu wrote: >Georgios, > >Quick comments (sorry if I miscatch): >Georgios Karagiannis wrote: >>Hi Lars >>A cleaner way of identifying what are the goals and requirements on=20 >>the PCN functionalities is to work on the following deployment models: >>* Intserv of diffserv deployment model >>* Application based deployment model > >IntServ/DiffServ is clear, but what do you mean by app-based deployment model? >Do you want to know how the application utilizes the PCN=20 >services/func, i.e., an API issue? > >Xiaoming > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Dec 06 04:47:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrtNN-0001nh-Ep; Wed, 06 Dec 2006 04:47:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrtNM-0001nc-A1 for pcn@ietf.org; Wed, 06 Dec 2006 04:47:40 -0500 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrtNK-0004PI-RJ for pcn@ietf.org; Wed, 06 Dec 2006 04:47:40 -0500 Received: from vpn-2004.gwdg.de ([134.76.2.4]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1GrtMy-0003Qj-TT; Wed, 06 Dec 2006 10:47:17 +0100 Message-ID: <457691A9.7010303@cs.uni-goettingen.de> Date: Wed, 06 Dec 2006 10:47:21 +0100 From: Xiaoming Fu Organization: University of Goettingen, Germany User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jozef Babiarz Subject: Re: [PCN] Regarding application based deployment model References: <9671A92C3C8B5744BC97F855F7CB64650D8EE9CD@zcarhxm1.corp.nortel.com> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650D8EE9CD@zcarhxm1.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:xfu X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Lars Eggert , pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Jozef and Kwok, This sounds reasonable to me. I think this is useful work. Cheers, Xiaoming Jozef Babiarz wrote: > Xiaoming: > > I would like to add to what Kwok wrote that: > 1./ The PCN WG needs to agree on a router marking behavior and encoding > that can be used if different deployment models. > 2./ The two proposed deployment models would be used to test through > simulations and analysis that infect the selected marking behavior in > routers does work satisfactory for both. > > Application-Controlled Admission and Preemption deployment model > addresses situations where pre-congestion information is conveyed via > ECN bits or possibility DSCP to the application and the application > controls admission of a new flow or should existing admitted flow be > terminated (preempted). In the first phase the WG will assume that the > application, routers and hosts (IP phones/gateways) are trusted but > later after rechartering the group would look at if that is not the > case. A SIP example of the Application-Controlled Admission deployment > model can be found in > http://www.ietf.org/internet-drafts/draft-babiarz-pcn-sip-cap-00.txt. > From the PCN BOF, the suggestion that most agreed with was that the > SIP-Controlled Admission and Preemption deployment model be made more > generic with SIP as an example so that it could be applied to other > signalling protocols and not just SIP. > > Hope this helps. > > > -----Original Message----- > From: Chan, Kwok-Ho (BL60:470) > Sent: Tuesday, December 05, 2006 1:51 PM > To: Xiaoming Fu > Cc: 'Lars Eggert'; pcn@ietf.org > Subject: Re: [PCN] Regarding application based deployment model > > Xiaoming: > Yes to the first part of what you are indicating: > By "Application Deployment Model", we mean (as you indicated), > a deployment model on how applications may use the information provided > by the PCN mechanism. > This is in parallel to the "IntServ over DiffServ Deployment Model", > which is > a deployment model on how IntServ over DiffServ mechanisms may use the > information provided by the PCN mechanism. > > But we are not trying to specify (standardize) an API by the document > we are creating. > We are seeing both the Application Control and the IntServ over > DiffServ Deployment > Models as Informational Track documents. > > Hope this answers your questions. > Thanks! > -- Kwok -- > > At 01:04 PM 12/5/2006, Xiaoming Fu wrote: >> Georgios, >> >> Quick comments (sorry if I miscatch): >> Georgios Karagiannis wrote: >>> Hi Lars >>> A cleaner way of identifying what are the goals and requirements on >>> the PCN functionalities is to work on the following deployment models: >>> * Intserv of diffserv deployment model >>> * Application based deployment model >> IntServ/DiffServ is clear, but what do you mean by app-based deployment > model? >> Do you want to know how the application utilizes the PCN >> services/func, i.e., an API issue? >> >> Xiaoming >> >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www1.ietf.org/mailman/listinfo/pcn > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Dec 08 06:16:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsdi2-0005hl-Br; Fri, 08 Dec 2006 06:16:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsdi0-0005bw-K2 for pcn@ietf.org; Fri, 08 Dec 2006 06:16:04 -0500 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsdhx-0000rC-3K for pcn@ietf.org; Fri, 08 Dec 2006 06:16:04 -0500 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 22FE85FE1; Fri, 8 Dec 2006 12:15:56 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 17BA35FDC; Fri, 8 Dec 2006 12:15:56 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id EF6A92FFF; Fri, 8 Dec 2006 12:15:55 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id kB8BFts30748; Fri, 8 Dec 2006 12:15:55 +0100 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id B62C66F58E; Fri, 8 Dec 2006 12:13:35 +0100 (CET) Message-ID: <457948AE.6080701@informatik.uni-wuerzburg.de> Date: Fri, 08 Dec 2006 12:12:46 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: pcn@ietf.org, Anna Charny Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Subject: [PCN] Feedback on performance draft X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Dear Anna et al., I've read your draft http://www.ietf.org/internet-drafts/draft-zhang-pcn-performance-evaluation-00.txt My overall impression: nice document and interesting and informative results! I've got some comments. ad 3.7/5.1) PCN works well also with small ingress-egress aggregation, i.e., over-admission is not observed with the simulated traffic. This can be explained as follows. If the admissible rate of an interface is exceeded, ALL packets flowing over the respective link are admission-stop labelled and their egress routers signal this information back to the respective ingress routers. As a consequence, all ingress routers having at least a single flow in progress are informed about the bottleneck. Therefore, this kind of implicit signalling is independent of the aggregation level. ad 4.2/5.2) If the preemption threshold is exceeded, only those packets are labelled that exceed the {tolerable interface, excess traffic, preemption} rate. The observation was that preemption marked packets were not distributed equally over all flows, but some flows had all off their packets labelled and some others had no packet labelled at all. I think this is due to the periodic nature of the aggregated process. The phase (= transmission instant within a period) of a flow within the aggregated process determines the "queue" encountered by its packets in any period. Randomizing the transmission time breaks this phenomenon if the randomization is strong enough. Applying a jitter offset to every transmission instant which is equally distributed in [0, period length] should lead to strong over-preemption for all simulated scenarios. Without randomization, this effect could be provoked by choosing different period length for the traffic and adjusting the packet sizes accordingly. Try prime numbers if you want to avoid short cycles: period lengths of 13, 17, 19, 23, 29, 31 ms! Kind regards, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Dec 13 09:58:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuVZG-0005Qa-N4; Wed, 13 Dec 2006 09:58:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuVZF-0005QT-Fl for pcn@ietf.org; Wed, 13 Dec 2006 09:58:45 -0500 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GuVZ8-0007F5-Ch for pcn@ietf.org; Wed, 13 Dec 2006 09:58:45 -0500 Received: from I2KF03BV-UKBR.domain1.systemhost.net ([193.113.197.43]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 14:58:33 +0000 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by I2KF03BV-UKBR.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Dec 2006 14:58:32 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Dec 2006 14:58:30 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CF4A@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on single marking draft Thread-Index: AccexyaTBlhK3y8XQeWPUER0mhigGw== From: To: X-OriginalArrivalTime: 13 Dec 2006 14:58:32.0758 (UTC) FILETIME=[2858C560:01C71EC7] X-Spam-Score: 0.6 (/) X-Scan-Signature: 8da0cbf8c1eef8eab03772f2044efec0 Subject: [PCN] comments on single marking draft X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0214770447==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0214770447== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71EC7.26F5C177" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71EC7.26F5C177 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Anna, all, =20 Here at last are some comments on your single marking idea as described in http://ietf.org/internet-drafts/draft-charny-pcn-single-marking-00.txt =20 The flow pre-emption mechanism is essentially the same as in the Briscoe drafts, so they should behave the same. The comments below are all for admission control.=20 =20 =20 The draft is very interesting, due to its two big advantages, as you point out: - only need a single pkt encoding, easier to stdise - only need a single measurement operation at routers [so simpler, faster] & this a measurement they do anyway [easier router upgrade] =20 in your simulations, you analyse the probability of "false accepts" ie accept calls when the network state really means should be rejected. >From your simulations, it seems this is probably OK, although it's harder to choose the parameters that make it work (harder than for the Briscoe i-d).=20 =20 * Reaction time: An important potential drawback is how quickly it reacts to changes in load, especially if the load suddenly increases above the configured-admission-rate how quickly does the mechanism ensure that new calls are rejected. This is worse for the token bucket algorithm compared with the virtual queue - because the latter moves rapidly from marking 0% to 100% of packets as the load increases, whilst the former only marks the excess rate.=20 Also, a smaller ewma 'weight' means that the egress effectively averages over a longer time. Unfortunately, for the video scenario Table A4 suggests you need to use a small ewma weight.=20 =20 It would be nice to get a handle on how significant this problem is.=20 =20 ewma 'weight':- ewma_new =3D weight * new_measurement + (1-weight)*ewma_old calculated/measured every 100ms interval according to http://www.ietf.org/internet-drafts/draft-zhang-pcn-performance-evaluati on-00.txt=20 so a weight of 0.1 is very roughly smoothing over about 1sec & weight of 0.9 smoothing over roughly 0.1sec. I'd imagined the smoothing was over a shorter time period. =20 =20 * False rejects: One danger (which I don't think you considered) is that new call request(s) may be rejected when they actually should be accepted, because the measured-ewma (=3DCLE) is greater than the CLE_threshold whereas the actual-ewma is smaller. In general, an operator won't like false rejects (=3D money). =20 It's quite hard to know how to assess this problem. Say you set CLE-threshold to 5% - there'll be times when you measure CLE as 5.01% (& reject) when really it's 4.99% - however, the actual traffic level is pretty much at your design level, so this error doesn't feel too important to me. However, if your CLE-threshold is 0.01% my instinct is that there's a much higher chance of falsely rejecting a call when the actual traffic level is still quite a way below your design level. =20 Unfortunately, for the video scenario Table A4 suggests you need to use a small CLE-threshold. =20 =20 * Inter-domain case you use a system-wide constant u, the assumed ratio between pre-emption and admission thresholds for all links in the PCN-region.=20 The thought is that the PCN-region can gradually be extended to cover multiple domains. But each might be using different values for u - so inter-domain operations might be hampered. This needs more thought.=20 =20 =20 * Other comments: - it would be nice if the simulations could be re-run for multiple videos per ingress-egress-aggregate - to check that the deduction is correct that "we believe that the severe degradation of performance in this topology is directly attributable to the lack of traffic aggregation on the ingress-egress pair basis." - in the simulations, could you check whether the probability of accepting a call request on a *particular* ingresss-egress-aggregate is biased by the RTT=20 - your assumptions in the simulations seemed ok to me: - single bottleneck - if there are multiple bottlenecks, would expect the method still to be ok - the marking %s combine as required.=20 - No packet loss - if there was packet loss, would expect method still to be ok, as would expect all packets getting through the overloaded router to be marked. NB must not preferentially drop marked packets, otherwise might get no pkts through. =20 =20 =20 ------_=_NextPart_001_01C71EC7.26F5C177 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Anna, all,

 

Here at last are some comments on your single marking idea as = described in http://ietf.org/internet-drafts/draft-charny-pcn-single-marking-00= .txt

 

The flow pre-emption mechanism is essentially the same as in the Briscoe drafts, so they should behave the same. The comments below are = all for admission control.

 

 

The draft is very interesting, due to its two big advantages, as = you point out:

- only need a single pkt encoding, easier to = stdise

- only need a single measurement operation at routers [so = simpler, faster] & this a measurement they do anyway [easier router = upgrade]

 

in your simulations, you analyse the probability of “false accepts” ie accept calls when the network state really means = should be rejected. From your simulations, it seems this is probably OK, although = it’s harder to choose the parameters that make it work (harder than for the = Briscoe i-d).

 

* Reaction time:

An important potential drawback is how quickly it reacts to = changes in load, especially if the load suddenly increases above the configured-admission-rate how quickly does the mechanism ensure that new = calls are rejected. This is worse for the token bucket algorithm compared with = the virtual queue – because the latter moves rapidly from marking 0% = to 100% of packets as the load increases, whilst the former only marks the = excess rate.

Also, a smaller ewma ‘weight’ means that the egress effectively averages over a longer time. Unfortunately, for the video = scenario Table A4 suggests you need to use a small ewma weight. =

 

It would be nice to get a handle on how significant this problem = is.

 

ewma ‘weight’:-

ewma_new =3D weight * new_measurement + = (1-weight)*ewma_old

calculated/measured every 100ms interval according to http://www.ietf.org/internet-drafts/draft-zhang-pcn-per= formance-evaluation-00.txt

so a weight of 0.1 is very roughly smoothing over about 1sec = & weight of 0.9 smoothing over roughly 0.1sec.

I’d imagined the smoothing was over a shorter time = period.

           = ;            =              =

 

* False rejects:

One danger (which I don’t think you considered) is that = new call request(s) may be rejected when they actually should be accepted, = because the measured-ewma (=3DCLE) is greater than the CLE_threshold whereas the actual-ewma is = smaller. In general, an operator won’t like false rejects (=3D = money).

 

It’s quite hard to know how to assess this problem. Say = you set CLE-threshold to 5% - there’ll be times when you measure CLE as = 5.01% (& reject) when really it’s 4.99% - however, the actual = traffic level is pretty much at your design level, so this error doesn’t feel = too important to me. However, if your CLE-threshold is 0.01% my instinct is = that there’s a much higher chance of falsely rejecting a call when the = actual traffic level is still quite a way below your design = level.

 

Unfortunately, for the video scenario Table A4 suggests you need = to use a small CLE-threshold.

 

 

* Inter-domain case

you use a system-wide constant u, the assumed ratio between = pre-emption and admission thresholds for all links in the PCN-region. =

The thought is that the PCN-region can gradually be extended to = cover multiple domains. But each might be using different values for u – = so inter-domain operations might be hampered. This needs more thought. =

 

 

* Other comments:

- it would be nice if the simulations could be re-run for = multiple videos per ingress-egress-aggregate – to check that the deduction = is correct that “we believe that the severe degradation of = performance in this topology is directly attributable to the lack of traffic = aggregation on the ingress-egress pair basis.”

- in the simulations, could you check whether the probability of accepting a call request on a *particular* ingresss-egress-aggregate is = biased by the RTT

- your assumptions in the simulations seemed ok to = me:

  - single bottleneck – if there are multiple = bottlenecks, would expect the method still to be ok – the marking %s combine as required.

  - No packet loss – if there was packet loss, would = expect method still to be ok, as would expect all packets getting through the overloaded router to be marked. NB must not preferentially drop marked = packets, otherwise might get no pkts through.

 

 

 

=00 ------_=_NextPart_001_01C71EC7.26F5C177-- --===============0214770447== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============0214770447==-- From pcn-bounces@ietf.org Wed Dec 13 11:36:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuX62-0006rK-OY; Wed, 13 Dec 2006 11:36:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuX61-0006rF-DB for pcn@ietf.org; Wed, 13 Dec 2006 11:36:41 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuX5z-00074T-T2 for pcn@ietf.org; Wed, 13 Dec 2006 11:36:41 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Dec 2006 08:36:40 -0800 X-IronPort-AV: i="4.12,164,1165219200"; d="scan'208"; a="48526145:sNHT59851436" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBDGadcb020580; Wed, 13 Dec 2006 11:36:39 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBDGadDO025448; Wed, 13 Dec 2006 11:36:39 -0500 (EST) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 11:36:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] comments on single marking draft Date: Wed, 13 Dec 2006 11:36:37 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] comments on single marking draft Thread-Index: AccexyaTBlhK3y8XQeWPUER0mhigGwAA+3mQ From: "Anna Charny \(acharny\)" To: , X-OriginalArrivalTime: 13 Dec 2006 16:36:39.0259 (UTC) FILETIME=[DCF98AB0:01C71ED4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8962; t=1166027799; x=1166891799; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20\(acharny\)=22=20 |Subject:=20RE=3A=20[PCN]=20comments=20on=20single=20marking=20draft |Sender:=20 |To:=20,=20; bh=5FKQ9cOQ9Rk2IQiWJkEDoDPVM+2Wf/09mtKTdTbim5c=; b=IrP3lVTMRBKR7ZdYb5hjQJcZzV1h3g6dJgnopC0CfHPWrsFmYrLrv9okHQsvFMnZyM0uRjDa Ya/57zOxq+yuZ+7/XAGi/ZqXClzdjhObtR+5AkZ6tHS9zMCSA3Tzggjh; Authentication-Results: rtp-dkim-2; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: "Xinyang \(Joy\) Zhang" X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Phil, =20 Thanks for the thoughtful comments. A few responses below: ________________________________ > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 > Sent: Wednesday, December 13, 2006 9:59 AM > To: pcn@ietf.org > Subject: [PCN] comments on single marking draft > Anna, all, > Here at last are some comments on your single marking idea as described in http://ietf.org/internet-drafts/draft-charny-pcn-single-marking-00.txt > The flow pre-emption mechanism is essentially the same as in the Briscoe drafts, so they should behave the same.=20 >The comments below are all for admission control. =20 > The draft is very interesting, due to its two big advantages, as you point out: > - only need a single pkt encoding, easier to stdise > - only need a single measurement operation at routers [so simpler, faster] & this a measurement they do anyway=20 >[easier router upgrade] =20 > in your simulations, you analyse the probability of "false accepts" ie accept calls when the network state really=20 > means should be rejected. From your simulations, it seems this is probably OK, although it's harder to choose the=20 > parameters that make it work (harder than for the Briscoe i-d).=20 > * Reaction time: > An important potential drawback is how quickly it reacts to changes in load, especially if the load suddenly=20 > increases above the configured-admission-rate how =20 > quickly does the mechanism ensure that new calls are rejected. This is worse for the token bucket algorithm compared=20 > with the virtual queue - because the latter moves rapidly from marking 0% to 100% of packets as the load increases,=20 > whilst the former only marks the excess rate.=20 >Also, a smaller ewma 'weight' means that the egress effectively averages over a longer time. Unfortunately, for the video >scenario Table A4 suggests you need to use a small ewma weight. =20 > It would be nice to get a handle on how significant this problem is. =20 Yes, indeed the reaction time is slower. It seems to me that from the practical standpoint slower reaction time may in principle be bad because it may result in overshoot when the load grows rapidly and undershoot when it drops. However, we did not really see much of either in the simulations (see below on comments regarding undershoot). In fact I believe that is the moderate overshoot we see in the simulation is exactly because of the slower reaction time. However, it should be pointed that the simulations assumed benign poisson arrivals. One of the things to do for the future is to investigate how bad it can become if arrivals are much burstier. We saw in earlier simulations that virtual queue is relatively tolerant to a moderate increase in burstiness of arrivals - so you are right we need to look at burtier arrivals here as well. >ewma 'weight':- > >ewma_new =3D weight * new_measurement + (1-weight)*ewma_old >calculated/measured every 100ms interval according to > http://www.ietf.org/internet-drafts/draft-zhang-pcn-performance-evaluati on-00.txt=20 >so a weight of 0.1 is very roughly smoothing over about 1sec & weight of 0.9 smoothing over roughly 0.1sec. >I'd imagined the smoothing was over a shorter time period. I think you are saying you would prefer a smaller measurement interval than 100ms? (once the interval is chosen ewma sensitivity is presented in th edraft). The 100ms was chosen to make the load on the egress device manageable if there are lots of ingresses. I guess the question boils down to how bad over/under admission is with these parameters. So far we think it is OK. But indeed burstier arrivals and in general more beating up on the simulation would help. We do plan to do more of that. >* False rejects: >One danger (which I don't think you considered) is that new call request(s) may be rejected when they actually should be >accepted, because the measured-ewma (=3DCLE) is greater than the CLE_threshold whereas the actual-ewma is smaller. In=20 >general, an operator won't like false rejects (=3D money). We actually did consider the false rejects (undersoot) by looking what happens when the offered load is below the admission thresold (specifically we looked at 0.95 and 1 load (although we showed only 0.95 load in the draft, I think). We were looking specifically to see if we will see any significant false rejects (which would result in under-admission).=20 It did appear that for the simulation we did underadmission was quite small (see negative "over-admission" numbers reflecting the under-udmission in the draft). But again we would like to do more to see if we see more underadmission for more abrupt traffic changes. >It's quite hard to know how to assess this problem. Say you set CLE-threshold to 5% - there'll be times when you measure >CLE as 5.01% (& reject) when really it's 4.99% - however, the actual traffic level is pretty much at your design level, >so this error doesn't feel too important to me. However, if your CLE-threshold is 0.01% my instinct is that there's a=20 >much higher chance of falsely rejecting a call when the actual traffic level is still quite a way below your design=20 >level.Unfortunately, for the video scenario Table A4 suggests you need to use a small CLE-threshold. See above. Specific suggestions on setups that you feel might show the problem you are concerned about are very welcome. One thing to remember here is that "video" we used in our simulations is not really video - it is on-ff CBR with long on and off periods (330 ms and 660 ms respectively). With a releatively small number of these "video" flows considered, one would expect the aggregate traffic to still be rather abruptly changing. Further, as we had only one or very few of these "video" flows per ngress-egrees pair, the ingress measurements are really challenging as 100 ms measurements really oscillate between 0 and peak rate most of the time. We had always felt that this kind of "video" represents a "lower bound" on the actual video behavior (that is, we felt that if performance is OK with this, it should be better with real video. One of the things we are trying to do right now is to implement more realistic video models. Will see if our intuition is confirmed then. >* Inter-domain case >you use a system-wide constant u, the assumed ratio between pre-emption and admission thresholds for all links in the=20 >PCN-region.=20 >The thought is that the PCN-region can gradually be extended to cover multiple domains. But each might be using different >values for u - so inter-domain operations might be hampered. This needs more thought.=20 I believe you are saying that when two PCN domains merge, then a virtual queue approach allows the operator to considerthe two omains as a single domain, while for the single marking approach the choice is either to mandate the same u in nboth or keep the boundary. I think that is true, and is certainly a tradeoff to consider. One question here is whether an operator who wants to merge two domains would really feel that mandating the same u is a limiting factor? =20 >* Other comments: > >- it would be nice if the simulations could be re-run for multiple videos per ingress-egress-aggregate - to check that=20 >the deduction is correct that "we believe that the severe degradation of performance in this topology is directly=20 >attributable to the lack of traffic aggregation on the ingress-egress pair basis." I believe we actually did that - the "single bottleneck topology" with video corresponds to the same bottleneck capacity but all video flows sharing the same ingress-egreess pair. Will doublecheck... >- in the simulations, could you check whether the probability of accepting a call request on a *particular* ingresss- >egress-aggregate is biased by the RTT=20 I will double-check, but I believe the answer we arrived at was "no" (in the experiments we tried) - in that the RTT had no effect in the distribution of admitted flows among the ingresses. We should reflect this more clearly in the next revision of the draft. >- your assumptions in the simulations seemed ok to me: > - single bottleneck - if there are multiple bottlenecks, would expect the method still to be ok - the marking %s combine as required.=20 We will check that - we finally got to the multiple bottleneck case, but started with preemption first, as it is relevant to both approaches. >- No packet loss - if there was packet loss, would expect method still to be ok, as would expect all packets getting through the overloaded router to be marked. NB must not preferentially drop marked packets, otherwise might get no pkts through. Still to be thought through further, but for the moment seemed like a reasonable initial assumption. =20 Best, Anna=20 =20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Dec 18 08:34:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwIdp-0008OV-FD; Mon, 18 Dec 2006 08:34:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwIdo-0008OQ-It for pcn@ietf.org; Mon, 18 Dec 2006 08:34:52 -0500 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwIdm-0004nY-2b for pcn@ietf.org; Mon, 18 Dec 2006 08:34:52 -0500 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 1656E411D for ; Mon, 18 Dec 2006 14:34:45 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 07A2C4118 for ; Mon, 18 Dec 2006 14:34:45 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id C9E7540D0 for ; Mon, 18 Dec 2006 14:34:44 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id kBIDYis20537 for ; Mon, 18 Dec 2006 14:34:44 +0100 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 9A1166F58E for ; Mon, 18 Dec 2006 14:32:15 +0100 (CET) Message-ID: <4586983A.1040407@informatik.uni-wuerzburg.de> Date: Mon, 18 Dec 2006 14:31:38 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: pcn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [PCN] Comments on draft-babiarz-pcn-sip-cap-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Joe et al. I've browsed again through the draft http://www.ietf.org/internet-drafts/draft-babiarz-pcn-sip-cap-00.txt Many aspects in this draft like probing etc. are of general nature regarding PCN and are not SIP-specific. This hides the SIP-specific problems. Probing is certainly a good thing to do to avoid flash crowds and ECMP problems, but the IntServ over DiffServ model would equally benefit from probing. Regarding the interaction between SIP and the PCN architecture I see two possible options (maybe mixed approaches are also possible): 1) SIP uses PCN admission and preemption provided by the ingress nodes of the PCN domain. 2) PCN border nodes only provide probing and measurement and send the raw measurement data to the SIP proxy which takes the admission and preemption decisions. I think 2) is favored in the draft. However, I still miss the full picture: which entity does what and communicates what to which other entity? Some comments to both approaches: ad 1) SIP uses PCN * The PCN ingress selects the flows being preempted which is unaware of session structures. (-) * SIP contacts the PCN ingress like any other flow would do and waits for an answer. Therefore, this approach can coexist with RSVP and other signaling schemes as PCN border routers control the resources of the network. (+) * No single point of failure (+) ad 2) SIP implements PCN * SIP triggers PCN border routers and receives information from them. Based on this information, admission and preemption decisions are made. Details are not clear to me yet. (o) * SIP selects the flows being preempted: correlated streams may be preempted together, e.g., voice and video of application X instead of voice of X and video of Y. (+) * SIP control makes coexistence with other resources control paradigms difficult (-) * SIP control is single point of failure like a bandwidth broker (-) Best regards, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Dec 18 10:16:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwKEb-0001wQ-5u; Mon, 18 Dec 2006 10:16:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwKEZ-0001wD-A7 for pcn@ietf.org; Mon, 18 Dec 2006 10:16:55 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwKEU-0006Q2-SE for pcn@ietf.org; Mon, 18 Dec 2006 10:16:55 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 15448644 for ; Mon, 18 Dec 2006 15:48:03 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 15:48:02 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 15:48:02 +0100 Message-ID: <4586AA22.9040907@ericsson.com> Date: Mon, 18 Dec 2006 15:48:02 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: pcn@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Dec 2006 14:48:02.0820 (UTC) FILETIME=[84F09C40:01C722B3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [PCN] Alternatives to Preemption X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi, So far the discussion has been quite focused on preemption when the resources gets overtaxed. Aren't there some cases when the alternative to preemption would be to indicate to the flows that they may only use less resources? This could happen by having the QoS mechanism engage in re-negotiation. For example in cases when large parts of the traffic is voice, then one could change the encoding or change codec mode to reduce the rate. Isn't most operator more in favor of reduced quality, rather than dropped calls? To be clear, this is a subject I would like to have some opinion from the group on to see if it is important to consider in the development. However I don't see how it would be in the first phase of a PCN WG other than as a constraint. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Dec 18 11:36:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwLTh-0007wH-Jl; Mon, 18 Dec 2006 11:36:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwLTg-0007uG-4Q for pcn@ietf.org; Mon, 18 Dec 2006 11:36:36 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwLTe-0005I5-MJ for pcn@ietf.org; Mon, 18 Dec 2006 11:36:36 -0500 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Mon, 18 Dec 2006 17:34:14 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 17:34:13 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: [PCN] Off list: Comments on re ecn border cheat Date: Mon, 18 Dec 2006 17:34:10 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFA2F@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <4586983A.1040407@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [PCN] Comments on draft-babiarz-pcn-sip-cap-00.txt thread-index: AcciqpIX1Pxp7dx2TVmkI3SmBAg2ogAB9LYQ From: "Geib, Ruediger" To: X-OriginalArrivalTime: 18 Dec 2006 16:34:13.0714 (UTC) FILETIME=[5A49E320:01C722C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Bob, although border cheating isn't part of the currently=20 discussed pcn charter, I prefer to communicate my=20 comments using this mail exploder. I'm happy to=20 continue this discussion privately, should others=20 feel this to be preferable. You propose a mechanism allowing to identify ingress=20 gateways to a PCN region ignoring feedback on ECN=20 marked packets which was given them. Your=20 argumentation is that intermediate transit networks=20 providing bulk CL transport must have a way to=20 ensure "fair use of resources" while maintaining the=20 agreed CL service level. You are right in your conclusion on the required=20 ability of a transit network to monitor the behaviour=20 of traffic sinks after pre congestion notifcation=20 occurred within this transit network, I think. While=20 I think, that the mechanism you propose is smart and=20 may work, I'm not sure, whether the accounting=20 mechanism surrounding it should or could be=20 standardised by IETF. I'd prefer not to enter a detailed discussion on=20 the usefulness of your proposed solution. Instead,=20 I'd like to list a couple of thoughts coming to=20 my mind: - The egress gateway feeds back the PCN information=20 to the ingress gateway. It could at least monitor=20 RSVP signaling after PCN feedback has been given=20 by it.=20 If it expects PATH messages after PCN feedback=20 to be followed by PathErr sent from the ingress=20 and receives refreshes instead, a cheat is easily=20 identified. But that is obviously of no help, if=20 the traffic contract of an admitted reservation=20 isn't kept. - Ingress/Egress gateway per flow policing probably=20 is the only way to ensure correct behaviour of=20 sources (and avoid cheats on consumed bandwidths). - The transit networks sell a bulk service. They=20 aren't aware of any per flow events and don't=20 care as long as the CL/PCN service operates=20 properly. - The transit provider charges for CL traffic=20 volumes and provides an SLA on two things: * CL performance (close to loss free) * Probability to cause ECN marks to be set on=20 an internal bottleneck (let's call it a "network=20 busy indication", should have a low probability). - Per transit domain (ingress-egress?) aggregate=20 PCN and CL reports may have to be produced anyway. They prove who has contributed to a network busy=20 situation in a chain of networks for ECN marks.=20 For CL traffic, they prove loss free operation. - The downstream egress (gateway) can't determine=20 where and by which network an ECN mark has been=20 set. I'd expect the egress border routers/gateways=20 noticing ECN marked traffic not to have an interest=20 in cheating as they could hit own customers. - The ingress can only cheat on a secure basis, if=20 it can be sure that it isn't the own network=20 producing the ECN marks. This assumes some form of ECN feedback from its border router (assuming the=20 ingress gateway to be part of a domain, not a=20 single service production point). - The hard part seems to be to identify and trace=20 back a cheater in the case of a chain of transit=20 networks and pre congestions marks set by a=20 downstream network are ignored by an upstream=20 ingress gateway. But that assumes that the ingress=20 operator knows that congestion isn't occuring close=20 to him and probaly also requires the egress gateway=20 to cooperate. To sum up, I'd prefer a deeper analysis of the scenarios=20 and architectures around cheating before discussing=20 solutions. I've read the March version of your draft - after a brief=20 glance on the June version. I still think they mostly=20 represent my thoughts on your input.=20 Regards, R=FCdiger _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Dec 18 12:11:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwM1Q-00058Z-OC; Mon, 18 Dec 2006 12:11:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwM1P-00058O-SY for pcn@ietf.org; Mon, 18 Dec 2006 12:11:27 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwM1N-0003un-B2 for pcn@ietf.org; Mon, 18 Dec 2006 12:11:27 -0500 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kBIHBMt20053; Mon, 18 Dec 2006 12:11:23 -0500 (EST) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 12:11:09 -0500 Message-Id: <6.2.5.6.0.20061218114225.03c87678@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 18 Dec 2006 12:11:09 -0500 To: menth@informatik.uni-wuerzburg.de From: "Kwok-Ho Chan" Subject: Re: [PCN] Comments on draft-babiarz-pcn-sip-cap-00.txt In-Reply-To: <4586983A.1040407@informatik.uni-wuerzburg.de> References: <4586983A.1040407@informatik.uni-wuerzburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 18 Dec 2006 17:11:10.0006 (UTC) FILETIME=[834D3560:01C722C7] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Michael: Thank you very much for your comments. We are currently working on the next version of this draft based on the feedback we received during the BOF in San Diego. Please see below for initial response to your comments. -- Kwok -- At 08:31 AM 12/18/2006, Michael Menth wrote: >Hi Joe et al. > >I've browsed again through the draft >http://www.ietf.org/internet-drafts/draft-babiarz-pcn-sip-cap-00.txt >Many aspects in this draft like probing etc. are of general nature >regarding PCN and are not SIP-specific. This hides the SIP-specific >problems. Probing is certainly a good thing to do to avoid flash >crowds and ECMP problems, but the IntServ over DiffServ model would >equally benefit from probing. Some of the work here may be applicable to more than just this Deployment Model, but possibly with different degree of importance. Hence these topics may need to be explored in general. My personal view point is there are more commonalities then differences between the current two deployment models, hence my recommendations to have both of them in the first phase charter of PCN. >Regarding the interaction between SIP and the PCN architecture I see >two possible options (maybe mixed approaches are also possible): >1) SIP uses PCN admission and preemption provided by the ingress >nodes of the PCN domain. >2) PCN border nodes only provide probing and measurement and send >the raw measurement data to the SIP proxy which takes the admission >and preemption decisions. > >I think 2) is favored in the draft. However, I still miss the full >picture: which entity does what and communicates what to which other entity? I think this should be better clarify in the next version of the draft. We are planning to have a more top down approach with the next version and possible defer some of the details. Hopefully the next version can better clarify the full picture. >Some comments to both approaches: > >ad 1) SIP uses PCN >* The PCN ingress selects the flows being preempted which is unaware >of session structures. (-) >* SIP contacts the PCN ingress like any other flow would do and >waits for an answer. Therefore, this approach can coexist with RSVP >and other signaling schemes as PCN border routers control the >resources of the network. (+) >* No single point of failure (+) For a real solution, no matter what signaling protocol is used, the source of the packets should stop sending the packets that contribute to the perceived congestion. Hence even in the RSVP as signaling protocol in the middle of the network deployment model, the sender of the traffic needs to be notified. It is just in the SIP-CAP deployment model, we are more specific on this point. And in this approach you indicated, there are room for inter-operability. Hence we want to have the PCN mechanism we are standardizing in the first phase charter to be applicable to both deployment models. And I believe this should be a goal. >ad 2) SIP implements PCN >* SIP triggers PCN border routers and receives information from >them. Based on this information, admission and preemption decisions >are made. Details are not clear to me yet. (o) >* SIP selects the flows being preempted: correlated streams may be >preempted together, e.g., voice and video of application X instead >of voice of X and video of Y. (+) >* SIP control makes coexistence with other resources control >paradigms difficult (-) >* SIP control is single point of failure like a bandwidth broker (-) Thanks for your comments, I think with clearer description in the next version of the draft, you may see more (+)s. We will keep your comments in mind to make sure we address them. And will provide you with more detailed response using contents of the new version of the draft. >Best regards, > > Michael > >-- >Dr. Michael Menth, Assistant Professor >University of Wuerzburg, Institute of Computer Science >Am Hubland, D-97074 Wuerzburg, Germany, room B206 >phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 >mailto:menth@informatik.uni-wuerzburg.de >http://www3.informatik.uni-wuerzburg.de/research/ngn > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Dec 18 12:59:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwMmB-0001mB-Tq; Mon, 18 Dec 2006 12:59:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwMmB-0001kQ-2J for pcn@ietf.org; Mon, 18 Dec 2006 12:59:47 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwMm8-0002bP-Ns for pcn@ietf.org; Mon, 18 Dec 2006 12:59:47 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Dec 2006 12:59:44 -0500 X-IronPort-AV: i="4.12,185,1165208400"; d="scan'208"; a="109769862:sNHT53490464" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBIHxiQt005746; Mon, 18 Dec 2006 12:59:44 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBIHxew2017428; Mon, 18 Dec 2006 12:59:44 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 12:59:42 -0500 Received: from jmpolk-wxp.cisco.com ([10.89.16.81]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 12:59:42 -0500 Message-Id: <4.3.2.7.2.20061218115736.030ed470@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Dec 2006 11:59:41 -0600 To: Magnus Westerlund , pcn@ietf.org From: "James M. Polk" Subject: Re: [PCN] Alternatives to Preemption In-Reply-To: <4586AA22.9040907@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 18 Dec 2006 17:59:42.0466 (UTC) FILETIME=[4B435620:01C722CE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1293; t=1166464784; x=1167328784; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[PCN]=20Alternatives=20to=20Preemption |Sender:=20 |To:=20Magnus=20Westerlund=20, =20pcn@ietf .org; bh=IB8VLodGg/AE+f/mE74HTS/XCoHvB5QxI741HVOumhA=; b=g1m1v1URwmI9MhI+bhiAbOEKHgnr9iFxwl/tM0u6fVsJYJADCuFG7B70crf6rPygQ15GLzsW 7pIx8pPYaY8kpkjuhpUcHXVlmQVre5Fky0ne1Jk3CR8xeawZiC0Hw32I; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org At 03:48 PM 12/18/2006 +0100, Magnus Westerlund wrote: >Hi, > >So far the discussion has been quite focused on preemption when the >resources gets overtaxed. Aren't there some cases when the alternative to >preemption would be to indicate to the flows that they may only use less >resources? This could happen by having the QoS mechanism engage in >re-negotiation. > >For example in cases when large parts of the traffic is voice, then one >could change the encoding or change codec mode to reduce the rate. Magnus What would a feedback (back to a calling party phone, for example) look like in this context? >Cheers > >Magnus Westerlund > >IETF Transport Area Director & TSVWG Chair >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVA/A >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Dec 18 13:12:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwMyT-0006aT-LG; Mon, 18 Dec 2006 13:12:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwMyR-0006ZT-6Z for pcn@ietf.org; Mon, 18 Dec 2006 13:12:27 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwMyN-0004NE-9V for pcn@ietf.org; Mon, 18 Dec 2006 13:12:27 -0500 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 18:12:17 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Dec 2006 18:12:17 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1166465535955; Mon, 18 Dec 2006 18:12:15 +0000 Received: from mut.jungle.bt.co.uk ([10.215.130.159]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id kBIICCED004206; Mon, 18 Dec 2006 18:12:14 GMT Message-Id: <5.2.1.1.2.20061218180339.0476f218@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 18 Dec 2006 18:12:17 +0000 To: "Geib, Ruediger" From: Bob Briscoe Subject: Re: [PCN] Off list: Comments on re ecn border cheat In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBFA2F@S4DE8PSAAFQ.mitte.t -com.de> References: <4586983A.1040407@informatik.uni-wuerzburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.201 () ALL_TRUSTED,MIME_QP_LONG_LINE X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 18 Dec 2006 18:12:17.0340 (UTC) FILETIME=[0D33F7C0:01C722D0] X-Spam-Score: 0.1 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org R=FCdiger, Just about to take a day off (xmas shopping). Will respond when I return. Regarding whether this should be on or off list, I think the general=20 sentiment at the PCN BoF was that inter-domain should be held strongly in=20 mind while focusing first on intra-domain (reflected in the new wording in= =20 the proposed charter). So, given the border-cheating draft is currently one= =20 of the only ways to both keep good scalability and go inter-domain, it is=20 certainly worth discussing whether it is a meaningful approach for going=20 inter-domain, and whether it involves anything standardisable anyway=20 (you'll notice my intent was for this draft to be informational, but there= =20 may be some standardisable elements). If it's not an acceptable approach, then we need to be looking for other=20 solutions. Because if we can't see how to take the last steps, interest in= =20 taking the first steps towards PCN will be lessened. I'll leave others to argue if they don't think this discussion belongs on=20 the list. More in a couple of days. Bob At 16:34 18/12/2006, Geib, Ruediger wrote: >Hi Bob, > >although border cheating isn't part of the currently >discussed pcn charter, I prefer to communicate my >comments using this mail exploder. I'm happy to >continue this discussion privately, should others >feel this to be preferable. > >You propose a mechanism allowing to identify ingress >gateways to a PCN region ignoring feedback on ECN >marked packets which was given them. Your >argumentation is that intermediate transit networks >providing bulk CL transport must have a way to >ensure "fair use of resources" while maintaining the >agreed CL service level. > >You are right in your conclusion on the required >ability of a transit network to monitor the behaviour >of traffic sinks after pre congestion notifcation >occurred within this transit network, I think. While >I think, that the mechanism you propose is smart and >may work, I'm not sure, whether the accounting >mechanism surrounding it should or could be >standardised by IETF. > >I'd prefer not to enter a detailed discussion on >the usefulness of your proposed solution. Instead, >I'd like to list a couple of thoughts coming to >my mind: > >- The egress gateway feeds back the PCN information > to the ingress gateway. It could at least monitor > RSVP signaling after PCN feedback has been given > by it. > If it expects PATH messages after PCN feedback > to be followed by PathErr sent from the ingress > and receives refreshes instead, a cheat is easily > identified. But that is obviously of no help, if > the traffic contract of an admitted reservation > isn't kept. > >- Ingress/Egress gateway per flow policing probably > is the only way to ensure correct behaviour of > sources (and avoid cheats on consumed bandwidths). > >- The transit networks sell a bulk service. They > aren't aware of any per flow events and don't > care as long as the CL/PCN service operates > properly. > >- The transit provider charges for CL traffic > volumes and provides an SLA on two things: > * CL performance (close to loss free) > * Probability to cause ECN marks to be set on > an internal bottleneck (let's call it a "network > busy indication", should have a low probability). > >- Per transit domain (ingress-egress?) aggregate > PCN and CL reports may have to be produced anyway. > They prove who has contributed to a network busy > situation in a chain of networks for ECN marks. > For CL traffic, they prove loss free operation. > >- The downstream egress (gateway) can't determine > where and by which network an ECN mark has been > set. I'd expect the egress border routers/gateways > noticing ECN marked traffic not to have an interest > in cheating as they could hit own customers. > >- The ingress can only cheat on a secure basis, if > it can be sure that it isn't the own network > producing the ECN marks. This assumes some form of > ECN feedback from its border router (assuming the > ingress gateway to be part of a domain, not a > single service production point). > >- The hard part seems to be to identify and trace > back a cheater in the case of a chain of transit > networks and pre congestions marks set by a > downstream network are ignored by an upstream > ingress gateway. But that assumes that the ingress > operator knows that congestion isn't occuring close > to him and probaly also requires the egress gateway > to cooperate. > >To sum up, I'd prefer a deeper analysis of the scenarios >and architectures around cheating before discussing >solutions. > >I've read the March version of your draft - after a brief >glance on the June version. I still think they mostly >represent my thoughts on your input. > >Regards, > >R=FCdiger > > > > > > > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not=20 necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196= =20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Dec 18 13:54:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwNda-00070Z-1V; Mon, 18 Dec 2006 13:54:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwNdY-00070R-Nx for pcn@ietf.org; Mon, 18 Dec 2006 13:54:56 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwNdX-0002Iq-Cs for pcn@ietf.org; Mon, 18 Dec 2006 13:54:56 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kBIIlW501285; Mon, 18 Dec 2006 13:47:33 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Alternatives to Preemption Date: Mon, 18 Dec 2006 13:54:47 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650DCA086F@zcarhxm1.corp.nortel.com> In-Reply-To: <4586AA22.9040907@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Alternatives to Preemption Thread-Index: Accit6MsfM23JHb1R+y0u15Ob+5XGwAFzHvw From: "Jozef Babiarz" To: "Magnus Westerlund" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Yes, changing of codec to a lower rate on the detection of onset of congestion is an option that needs to be supported. However, the changing of codecs only is possible if both endpoints have this capability so not all flows will respond. Yes, I'm interested in working on this problem in later phase of the PCN work. Regards, Joe Email: babiarz@nortel.com -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Monday, December 18, 2006 9:48 AM To: pcn@ietf.org Subject: [PCN] Alternatives to Preemption Hi, So far the discussion has been quite focused on preemption when the=20 resources gets overtaxed. Aren't there some cases when the alternative=20 to preemption would be to indicate to the flows that they may only use=20 less resources? This could happen by having the QoS mechanism engage in=20 re-negotiation. For example in cases when large parts of the traffic is voice, then one=20 could change the encoding or change codec mode to reduce the rate. Isn't most operator more in favor of reduced quality, rather than dropped calls? To be clear, this is a subject I would like to have some opinion from=20 the group on to see if it is important to consider in the development.=20 However I don't see how it would be in the first phase of a PCN WG other than as a constraint. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Dec 18 14:15:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwNxD-0006h2-Hr; Mon, 18 Dec 2006 14:15:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwNxC-0006gr-3i for pcn@ietf.org; Mon, 18 Dec 2006 14:15:14 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwNx9-00064J-Qy for pcn@ietf.org; Mon, 18 Dec 2006 14:15:14 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kBIJF7u25267; Mon, 18 Dec 2006 14:15:08 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Alternatives to Preemption Date: Mon, 18 Dec 2006 14:15:06 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650DCA08F9@zcarhxm1.corp.nortel.com> In-Reply-To: <4.3.2.7.2.20061218115736.030ed470@email.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Alternatives to Preemption Thread-Index: AccizmDC+dBLNLSDSYGXpoYmZdULRwACMo0w From: "Jozef Babiarz" To: "James M. Polk" , "Magnus Westerlund" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org James one possible way that this could work is that during session setup, two codecs are negotiated in the SDP offer message, the first being high quality higher rate codec and the second a lower rate codec. When onset of congestion is detected, the PCN marking triggers the endpoints to switch to lower rate codec. The receiver of the RTP steam (phone) needs to signal to the sender possible using RTCP the codec change request.=20 Regards, Joe Email: babiarz@nortel.com -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com]=20 Sent: Monday, December 18, 2006 1:00 PM To: Magnus Westerlund; pcn@ietf.org Subject: Re: [PCN] Alternatives to Preemption At 03:48 PM 12/18/2006 +0100, Magnus Westerlund wrote: >Hi, > >So far the discussion has been quite focused on preemption when the=20 >resources gets overtaxed. Aren't there some cases when the alternative to=20 >preemption would be to indicate to the flows that they may only use less=20 >resources? This could happen by having the QoS mechanism engage in=20 >re-negotiation. > >For example in cases when large parts of the traffic is voice, then one >could change the encoding or change codec mode to reduce the rate. Magnus What would a feedback (back to a calling party phone, for example) look=20 like in this context? >Cheers > >Magnus Westerlund > >IETF Transport Area Director & TSVWG Chair >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVA/A >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Dec 18 16:07:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwPiA-00069A-Cj; Mon, 18 Dec 2006 16:07:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwPi8-00068o-Ey for pcn@ietf.org; Mon, 18 Dec 2006 16:07:48 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwPi6-0008To-Th for pcn@ietf.org; Mon, 18 Dec 2006 16:07:48 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 18 Dec 2006 13:07:46 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id kBIL7iDM004813; Mon, 18 Dec 2006 13:07:44 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kBIL7eSh012314; Mon, 18 Dec 2006 13:07:43 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 16:07:36 -0500 Received: from jmpolk-wxp.cisco.com ([10.89.16.81]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 16:07:35 -0500 Message-Id: <4.3.2.7.2.20061218150159.02f5fbe8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Dec 2006 15:07:34 -0600 To: "Jozef Babiarz" , "Magnus Westerlund" , From: "James M. Polk" Subject: RE: [PCN] Alternatives to Preemption In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650DCA08F9@zcarhxm1.corp.nor tel.com> References: <4.3.2.7.2.20061218115736.030ed470@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 18 Dec 2006 21:07:35.0660 (UTC) FILETIME=[8A9C3AC0:01C722E8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3078; t=1166476064; x=1167340064; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[PCN]=20Alternatives=20to=20Preemption |Sender:=20; bh=0r35VUET0US52BbcozkTMFikWpQZo+1iXASweErCCV8=; b=mQwwufPLb7UpraMPWca9TpIYkVRuD9gFt3cPTSONFUtqDDxOT8Cf76bg8oH3ZKiDjfSfBk98 oLiH+eYC0oAu+sJPuSX6OGdRwZrzLZFbPhJIqOBLwF2U5trdboP/YWkx; Authentication-Results: sj-dkim-6; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Jozef This is an interesting way of doing a solution, however, I do not see what type of message is sent by the core edge to the actual phone to tell it to do anything. SIP messaging (with SDP inside) can and probably does take an entirely different path to set up the call than the RTP media packets take, therefore - something needs to be on the RTP path giving feedback. This could be RTCP, but is that sent by the core edge router? I don't believe so (unless this node is also an SBC). Therefore, what does send this message and what could it be in the form of? I'm wondering if Magnus is assuming the ingress and egress of bidirectional RTP pcakets traverse the same core edge router? I'm not looking for a solution as much as I'm looking for what people might be thinking a solution could look like. At 02:15 PM 12/18/2006 -0500, Jozef Babiarz wrote: >James one possible way that this could work is that during session >setup, two codecs are negotiated in the SDP offer message, the first >being high quality higher rate codec and the second a lower rate codec. >When onset of congestion is detected, the PCN marking triggers the >endpoints to switch to lower rate codec. The receiver of the RTP steam >(phone) needs to signal to the sender possible using RTCP the codec >change request. > >Regards, Joe >Email: babiarz@nortel.com > >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: Monday, December 18, 2006 1:00 PM >To: Magnus Westerlund; pcn@ietf.org >Subject: Re: [PCN] Alternatives to Preemption > >At 03:48 PM 12/18/2006 +0100, Magnus Westerlund wrote: > >Hi, > > > >So far the discussion has been quite focused on preemption when the > >resources gets overtaxed. Aren't there some cases when the alternative >to > >preemption would be to indicate to the flows that they may only use >less > >resources? This could happen by having the QoS mechanism engage in > >re-negotiation. > > > >For example in cases when large parts of the traffic is voice, then one > > >could change the encoding or change codec mode to reduce the rate. > >Magnus > >What would a feedback (back to a calling party phone, for example) look >like in this context? > > >Cheers > > > >Magnus Westerlund > > > >IETF Transport Area Director & TSVWG Chair > >---------------------------------------------------------------------- > >Multimedia Technologies, Ericsson Research EAB/TVA/A > >---------------------------------------------------------------------- > >Ericsson AB | Phone +46 8 4048287 > >Torshamsgatan 23 | Fax +46 8 7575550 > >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > >---------------------------------------------------------------------- > > > >_______________________________________________ > >PCN mailing list > >PCN@ietf.org > >https://www1.ietf.org/mailman/listinfo/pcn > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Dec 19 02:51:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwZkp-0003Ca-BY; Tue, 19 Dec 2006 02:51:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwZkn-00039L-Kg for pcn@ietf.org; Tue, 19 Dec 2006 02:51:13 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwZkm-00066i-4l for pcn@ietf.org; Tue, 19 Dec 2006 02:51:13 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 19 Dec 2006 08:47:57 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Dec 2006 08:47:57 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [PCN] Alternatives to Preemption Date: Tue, 19 Dec 2006 08:47:56 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFA30@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <4.3.2.7.2.20061218150159.02f5fbe8@email.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [PCN] Alternatives to Preemption thread-index: Acci6Jp+Xbe1fnHISjColW0IZA8GOAAVueJw From: "Geib, Ruediger" To: X-OriginalArrivalTime: 19 Dec 2006 07:47:57.0535 (UTC) FILETIME=[FFD516F0:01C72341] X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org James, in general I think there are two possibilities: You mentioned an edge element which somehow is able to inform=20 the SIP proxy (or RSVP edge router) controlling a session=20 that it received congestion/preemption marked packets related=20 to this session. The other option is to forward PCN or DSCP marked media packets=20 to the end system and inform it that way. RTCP could be adapted=20 to report congestion marked packets. But also the receivers=20 SIP stack could be adapted to interpret these packets and=20 then start to re-negotiate codecs. The general aim of codec adaptation in the case of congestion=20 seems useful to me and I think PCN should work on it once the=20 basic PCN mechanisms are specified. Regards, Rudiger |-----Original Message----- |From: James M. Polk [mailto:jmpolk@cisco.com] |Sent: Monday, December 18, 2006 10:08 PM |To: Jozef Babiarz; Magnus Westerlund; pcn@ietf.org |Subject: RE: [PCN] Alternatives to Preemption | | |Jozef | |This is an interesting way of doing a solution, however, I do=20 |not see what=20 |type of message is sent by the core edge to the actual phone=20 |to tell it to=20 |do anything. SIP messaging (with SDP inside) can and probably=20 |does take an=20 |entirely different path to set up the call than the RTP media=20 |packets take,=20 |therefore - something needs to be on the RTP path giving=20 |feedback. This=20 |could be RTCP, but is that sent by the core edge router? I=20 |don't believe so=20 |(unless this node is also an SBC). Therefore, what does send=20 |this message=20 |and what could it be in the form of? | |I'm wondering if Magnus is assuming the ingress and egress of=20 |bidirectional=20 |RTP pcakets traverse the same core edge router? | |I'm not looking for a solution as much as I'm looking for what=20 |people might=20 |be thinking a solution could look like. | |At 02:15 PM 12/18/2006 -0500, Jozef Babiarz wrote: |>James one possible way that this could work is that during session |>setup, two codecs are negotiated in the SDP offer message, the first |>being high quality higher rate codec and the second a lower=20 |rate codec. |>When onset of congestion is detected, the PCN marking triggers the |>endpoints to switch to lower rate codec. The receiver of the RTP steam |>(phone) needs to signal to the sender possible using RTCP the codec |>change request. |> |>Regards, Joe |>Email: babiarz@nortel.com |> |>-----Original Message----- |>From: James M. Polk [mailto:jmpolk@cisco.com] |>Sent: Monday, December 18, 2006 1:00 PM |>To: Magnus Westerlund; pcn@ietf.org |>Subject: Re: [PCN] Alternatives to Preemption |> |>At 03:48 PM 12/18/2006 +0100, Magnus Westerlund wrote: |> >Hi, |> > |> >So far the discussion has been quite focused on preemption when the |> >resources gets overtaxed. Aren't there some cases when the=20 |alternative |>to |> >preemption would be to indicate to the flows that they may only use |>less |> >resources? This could happen by having the QoS mechanism engage in |> >re-negotiation. |> > |> >For example in cases when large parts of the traffic is=20 |voice, then one |> |> >could change the encoding or change codec mode to reduce the rate. |> |>Magnus |> |>What would a feedback (back to a calling party phone, for=20 |example) look |>like in this context? |> |> >Cheers |> > |> >Magnus Westerlund |> > |> >IETF Transport Area Director & TSVWG Chair |>=20 |>---------------------------------------------------------------------- |> >Multimedia Technologies, Ericsson Research EAB/TVA/A |>=20 |>---------------------------------------------------------------------- |> >Ericsson AB | Phone +46 8 4048287 |> >Torshamsgatan 23 | Fax +46 8 7575550 |> >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com |>=20 |>---------------------------------------------------------------------- |> > |> >_______________________________________________ |> >PCN mailing list |> >PCN@ietf.org |> >https://www1.ietf.org/mailman/listinfo/pcn |> |>_______________________________________________ |>PCN mailing list |>PCN@ietf.org |>https://www1.ietf.org/mailman/listinfo/pcn | |_______________________________________________ |PCN mailing list |PCN@ietf.org |https://www1.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Dec 19 03:29:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwaM0-0005XQ-W4; Tue, 19 Dec 2006 03:29:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwaM0-0005XJ-78 for pcn@ietf.org; Tue, 19 Dec 2006 03:29:40 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwaLx-0006zW-PF for pcn@ietf.org; Tue, 19 Dec 2006 03:29:40 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id kBJ8TLd3020393; Tue, 19 Dec 2006 09:29:25 +0100 (MET) From: "Georgios Karagiannis" To: "'Jozef Babiarz'" , "'Magnus Westerlund'" , Subject: RE: [PCN] Alternatives to Preemption Date: Tue, 19 Dec 2006 09:29:24 +0100 Message-ID: <000901c72347$cdb0ba70$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Accit6MsfM23JHb1R+y0u15Ob+5XGwAFzHvwAB41b9A= In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650DCA086F@zcarhxm1.corp.nortel.com> X-Spam-Score: 0.107 () AWL X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 19 Dec 2006 09:29:25 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Magnus I am also interested in working on this problem and yes it should be considered as a constraint! Best Regards, Georgios > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com] > Sent: maandag 18 december 2006 19:55 > To: Magnus Westerlund; pcn@ietf.org > Subject: RE: [PCN] Alternatives to Preemption > > Yes, changing of codec to a lower rate on the detection of > onset of congestion is an option that needs to be supported. > However, the changing of codecs only is possible if both > endpoints have this capability so not all flows will respond. > Yes, I'm interested in working on this problem in later phase > of the PCN work. > > Regards, Joe > Email: babiarz@nortel.com > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Monday, December 18, 2006 9:48 AM > To: pcn@ietf.org > Subject: [PCN] Alternatives to Preemption > > Hi, > > So far the discussion has been quite focused on preemption > when the resources gets overtaxed. Aren't there some cases > when the alternative to preemption would be to indicate to > the flows that they may only use less resources? This could > happen by having the QoS mechanism engage in re-negotiation. > > For example in cases when large parts of the traffic is > voice, then one could change the encoding or change codec > mode to reduce the rate. Isn't > > most operator more in favor of reduced quality, rather than > dropped calls? > > To be clear, this is a subject I would like to have some > opinion from the group on to see if it is important to > consider in the development. > However I don't see how it would be in the first phase of a > PCN WG other > > than as a constraint. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Dec 19 04:04:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwato-0000NZ-Ef; Tue, 19 Dec 2006 04:04:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwatn-0000NU-It for pcn@ietf.org; Tue, 19 Dec 2006 04:04:35 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwatk-0006kU-Vx for pcn@ietf.org; Tue, 19 Dec 2006 04:04:35 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6E93812A2; Tue, 19 Dec 2006 10:04:30 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Dec 2006 10:04:30 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Dec 2006 10:04:30 +0100 Message-ID: <4587AB1D.8010101@ericsson.com> Date: Tue, 19 Dec 2006 10:04:29 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [PCN] Alternatives to Preemption References: <4.3.2.7.2.20061218115736.030ed470@email.cisco.com> In-Reply-To: <4.3.2.7.2.20061218115736.030ed470@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Dec 2006 09:04:30.0211 (UTC) FILETIME=[B147D530:01C7234C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org James M. Polk skrev: > At 03:48 PM 12/18/2006 +0100, Magnus Westerlund wrote: >> Hi, >> >> So far the discussion has been quite focused on preemption when the >> resources gets overtaxed. Aren't there some cases when the alternative >> to preemption would be to indicate to the flows that they may only use >> less resources? This could happen by having the QoS mechanism engage >> in re-negotiation. >> >> For example in cases when large parts of the traffic is voice, then >> one could change the encoding or change codec mode to reduce the rate. > > Magnus > > What would a feedback (back to a calling party phone, for example) look > like in this context? > As mentioned before I can see several possible ways. One that I like is to enable the PCN marking to reach the receiving entity that uses some back-channel, e.g. RTCP, to move the marking back to the sender. I do not assume that there is bi-directional media traffic nor that it will have the same path. Another case would be for the ingress router to use the QoS signalling protocol to re-negotiate the parameters. However I think the above type would be simpler to get working correctly. It also seem to provide some possibility to allow for flows to utilize over capacity when available. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Dec 19 11:33:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwhtq-0002n0-7o; Tue, 19 Dec 2006 11:33:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwhtp-0002mc-AZ for pcn@ietf.org; Tue, 19 Dec 2006 11:33:05 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwhtm-0001vu-J6 for pcn@ietf.org; Tue, 19 Dec 2006 11:33:05 -0500 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Dec 2006 16:32:57 +0000 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Dec 2006 16:32:55 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] comments on single marking draft Date: Tue, 19 Dec 2006 16:32:54 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CF69@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] comments on single marking draft Thread-Index: AccexyaTBlhK3y8XQeWPUER0mhigGwAA+3mQAS/stJA= From: To: , X-OriginalArrivalTime: 19 Dec 2006 16:32:55.0106 (UTC) FILETIME=[55D90220:01C7238B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: jzhang@cs.cornell.edu X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Anna a few follow-ups in-line Thanks - happy Christmas! phil > -----Original Message----- > From: Anna Charny (acharny) [mailto:acharny@cisco.com] > Sent: 13 December 2006 16:37 > To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org > Cc: Xinyang (Joy) Zhang > Subject: RE: [PCN] comments on single marking draft >=20 > Hi Phil, >=20 > Thanks for the thoughtful comments. A few responses below: >=20 > ________________________________ >=20 > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > Sent: Wednesday, December 13, 2006 9:59 AM > > To: pcn@ietf.org > > Subject: [PCN] comments on single marking draft >=20 > > Anna, all, >=20 > > Here at last are some comments on your single marking idea as > described in > http://ietf.org/internet-drafts/draft-charny-pcn-single-marking-00.txt >=20 >=20 > > The flow pre-emption mechanism is essentially the same as in the > Briscoe drafts, so they should behave the same. > >The comments below are all for admission control. >=20 > > The draft is very interesting, due to its two big advantages, as you > point out: > > - only need a single pkt encoding, easier to stdise > > - only need a single measurement operation at routers [so simpler, > faster] & this a measurement they do anyway > >[easier router upgrade] >=20 >=20 > > in your simulations, you analyse the probability of "false accepts" ie > accept calls when the network state really > > means should be rejected. From your simulations, it seems this is > probably OK, although it's harder to choose the > > parameters that make it work (harder than for the Briscoe i-d). >=20 > > * Reaction time: > > An important potential drawback is how quickly it reacts to changes in > load, especially if the load suddenly > > increases above the configured-admission-rate how > > quickly does the mechanism ensure that new calls are rejected. This is > worse for the token bucket algorithm compared > > with the virtual queue - because the latter moves rapidly from marking > 0% to 100% of packets as the load increases, > > whilst the former only marks the excess rate. > >Also, a smaller ewma 'weight' means that the egress effectively > averages over a longer time. Unfortunately, for the video >scenario > Table A4 suggests you need to use a small ewma weight. > > It would be nice to get a handle on how significant this problem is. >=20 > Yes, indeed the reaction time is slower. It seems to me that from the > practical standpoint slower reaction time may in principle be bad > because it may result in overshoot when the load grows rapidly and > undershoot when it drops. However, we did not really see much of either > in the simulations (see below on comments regarding undershoot). >=20 > In fact I believe that is the moderate overshoot we see in the > simulation is exactly because of the slower reaction time. However, it > should be pointed that the simulations assumed benign poisson arrivals. > One of the things to do for the future is to investigate how bad it can > become if arrivals are much burstier. We saw in earlier simulations > that virtual queue is relatively tolerant to a moderate increase in > burstiness of arrivals - so you are right we need to look at burtier > arrivals here as well. Great - another way of assessing this might be the 'vulnerability period'? - time for which you could admit calls although you shouldn't. the measurement overshoot depends on the number of call attempts during the vulnerability periods during the simulation - which depends on the call arrival stats.=20 >=20 > >ewma 'weight':- > > > >ewma_new =3D weight * new_measurement + (1-weight)*ewma_old > >calculated/measured every 100ms interval according to > > > http://www.ietf.org/internet-drafts/draft-zhang-pcn-performance-evaluati > on-00.txt > >so a weight of 0.1 is very roughly smoothing over about 1sec & weight > of 0.9 smoothing over roughly 0.1sec. > >I'd imagined the smoothing was over a shorter time period. >=20 > I think you are saying you would prefer a smaller measurement interval > than 100ms? (once the interval is chosen ewma sensitivity is presented > in th edraft). The 100ms was chosen to make the load on the egress > device manageable if there are lots of ingresses. I guess the question > boils down to how bad over/under admission is with these parameters. So > far we think it is OK. But indeed burstier arrivals and in general more > beating up on the simulation would help. We do plan to do more of that. >=20 if your mean interval is 100ms, clearly your 'vulnerability period' is at least (roughly) 100ms.=20 > >* False rejects: > >One danger (which I don't think you considered) is that new call > request(s) may be rejected when they actually should be >accepted, > because the measured-ewma (=3DCLE) is greater than the CLE_threshold > whereas the actual-ewma is smaller. In > >general, an operator won't like false rejects (=3D money). >=20 > We actually did consider the false rejects (undersoot) by looking what > happens when the offered load is below the admission thresold > (specifically we looked at 0.95 and 1 load (although we showed only 0.95 > load in the draft, I think). We were looking specifically to see if we > will see any significant false rejects (which would result in > under-admission). > It did appear that for the simulation we did underadmission was quite > small (see negative "over-admission" numbers reflecting the > under-udmission in the draft). But again we would like to do more to see > if we see more underadmission for more abrupt traffic changes. >=20 > >It's quite hard to know how to assess this problem. Say you set > CLE-threshold to 5% - there'll be times when you measure >CLE as 5.01% > (& reject) when really it's 4.99% - however, the actual traffic level is > pretty much at your design level, > >so this error doesn't feel too important to me. However, if your > CLE-threshold is 0.01% my instinct is that there's a > >much higher chance of falsely rejecting a call when the actual traffic > level is still quite a way below your design > >level.Unfortunately, for the video scenario Table A4 suggests you need > to use a small CLE-threshold. >=20 > See above. Specific suggestions on setups that you feel might show the > problem you are concerned about are very welcome. Will think about >=20 > One thing to remember here is that "video" we used in our simulations is > not really video - it is on-ff CBR with long on and off periods (330 ms > and 660 ms respectively). With a releatively small number of these > "video" flows considered, one would expect the aggregate traffic to > still be rather abruptly changing. Further, as we had only one or very > few of these "video" flows per ngress-egrees pair, the ingress > measurements are really challenging as 100 ms measurements really > oscillate between 0 and peak rate most of the time. We had always felt > that this kind of "video" represents a "lower bound" on the actual video > behavior (that is, we felt that if performance is OK with this, it > should be better with real video. One of the things we are trying to do > right now is to implement more realistic video models. Will see if our > intuition is confirmed then. >=20 > >* Inter-domain case > >you use a system-wide constant u, the assumed ratio between pre-emption > and admission thresholds for all links in the > >PCN-region. > >The thought is that the PCN-region can gradually be extended to cover > multiple domains. But each might be using different >values for u - so > inter-domain operations might be hampered. This needs more thought. >=20 > I believe you are saying that when two PCN domains merge, then a virtual > queue approach allows the operator to considerthe two omains as a single > domain, while for the single marking approach the choice is either to > mandate the same u in nboth or keep the boundary. I think that is true, > and is certainly a tradeoff to consider. One question here is whether > an operator who wants to merge two domains would really feel that > mandating the same u is a limiting factor? I think this is probably fair (except where you say "an operator who wants to merge two domains", they could be in separate operators) >=20 > >* Other comments: > > > >- it would be nice if the simulations could be re-run for multiple > videos per ingress-egress-aggregate - to check that > >the deduction is correct that "we believe that the severe degradation > of performance in this topology is directly > >attributable to the lack of traffic aggregation on the ingress-egress > pair basis." >=20 > I believe we actually did that - the "single bottleneck topology" with > video corresponds to the same bottleneck capacity but all video flows > sharing the same ingress-egreess pair. Will doublecheck... >=20 > >- in the simulations, could you check whether the probability of > accepting a call request on a *particular* ingresss- > >egress-aggregate is biased by the RTT >=20 > I will double-check, but I believe the answer we arrived at was "no" (in > the experiments we tried) - in that the RTT had no effect in the > distribution of admitted flows among the ingresses. We should reflect > this more clearly in the next revision of the draft. >=20 > >- your assumptions in the simulations seemed ok to me: >=20 > > - single bottleneck - if there are multiple bottlenecks, would expect > the method still to be ok - the marking %s combine as required. >=20 > We will check that - we finally got to the multiple bottleneck case, but > started with preemption first, as it is relevant to both approaches. >=20 > >- No packet loss - if there was packet loss, would expect method still > to be ok, as would expect all packets getting through the overloaded > router to be marked. NB must not preferentially drop marked packets, > otherwise might get no pkts through. >=20 > Still to be thought through further, but for the moment seemed like a > reasonable initial assumption. >=20 > Best, > Anna >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Dec 20 07:11:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx0IA-0002h3-TH; Wed, 20 Dec 2006 07:11:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx0I9-0002gn-1j for pcn@ietf.org; Wed, 20 Dec 2006 07:11:25 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx0I5-0007NC-8L for pcn@ietf.org; Wed, 20 Dec 2006 07:11:24 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 97C607BF; Wed, 20 Dec 2006 13:10:49 +0100 (CET) Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 13:10:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Alternatives to Preemption Date: Wed, 20 Dec 2006 13:10:49 +0100 Message-ID: <53CCFDD6E346CB43994852666C210E910F7387@esealmw116.eemea.ericsson.se> In-Reply-To: <4587AB1D.8010101@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Alternatives to Preemption Thread-Index: AccjTLprC+5vhujIQh+BPrbRk7gJOQA4R/9A From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Magnus Westerlund \(KI/EAB\)" , "James M. Polk" X-OriginalArrivalTime: 20 Dec 2006 12:10:49.0448 (UTC) FILETIME=[E309C680:01C7242F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi All, I also support the idea to think of and supporting different = applications. The problem of congestion notification and the action to = decrease the load can be well separated.=20 In the notificaion part it is important to indicate the congestion = level. It can be application specific how to decrease the load to the = appropriate level. Best regards, Attila >-----Original Message----- >From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 >Sent: Tuesday, December 19, 2006 10:04 AM >To: James M. Polk >Cc: pcn@ietf.org >Subject: Re: [PCN] Alternatives to Preemption > >James M. Polk skrev: >> At 03:48 PM 12/18/2006 +0100, Magnus Westerlund wrote: >>> Hi, >>> >>> So far the discussion has been quite focused on preemption when the=20 >>> resources gets overtaxed. Aren't there some cases when the=20 >>> alternative to preemption would be to indicate to the flows=20 >that they=20 >>> may only use less resources? This could happen by having the QoS=20 >>> mechanism engage in re-negotiation. >>> >>> For example in cases when large parts of the traffic is voice, then=20 >>> one could change the encoding or change codec mode to=20 >reduce the rate. >>=20 >> Magnus >>=20 >> What would a feedback (back to a calling party phone, for example)=20 >> look like in this context? >>=20 > >As mentioned before I can see several possible ways. One that=20 >I like is to enable the PCN marking to reach the receiving=20 >entity that uses some back-channel, e.g. RTCP, to move the=20 >marking back to the sender. I do not assume that there is=20 >bi-directional media traffic nor that it will have the same=20 >path. Another case would be for the ingress router to use the=20 >QoS signalling protocol to re-negotiate the parameters.=20 >However I think the above type would be simpler to get working=20 >correctly. It also seem to provide some possibility to allow=20 >for flows to utilize over capacity when available. > >Cheers > >Magnus Westerlund > >IETF Transport Area Director & TSVWG Chair >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVA/A >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Dec 20 09:06:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx25P-0001pb-8E; Wed, 20 Dec 2006 09:06:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx25O-0001pW-5Z for pcn@ietf.org; Wed, 20 Dec 2006 09:06:22 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx25L-00063C-QA for pcn@ietf.org; Wed, 20 Dec 2006 09:06:22 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kBKE6CjH022225 for ; Wed, 20 Dec 2006 08:06:19 -0600 (CST) Received: from ILEXC1U02.ndc.lucent.com ([135.3.39.5]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 08:06:13 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Alternatives to Preemption Date: Wed, 20 Dec 2006 08:06:13 -0600 Message-ID: <7D096A439A3D0D48A3D10872022CFD09813883@ILEXC1U02.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Alternatives to Preemption Thread-Index: AccjTLprC+5vhujIQh+BPrbRk7gJOQA4R/9AAAHi3IAAAp6fkA== From: "GOLDMAN, STUART O \(STUART\)" To: X-OriginalArrivalTime: 20 Dec 2006 14:06:13.0709 (UTC) FILETIME=[023827D0:01C72440] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Folks, Since preemption is sometimes viewed as an "inflammatory" topic, it does = seem better to take the approach of separating the detection and = notification of congestion from the collection of possible actions that = can be taken to rectify it. Stuart Goldman Alcatel-Lucent=20 sgoldman@alcatel-lucent.com 602 493 8438 -----Original Message----- From: Attila B=E1der (IJ/ETH) [mailto:attila.bader@ericsson.com]=20 Sent: Wednesday, December 20, 2006 5:11 AM To: Magnus Westerlund (KI/EAB); James M. Polk Cc: pcn@ietf.org Subject: RE: [PCN] Alternatives to Preemption Hi All, I also support the idea to think of and supporting different = applications. The problem of congestion notification and the action to = decrease the load can be well separated.=20 In the notificaion part it is important to indicate the congestion = level. It can be application specific how to decrease the load to the = appropriate level. Best regards, Attila >-----Original Message----- >From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 >Sent: Tuesday, December 19, 2006 10:04 AM >To: James M. Polk >Cc: pcn@ietf.org >Subject: Re: [PCN] Alternatives to Preemption > >James M. Polk skrev: >> At 03:48 PM 12/18/2006 +0100, Magnus Westerlund wrote: >>> Hi, >>> >>> So far the discussion has been quite focused on preemption when the=20 >>> resources gets overtaxed. Aren't there some cases when the=20 >>> alternative to preemption would be to indicate to the flows=20 >that they=20 >>> may only use less resources? This could happen by having the QoS=20 >>> mechanism engage in re-negotiation. >>> >>> For example in cases when large parts of the traffic is voice, then=20 >>> one could change the encoding or change codec mode to=20 >reduce the rate. >>=20 >> Magnus >>=20 >> What would a feedback (back to a calling party phone, for example)=20 >> look like in this context? >>=20 > >As mentioned before I can see several possible ways. One that=20 >I like is to enable the PCN marking to reach the receiving=20 >entity that uses some back-channel, e.g. RTCP, to move the=20 >marking back to the sender. I do not assume that there is=20 >bi-directional media traffic nor that it will have the same=20 >path. Another case would be for the ingress router to use the=20 >QoS signalling protocol to re-negotiate the parameters.=20 >However I think the above type would be simpler to get working=20 >correctly. It also seem to provide some possibility to allow=20 >for flows to utilize over capacity when available. > >Cheers > >Magnus Westerlund > >IETF Transport Area Director & TSVWG Chair >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVA/A >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Dec 21 10:14:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxPcc-0004M4-My; Thu, 21 Dec 2006 10:14:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxPcb-0004Lu-TV for pcn@ietf.org; Thu, 21 Dec 2006 10:14:13 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxPcZ-0003la-Gj for pcn@ietf.org; Thu, 21 Dec 2006 10:14:13 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kBLFE6q27881; Thu, 21 Dec 2006 10:14:06 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Comments on draft-babiarz-pcn-sip-cap-00.txt Date: Thu, 21 Dec 2006 10:14:04 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650DD8A0AB@zcarhxm1.corp.nortel.com> In-Reply-To: <4586983A.1040407@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Comments on draft-babiarz-pcn-sip-cap-00.txt Thread-Index: AcciqWtQipGLz7FXRjmF+SdWxwENrAAMWPIQ From: "Jozef Babiarz" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Michael, please see comments below: Regards, Joe Email: babiarz@nortel.com -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: Monday, December 18, 2006 8:32 AM To: pcn@ietf.org Subject: [PCN] Comments on draft-babiarz-pcn-sip-cap-00.txt >Hi Joe et al. >I've browsed again through the draft >http://www.ietf.org/internet-drafts/draft-babiarz-pcn-sip-cap-00.txt >Many aspects in this draft like probing etc. are of general nature=20 >regarding PCN and are not SIP-specific. This hides the SIP-specific=20 >problems. Probing is certainly a good thing to do to avoid flash crowds >and ECMP problems, but the IntServ over DiffServ model would equally=20 >benefit from probing. [Joe] Yes, I also believe that the probing concept adds value in the IntServ over DiffServ model. Note, I'm not trying to hide any SIP-specific issue, just wanted to provide a high level overview using SIP as an example. >Regarding the interaction between SIP and the PCN architecture I see two=20 >possible options (maybe mixed approaches are also possible): >1) SIP uses PCN admission and preemption provided by the ingress nodes=20 >of the PCN domain. >2) PCN border nodes only provide probing and measurement and send the=20 >raw measurement data to the SIP proxy which takes the admission and=20 >preemption decisions. [Joe] Actually what I proposed in the draft is different, however what you proposing could be a method for currently defined IntServ over DiffServ model to interact with SIP application control. I mentioned in the draft-babiarz-pcn-sip-cap-00 that the PCN marking behavior for preemption is a bit different than what is currently in draft-briscode-tswwg-cl-phb-02. What I'm proposing is that interior routers explicitly signal via setting of bits in the IP header the action that end nodes (hosts or edge routers) should take. For preemption the concept is similar to what is defined for ECN in RFC3168. In other words, edge nodes just need to react to the marking. i.e., stop admitting of new flow or preempt already admitted PCN marked follow(s) should the need arise. With this approach, only the interior routers perform traffic level measurements and explicit mark to indicate the action that the edge nodes need to take. I'm planning to do a write-up with simulation and see what everyone thinks of this approach for PCN marking.=20 >I think 2) is favored in the draft. However, I still miss the full=20 >picture: which entity does what and communicates what to which other >entity? >Some comments to both approaches: >ad 1) SIP uses PCN >* The PCN ingress selects the flows being preempted which is unaware of >session structures. (-) >* SIP contacts the PCN ingress like any other flow would do and waits=20 >for an answer. Therefore, this approach can coexist with RSVP and other >signaling schemes as PCN border routers control the resources of the=20 >network. (+) >* No single point of failure (+) >ad 2) SIP implements PCN >* SIP triggers PCN border routers and receives information from them.=20 >Based on this information, admission and preemption decisions are made. >Details are not clear to me yet. (o) >* SIP selects the flows being preempted: correlated streams may be=20 >preempted together, e.g., voice and video of application X instead of=20 >voice of X and video of Y. (+) >* SIP control makes coexistence with other resources control paradigms=20 >difficult (-) >* SIP control is single point of failure like a bandwidth broker (-) >Best regards, > Michael --=20 Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Dec 21 10:29:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxPr3-0003VH-9q; Thu, 21 Dec 2006 10:29:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxPr2-0003VB-1e for pcn@ietf.org; Thu, 21 Dec 2006 10:29:08 -0500 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxPqw-0006c5-CW for pcn@ietf.org; Thu, 21 Dec 2006 10:29:08 -0500 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 64C7830E2; Thu, 21 Dec 2006 16:28:57 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 54540352C; Thu, 21 Dec 2006 16:28:57 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id E9DE130E2; Thu, 21 Dec 2006 16:28:56 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id kBLFSus27027; Thu, 21 Dec 2006 16:28:56 +0100 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 0D2BE6F58E; Thu, 21 Dec 2006 16:26:25 +0100 (CET) Message-ID: <458AA77D.2000807@informatik.uni-wuerzburg.de> Date: Thu, 21 Dec 2006 16:25:49 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Jozef Babiarz Subject: Re: [PCN] Comments on draft-babiarz-pcn-sip-cap-00.txt References: <9671A92C3C8B5744BC97F855F7CB64650DD8A0AB@zcarhxm1.corp.nortel.com> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650DD8A0AB@zcarhxm1.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Joe, Jozef Babiarz wrote: > Michael, please see comments below: > > Regards, Joe > Email: babiarz@nortel.com > > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: Monday, December 18, 2006 8:32 AM > To: pcn@ietf.org > Subject: [PCN] Comments on draft-babiarz-pcn-sip-cap-00.txt > > >> Hi Joe et al. >> > > >> I've browsed again through the draft >> http://www.ietf.org/internet-drafts/draft-babiarz-pcn-sip-cap-00.txt >> Many aspects in this draft like probing etc. are of general nature >> regarding PCN and are not SIP-specific. This hides the SIP-specific >> problems. Probing is certainly a good thing to do to avoid flash crowds >> > > >> and ECMP problems, but the IntServ over DiffServ model would equally >> benefit from probing. >> > [Joe] Yes, I also believe that the probing concept adds value in the > IntServ over DiffServ model. Note, I'm not trying to hide any > SIP-specific issue, just wanted to provide a high level overview using > SIP as an example. > > >> Regarding the interaction between SIP and the PCN architecture I see >> > two > >> possible options (maybe mixed approaches are also possible): >> 1) SIP uses PCN admission and preemption provided by the ingress nodes >> of the PCN domain. >> 2) PCN border nodes only provide probing and measurement and send the >> raw measurement data to the SIP proxy which takes the admission and >> preemption decisions. >> > [Joe] Actually what I proposed in the draft is different, however what > you proposing could be a method for currently defined IntServ over > DiffServ model to interact with SIP application control. I mentioned in > the draft-babiarz-pcn-sip-cap-00 that the PCN marking behavior for > preemption is a bit different than what is currently in > draft-briscode-tswwg-cl-phb-02. What I'm proposing is that interior > routers explicitly signal via setting of bits in the IP header the > action that end nodes (hosts or edge routers) should take. For > preemption the concept is similar to what is defined for ECN in RFC3168. > In other words, edge nodes just need to react to the marking. i.e., stop > admitting of new flow or preempt already admitted PCN marked follow(s) > should the need arise. With this approach, only the interior routers > perform traffic level measurements and explicit mark to indicate the > action that the edge nodes need to take. I'm planning to do a write-up > with simulation and see what everyone thinks of this approach for PCN > marking. > I don't see the difference to the functionality of http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-04.txt So pointing out the differences in your draft would be helpful for me and probably also for others to recognized what's different and facilitates a discussion. Best wishes, Michael > >> I think 2) is favored in the draft. However, I still miss the full >> picture: which entity does what and communicates what to which other >> entity? >> > > >> Some comments to both approaches: >> > > >> ad 1) SIP uses PCN >> * The PCN ingress selects the flows being preempted which is unaware of >> > > >> session structures. (-) >> * SIP contacts the PCN ingress like any other flow would do and waits >> for an answer. Therefore, this approach can coexist with RSVP and other >> > > >> signaling schemes as PCN border routers control the resources of the >> network. (+) >> * No single point of failure (+) >> > > >> ad 2) SIP implements PCN >> * SIP triggers PCN border routers and receives information from them. >> Based on this information, admission and preemption decisions are made. >> > > >> Details are not clear to me yet. (o) >> * SIP selects the flows being preempted: correlated streams may be >> preempted together, e.g., voice and video of application X instead of >> voice of X and video of Y. (+) >> * SIP control makes coexistence with other resources control paradigms >> difficult (-) >> * SIP control is single point of failure like a bandwidth broker (-) >> > > >> Best regards, >> > > >> Michael >> > > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Dec 21 10:34:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxPvu-00064W-AI; Thu, 21 Dec 2006 10:34:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxPvt-00063f-1K for pcn@ietf.org; Thu, 21 Dec 2006 10:34:09 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxPvq-0007Xe-N6 for pcn@ietf.org; Thu, 21 Dec 2006 10:34:09 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kBLFXsP28584; Thu, 21 Dec 2006 10:33:55 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Alternatives to Preemption Date: Thu, 21 Dec 2006 10:33:53 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650DD8A0D2@zcarhxm1.corp.nortel.com> In-Reply-To: <4.3.2.7.2.20061218150159.02f5fbe8@email.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Alternatives to Preemption Thread-Index: Acci6J9eEwssV+vHSxqKjTNlAh6M1QCKmuQQ From: "Jozef Babiarz" To: "James M. Polk" , "Magnus Westerlund" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org James, My assumption is that like with ECN, PCN (explicit pre-congestion notification) information is carried in the IP header to the media endpoint (receiver). The receivers are informed via PCN marking that rate reduction is desirable. The receiver needs to signal to the transmitter to reduce its sending rate. I was thinking for applications that use RTP that RTCP could be used to signal rate changes between the two media endpoint.=20 Regards, Joe QoS & Network Architecture Telephone: 613-763-6098 (ESN 393-6098) Email: babiarz@nortel.com -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com]=20 Sent: Monday, December 18, 2006 4:08 PM To: Babiarz, Jozef (CAR:0S03); Magnus Westerlund; pcn@ietf.org Subject: RE: [PCN] Alternatives to Preemption Jozef This is an interesting way of doing a solution, however, I do not see what=20 type of message is sent by the core edge to the actual phone to tell it to=20 do anything. SIP messaging (with SDP inside) can and probably does take an=20 entirely different path to set up the call than the RTP media packets take,=20 therefore - something needs to be on the RTP path giving feedback. This could be RTCP, but is that sent by the core edge router? I don't believe so=20 (unless this node is also an SBC). Therefore, what does send this message=20 and what could it be in the form of? I'm wondering if Magnus is assuming the ingress and egress of bidirectional=20 RTP pcakets traverse the same core edge router? I'm not looking for a solution as much as I'm looking for what people might=20 be thinking a solution could look like. At 02:15 PM 12/18/2006 -0500, Jozef Babiarz wrote: >James one possible way that this could work is that during session >setup, two codecs are negotiated in the SDP offer message, the first >being high quality higher rate codec and the second a lower rate codec. >When onset of congestion is detected, the PCN marking triggers the >endpoints to switch to lower rate codec. The receiver of the RTP steam >(phone) needs to signal to the sender possible using RTCP the codec >change request. > >Regards, Joe >Email: babiarz@nortel.com > >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: Monday, December 18, 2006 1:00 PM >To: Magnus Westerlund; pcn@ietf.org >Subject: Re: [PCN] Alternatives to Preemption > >At 03:48 PM 12/18/2006 +0100, Magnus Westerlund wrote: > >Hi, > > > >So far the discussion has been quite focused on preemption when the > >resources gets overtaxed. Aren't there some cases when the alternative >to > >preemption would be to indicate to the flows that they may only use >less > >resources? This could happen by having the QoS mechanism engage in > >re-negotiation. > > > >For example in cases when large parts of the traffic is voice, then one > > >could change the encoding or change codec mode to reduce the rate. > >Magnus > >What would a feedback (back to a calling party phone, for example) look >like in this context? > > >Cheers > > > >Magnus Westerlund > > > >IETF Transport Area Director & TSVWG Chair > >---------------------------------------------------------------------- > >Multimedia Technologies, Ericsson Research EAB/TVA/A > >---------------------------------------------------------------------- > >Ericsson AB | Phone +46 8 4048287 > >Torshamsgatan 23 | Fax +46 8 7575550 > >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > >---------------------------------------------------------------------- > > > >_______________________________________________ > >PCN mailing list > >PCN@ietf.org > >https://www1.ietf.org/mailman/listinfo/pcn > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Dec 21 10:41:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxQ2g-000193-3K; Thu, 21 Dec 2006 10:41:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxQ2f-00018t-Ck for pcn@ietf.org; Thu, 21 Dec 2006 10:41:09 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxQ2c-0000Tb-Vq for pcn@ietf.org; Thu, 21 Dec 2006 10:41:09 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kBLFf4q03581; Thu, 21 Dec 2006 10:41:04 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Comments on draft-babiarz-pcn-sip-cap-00.txt Date: Thu, 21 Dec 2006 10:40:48 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650DD8A0DC@zcarhxm1.corp.nortel.com> In-Reply-To: <458AA77D.2000807@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Comments on draft-babiarz-pcn-sip-cap-00.txt Thread-Index: AcclFMsmZEjnrARITwyyrGhoIQhCBgAANaKQ From: "Jozef Babiarz" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Michael wrote:=20 >I don't see the difference to the functionality of >http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture ->04.txt >So pointing out the differences in your draft would be helpful for me=20 >and probably also for others to recognized what's different and=20 >facilitates a discussion. [Joe] OK, will do. Regards, Joe Email: babiarz@nortel.com -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: Thursday, December 21, 2006 10:26 AM To: Babiarz, Jozef (CAR:0S03) Cc: pcn@ietf.org Subject: Re: [PCN] Comments on draft-babiarz-pcn-sip-cap-00.txt Hi Joe, Jozef Babiarz wrote: > Michael, please see comments below: > > Regards, Joe > Email: babiarz@nortel.com > > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 > Sent: Monday, December 18, 2006 8:32 AM > To: pcn@ietf.org > Subject: [PCN] Comments on draft-babiarz-pcn-sip-cap-00.txt > > =20 >> Hi Joe et al. >> =20 > > =20 >> I've browsed again through the draft >> http://www.ietf.org/internet-drafts/draft-babiarz-pcn-sip-cap-00.txt >> Many aspects in this draft like probing etc. are of general nature=20 >> regarding PCN and are not SIP-specific. This hides the SIP-specific=20 >> problems. Probing is certainly a good thing to do to avoid flash crowds >> =20 > > =20 >> and ECMP problems, but the IntServ over DiffServ model would equally=20 >> benefit from probing. >> =20 > [Joe] Yes, I also believe that the probing concept adds value in the > IntServ over DiffServ model. Note, I'm not trying to hide any > SIP-specific issue, just wanted to provide a high level overview using > SIP as an example. > > =20 >> Regarding the interaction between SIP and the PCN architecture I see >> =20 > two=20 > =20 >> possible options (maybe mixed approaches are also possible): >> 1) SIP uses PCN admission and preemption provided by the ingress nodes=20 >> of the PCN domain. >> 2) PCN border nodes only provide probing and measurement and send the >> raw measurement data to the SIP proxy which takes the admission and=20 >> preemption decisions. >> =20 > [Joe] Actually what I proposed in the draft is different, however what > you proposing could be a method for currently defined IntServ over > DiffServ model to interact with SIP application control. I mentioned in > the draft-babiarz-pcn-sip-cap-00 that the PCN marking behavior for > preemption is a bit different than what is currently in > draft-briscode-tswwg-cl-phb-02. What I'm proposing is that interior > routers explicitly signal via setting of bits in the IP header the > action that end nodes (hosts or edge routers) should take. For > preemption the concept is similar to what is defined for ECN in RFC3168. > In other words, edge nodes just need to react to the marking. i.e., stop > admitting of new flow or preempt already admitted PCN marked follow(s) > should the need arise. With this approach, only the interior routers > perform traffic level measurements and explicit mark to indicate the > action that the edge nodes need to take. I'm planning to do a write-up > with simulation and see what everyone thinks of this approach for PCN > marking.=20 > =20 I don't see the difference to the functionality of http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture- 04.txt So pointing out the differences in your draft would be helpful for me=20 and probably also for others to recognized what's different and=20 facilitates a discussion. Best wishes, Michael > =20 >> I think 2) is favored in the draft. However, I still miss the full=20 >> picture: which entity does what and communicates what to which other >> entity? >> =20 > > =20 >> Some comments to both approaches: >> =20 > > =20 >> ad 1) SIP uses PCN >> * The PCN ingress selects the flows being preempted which is unaware of >> =20 > > =20 >> session structures. (-) >> * SIP contacts the PCN ingress like any other flow would do and waits >> for an answer. Therefore, this approach can coexist with RSVP and other >> =20 > > =20 >> signaling schemes as PCN border routers control the resources of the=20 >> network. (+) >> * No single point of failure (+) >> =20 > > =20 >> ad 2) SIP implements PCN >> * SIP triggers PCN border routers and receives information from them. >> Based on this information, admission and preemption decisions are made. >> =20 > > =20 >> Details are not clear to me yet. (o) >> * SIP selects the flows being preempted: correlated streams may be=20 >> preempted together, e.g., voice and video of application X instead of >> voice of X and video of Y. (+) >> * SIP control makes coexistence with other resources control paradigms=20 >> difficult (-) >> * SIP control is single point of failure like a bandwidth broker (-) >> =20 > > =20 >> Best regards, >> =20 > > =20 >> Michael >> =20 > > =20 --=20 Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Dec 22 12:57:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxoeE-0001EP-3Y; Fri, 22 Dec 2006 12:57:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxoeC-0001E7-Tk for pcn@ietf.org; Fri, 22 Dec 2006 12:57:32 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxoe7-0001KA-VC for pcn@ietf.org; Fri, 22 Dec 2006 12:57:32 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Dec 2006 17:56:55 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Dec 2006 17:55:56 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1166810156452; Fri, 22 Dec 2006 17:55:56 +0000 Received: from mut.jungle.bt.co.uk ([10.215.130.159]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id kBMHtsF5026275; Fri, 22 Dec 2006 17:55:55 GMT Message-Id: <5.2.1.1.2.20061222120545.01f64098@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Dec 2006 17:55:53 +0000 To: "Geib, Ruediger" From: Bob Briscoe Subject: Re: [PCN] Off list: Comments on re ecn border cheat Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.201 () ALL_TRUSTED,MIME_QP_LONG_LINE X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 22 Dec 2006 17:55:56.0926 (UTC) FILETIME=[6E7BA9E0:01C725F2] X-Spam-Score: 0.1 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org R=FCdiger, The most important part of this mail is right at the end in response to=20 your sum-up. On the way are my clarifications where I think my draft must=20 have confused you... At 16:34 18/12/2006, Geib, Ruediger wrote: >Hi Bob, > >although border cheating isn't part of the currently >discussed pcn charter, I prefer to communicate my >comments using this mail exploder. I'm happy to >continue this discussion privately, should others >feel this to be preferable. As no-one seems to have objected to this being on-list, let's continue. >You propose a mechanism allowing to identify ingress >gateways to a PCN region ignoring feedback on ECN >marked packets which was given them. Your >argumentation is that intermediate transit networks >providing bulk CL transport must have a way to >ensure "fair use of resources" while maintaining the >agreed CL service level. > >You are right in your conclusion on the required >ability of a transit network to monitor the behaviour >of traffic sinks ...and sources >after pre congestion notifcation >occurred within this transit network, I think. While >I think, that the mechanism you propose is smart and >may work, I'm not sure, whether the accounting >mechanism surrounding it should or could be >standardised by IETF. Certainly, I don't expect the accounting mechanism to need IETF standards.= =20 My intent is always to give operators the freedom to choose what they agree= =20 bilaterally with each other. The intent was purely to standardise a new=20 metric (downstream congestion) that can be used in various ways by=20 operators for accounting at borders. [Network economics says that the true cost of usage of a network is solely= =20 the congestion, and pricing in a competitive market will gradually converge= =20 to true cost. So it's important that a network architecture provides=20 congestion as a metric, for commercial agreements to be built on, given its= =20 in end-users interests for the Internet market to be competitive.] Does the I-D make it clear that I'm not expecting IETF standardisation of=20 the accounting? I tried to say this in the para in section 5.3 on=20 Pre-requisite Contractual Arrangements, starting "operators are free to=20 choose how they incorporate it into their interconnection contracts..."? Or= =20 should I say this more explicitly somehow? If this gets chartered later, this scheme would require IETF=20 standardisation of the behaviour of edge gateways (the draft includes some= =20 MUSTs and SHOULDs in this respect), but there will be no need for the IETF= =20 to standardise any accounting procedures at borders. Accounting procedures= =20 might be standardised elsewhere (e.g. ITU-T, ETSI-TISPAN). But there will=20 still be a need for this informational draft to explain the overall intent. I will think how I can make all this standards intent clearer. >I'd prefer not to enter a detailed discussion on >the usefulness of your proposed solution. Instead, >I'd like to list a couple of thoughts coming to >my mind: > >- The egress gateway feeds back the PCN information > to the ingress gateway. It could at least monitor > RSVP signaling after PCN feedback has been given > by it. > If it expects PATH messages after PCN feedback > to be followed by PathErr sent from the ingress > and receives refreshes instead, a cheat is easily > identified. But that is obviously of no help, if > the traffic contract of an admitted reservation > isn't kept. Yes, the egress gateway can police reservation traffic because it=20 understands flows. I took that as a given - something that the introduction= =20 of PCN doesn't alter. I need to make that clear. Thanks. Imagine the interior networks A,B&C in the generic scenario shown in Fig 1= =20 can't see reservation signalling at all (the ingress & egress gateways=20 could even encrypt signalling between themselves). The anti-cheating=20 mechanism ensures networks A,B&C can encourage the edge gateways to do=20 admission control properly even tho they don't see the per-flow signalling. >- Ingress/Egress gateway per flow policing probably > is the only way to ensure correct behaviour of > sources (and avoid cheats on consumed bandwidths). Agreed - we're not changing that - I'll make that clear. >- The transit networks sell a bulk service. They > aren't aware of any per flow events and don't > care as long as the CL/PCN service operates > properly. > >- The transit provider charges for CL traffic > volumes [Charging for CL traffic volumes isn't a particularly necessary or sensible= =20 proposition (if there's no congestion, traffic volume doesn't cost=20 anything), but they could do this.] >and provides an SLA on two things: > * CL performance (close to loss free) > * Probability to cause ECN marks to be set on > an internal bottleneck (let's call it a "network > busy indication", should have a low probability). Yes, that's one possible SLA. >- Per transit domain (ingress-egress?) aggregate > PCN and CL reports may have to be produced anyway. > They prove who has contributed to a network busy > situation in a chain of networks for ECN marks. > For CL traffic, they prove loss free operation. The phrase "(ingress-egress?) aggregate" is /not/ what I am suggesting. It= =20 sounds complicated whereas the idea I have described is designed to make=20 border accounting very simple. There is no need for a transit domain to separate up its traffic into=20 ingress-egress aggregates. All it has to do is measure the whole bulk of CL= =20 traffic crossing its border with another operator (say the A->B border)=20 over say a month. This measurement can remain local to that border and=20 requires no comparison or correlation with any other measurements from any= =20 other border. The SLA between A and B only depends on this local=20 measurement of traffic between them. They both see the traffic at this=20 point, so they don't have to trust any measurements from anywhere else in=20 the network. Given the rest of the protocol arrangement, this local border measurement=20 alone tells them how much congestion A has dumped into B. >- The downstream egress (gateway) can't determine > where and by which network an ECN mark has been > set. I'd expect the egress border routers/gateways > noticing ECN marked traffic not to have an interest > in cheating as they could hit own customers. The re-feedback solution doesn't rely on someone not cheating /just in=20 case/ they hurt their customers - it aims to make the incentives= unambiguous. Without re-feedback, an egress gateway seeing PCN marking might suppress=20 the marking or suppress PCN feedback on the basis that the pre-congestion=20 was in an upstream network. It could gain from selling more reservations to= =20 its downstream customers. It might reckon that the service to its own=20 customers wouldn't be degraded, because PCN marking doesn't mean the=20 upstream network is actually congested yet, so it can eat into the other=20 network's other services (e.g. corporate VPNs). With re-feedback, if an upstream network is congested, and the egress=20 gateway suppresses the PCN marking, or the feedback, this leads to a=20 'negative' balance at the border where this traffic arrives from the=20 upstream network. The mechanisms described in the draft allow the upstream= =20 network to detect this negative balance and remove such traffic flows (and= =20 any expected SLA would give them the incentive to do this). >- The ingress can only cheat on a secure basis, if > it can be sure that it isn't the own network > producing the ECN marks. This assumes some form of > ECN feedback from its border router (assuming the > ingress gateway to be part of a domain, not a > single service production point). No, again I don't think you're reading it right. There is no feedback from= =20 border routers. The whole idea is to simplify border routers in the future. The re-feedback mechanism only requires feedback (at a slow rate) from=20 egress to ingress gateway. Border routers merely forward traffic. And they= =20 meter passively for local use only, as we discussed earlier. [If this becomes the way a border works, it should eventually be possible=20 to have a straight-through optical interconnect at the border. Of course,=20 there are other things border routers do in the data plane that are=20 problematic to do in pure optics, but it will be useful to know we can do=20 inter-provider admission control without adding to the list of things that= =20 require an optical-electronic-optical conversion.] >- The hard part seems to be to identify and trace > back a cheater in the case of a chain of transit > networks and pre congestions marks set by a > downstream network are ignored by an upstream > ingress gateway. But that assumes that the ingress > operator knows that congestion isn't occuring close > to him and probaly also requires the egress gateway > to cooperate. I have chosen not to try to help networks /identify/ the source of a cheat.= =20 The re-feedback solution ensures that, where there are sensible penalties=20 agreed bilaterally between networks for breaking SLAs, a cheating network=20 will have to pay a penalty to its neighbour that makes it not worth=20 cheating. The ultimate effect will be the cheater pays, and the network it= =20 harmed eventually receives the penalty. Other non-cheating networks that=20 may be between them will both pay and receive penalties, effectively=20 passing along the penalty. [Whether everything balances out fairly depends on the SLAs they all agree.= =20 I have described at least one type of SLA that would balance out fairly if= =20 they all used it. However, I don't want to mandate that they must use just= =20 this one, of course.] Penalties proportionate to the cheat /deter/ cheating. They don't=20 /identify/ the cheater. In this scheme, just because you make your=20 neighbour pay you a penalty, it doesn't mean you think your neighbour is=20 cheating. Other much more complicated probe-based schemes might be used (in= =20 parallel) to /identify/ cheaters, but I'm proposing something simpler but=20 sufficient. I guess I need to start by explaining this motivation. >To sum up, I'd prefer a deeper analysis of the scenarios >and architectures around cheating before discussing >solutions. Certainly. I tried to write up both the problem and the solution, so that=20 anyone who cared to read it all could start to satisfy themselves that PCN= =20 potentially had enough legs to go beyond just an intra-domain scenario. I would be very happy to take a more measured approach to this whole area,= =20 if others are interested too. In that case, yes, we should start with a=20 problem statement alone. I suggest the general problem is how to police=20 microflow admission control at borders without per-flow processing. Or we=20 could limit the scope of the problem to a PCN context. Even though this isn't yet PCN chartered work, would you be interested in=20 working on an I-D on this with me in parallel to the PCN w-g, so it's ready= =20 for when the PCN group re-charter in about a year's time? Once the problem is clarified, we should see if we can dream up other=20 solutions. However, policing of a response to network layer congestion by=20 the transport was a very hard problem to solve elegantly. Solving it across= =20 an internetwork has been much much harder. So I suspect any alternative=20 solutions are going to look pretty similar to this one, unless someone=20 makes an innovative breakthrough. >I've read the March version of your draft - after a brief >glance on the June version. I still think they mostly >represent my thoughts on your input. Diffs from the previous draft were minimal. You can see them hilited via a= =20 link at: For the benefit of the list, you can also get the draft in various formats,= =20 and presentations of it via this link. Merry thingy Bob ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not=20 necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196= =20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Dec 22 13:19:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxozF-00032C-L7; Fri, 22 Dec 2006 13:19:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxozE-000322-Kn for pcn@ietf.org; Fri, 22 Dec 2006 13:19:16 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxozC-0005KK-Ro for pcn@ietf.org; Fri, 22 Dec 2006 13:19:16 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBMIHuPf013568 for ; Fri, 22 Dec 2006 20:18:27 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Dec 2006 20:18:38 +0200 Received: from esmgw001.ext.nokia.com ([147.243.42.25]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Dec 2006 20:16:47 +0200 Received: from espmg001.ext.nokia.com (espmg001.ext.nokia.com [147.243.46.49]) by esmgw001.ext.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBMIGK4B030380 for ; Fri, 22 Dec 2006 20:16:22 +0200 Message-ID: <23941163.1166811406700.JavaMail.root@espmg001.ext.nokia.com> Date: Fri, 22 Dec 2006 20:16:44 +0200 (EET) From: Lars Eggert To: pcn@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 22 Dec 2006 18:16:47.0687 (UTC) FILETIME=[57FEA570:01C725F5] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [PCN] Quick update X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi, sorry for the period of silence; I'm currently in-between jobs and things are a bit hectic. I've prepared a revision of the initial charter that attempts to carefully outline the initial scope for this work. I plan on posting it for discussion to the list after some further refinements over the holidays. It is similar to the previous charter proposal, but refactors the initial constraints and milestones in a wa that Magnus and me prefer. Happy holidays! Lars -- NEW EMAIL: lars.eggert@nokia.com NEW MOBILE: +358 50 48 24461 NEW JABBER: lars.eggert@googlemail.com _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Dec 26 11:46:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzFRn-0000V1-Fy; Tue, 26 Dec 2006 11:46:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzFRl-0000Uv-PC for pcn@ietf.org; Tue, 26 Dec 2006 11:46:37 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzFRj-0006Nd-Ep for pcn@ietf.org; Tue, 26 Dec 2006 11:46:37 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kBQGkVZX006930; Tue, 26 Dec 2006 10:46:31 -0600 (CST) Received: from ILEXC1U02.ndc.lucent.com ([135.3.39.5]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Dec 2006 10:46:31 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Alternatives to Preemption Date: Tue, 26 Dec 2006 10:46:30 -0600 Message-ID: <7D096A439A3D0D48A3D10872022CFD098644FE@ILEXC1U02.ndc.lucent.com> In-Reply-To: <4586AA22.9040907@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Alternatives to Preemption Thread-Index: Accit5Znpkf4YmjjQbKNaBMoqo0h3gGVOvxg From: "GOLDMAN, STUART O \(STUART\)" To: "Magnus Westerlund" , X-OriginalArrivalTime: 26 Dec 2006 16:46:31.0400 (UTC) FILETIME=[6549D680:01C7290D] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Magnus, You have asked an interesting question. ("Isn't most operator more in favor of reduced quality, rather than dropped calls?") I suspect that different users would have different preferences. Personally, I would like a third choice. I don't like either dropped calls or unacceptable QoS, as I suspect both would lead to service calls resulting in no trouble found and thus subscriber disappointment with the service. Rather I would be more comfortable with using the PCN to cause new session originations to be blocked so that the network can return to a stable state. I gathered at the BOF that this would likely occur in a matter of several seconds after an event. Stuart Goldman Alcatel-Lucent=20 sgoldman@alcatel-lucent.com 602 493 8438 -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Monday, December 18, 2006 7:48 AM To: pcn@ietf.org Subject: [PCN] Alternatives to Preemption Hi, So far the discussion has been quite focused on preemption when the=20 resources gets overtaxed. Aren't there some cases when the alternative=20 to preemption would be to indicate to the flows that they may only use=20 less resources? This could happen by having the QoS mechanism engage in=20 re-negotiation. For example in cases when large parts of the traffic is voice, then one=20 could change the encoding or change codec mode to reduce the rate. Isn't most operator more in favor of reduced quality, rather than dropped calls? To be clear, this is a subject I would like to have some opinion from=20 the group on to see if it is important to consider in the development.=20 However I don't see how it would be in the first phase of a PCN WG other than as a constraint. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn